Die Plattform wird innerhalb Ihres eigenen Cloud-Kontos installiert.

Nexa Intelligence lauft als Menge von Workers, Queues, Objektspeichern und Durable Objects innerhalb einer Infrastruktur, die Sie besitzen. Cloudflare ist das Standard-Substrat, da die gesamte Plattform Cloudflare-nativ ist. AWS, Azure und On-Premise folgen demselben Modell auf einem anderen Anbieter. Ihr IT-Team installiert das Cloud Harness. Wir arbeiten darin. Daten verlassen Ihren Perimeter nie zur Verarbeitung.

Diese Seite behandelt, was installiert wird, wer was betreibt, was Ihren Perimeter uberschreitet und wie das Deployment je nach Anbieter variiert.

[ 01 ]  ·  NAMED: DAS CLOUD HARNESS

Eine installierbare Einheit. Ihr Konto. Unser Betrieb.

Das Cloud Harness ist das Infrastrukturpaket, das zu Ihrem Deployment wird. Auf Cloudflare sind das sieben Workers, zwei R2-Buckets, mehrere Durable-Object-Klassen und eine kleine Menge Queues. Auf AWS ist das dieselbe Topologie, abgebildet auf Lambda, S3, DynamoDB und SQS. Auf Azure sind das Functions, Blob Storage, Cosmos DB und Service Bus. On-Premise ist das dieselbe Topologie auf Kubernetes mit Postgres, MinIO und NATS.

Ihr Team stellt das Konto bereit. Wir liefern die Deployment-Skripte, die Wrangler- oder Terraform-Konfiguration und das Installations-Runbook. Sobald das Harness einsatzbereit ist, halt Ihr Konto jeden Teil der Infrastruktur, den die Plattform benutzt. Es gibt keine separate, Nexa-kontrollierte Umgebung, durch die Ihre Daten fliessen.

Wir betreiben das Harness unter einem unterzeichneten Vertrag. Ihre IT behalt die Schlussel. Wir erhalten den Zugang, den wir fur den Betrieb von Anreicherung, Dashboards und Agentenoberflachen benotigen, begrenzt auf die Umgebungen, die wir betreiben.

Architekturskizze

Wo der Datenpfad lebt.

Datenpfad verbleibt in Ihrem Konto. Zwei Grenzaufrufe, beide vertraglich gebunden.

[ 02 ]  ·  NAMED: WAS DEN PERIMETER UBERSCHREITET

Zwei ausgehende Aufrufe. Beide unter unterzeichneten No-Retention-Vertragen.

Zwei Dienste leben ausserhalb Ihres Kontos: der LLM-Anbieter (Anthropic) und der Sprachanbieter (ElevenLabs). Jeder andere Teil des Systems lauft innerhalb Ihres Kontos, einschliesslich des Data Lakes, der Anreicherungs-Workers, des Fact Stores, der Dashboards und der Agenten-Endpunkte.

Der Anthropic-Aufruf ist durch einen No-Training-Vertrag auf jedem Plan gebunden. Enterprise betreibt zusatzlich No-Retention: keine Kundeninhalte bleiben bei Anthropic uber die Anfrage hinaus bestehen. ElevenLabs betreibt No-Retention auf jedem Plan und jeder Stufe. Das Originalaudio hinterlasst nach Geendigung des Anrufs keine Spur beim Sprachanbieter. Siehe die Unterauftragsverarbeiterliste fur die genauen Daten, die jeder Partner sieht.

Eingehende Aufrufe sind am Edge authentifiziert. Webhooks tragen eine HMAC-Signatur, die gegen ein in Ihrem Konto gespeichertes Secret verifiziert wird. Betreiberoberflachen tragen ein Bearer-Token, dessen Umfang in der Berechtigung kodiert ist. Es gibt kein gemeinsames Secret zwischen Nexa und Ihrem Konto ausser den Anmeldedaten, die Ihre IT uns ausstellt.

[ 03 ]  ·  NAMED: CLOUDFLARE (STANDARD)

Workers, R2, Durable Objects, Queues.

Cloudflare ist das Standard-Substrat, da die Plattform Cloudflare-nativ ist. Das Harness wird als sieben Workers (operations, canvas, ingestion, engine, query, r2ops, docs), zwei R2-Buckets (der Data Lake und der Matrix-Artefakt-Speicher) und eine Menge Durable-Object-Klassen, die den Matrix-spezifischen Zustand halten, bereitgestellt. Queues transportieren asynchrone Arbeit zwischen dem Ingestion-Worker und der Anreicherungs-Engine.

Jede wrangler.toml setzt workers_dev = false, sodass die *.workers.dev-URLs 404 zuruckgeben. Nur die benutzerdefinierten Domains in Ihrem Konto bedienen Traffic. Der Engine-Worker hat uberhaupt keine offentliche Oberflache. Er wird uber Queue-Consumer und Service-Bindings von anderen Workers in Ihrem Konto erreicht. Es gibt keinen eingehenden Pfad vom Internet zum LLM-aufrufenden Worker.

Cloudflare-nativ bedeutet, dass das regionale Pinning eine Konfigurationsanderung statt einer Re-Architektur ist. R2-Buckets konnen uber die Bucket-Bindung an die Gerichtsbarkeiten eu oder fedramp angeheftet werden. Durable Objects akzeptieren Standorthinweise, die sie in einer bestimmten Region platzieren. Siehe Abschnitt 06 fur die Datenresidenz-Konfiguration.

[ 04 ]  ·  NAMED: AWS

Lambda, S3, DynamoDB, SQS, EventBridge.

Das AWS-Deployment bildet die Harness-Topologie auf die aquivalenten AWS-Primitive ab. Workers werden zu Lambda-Funktionen. R2-Buckets werden zu S3-Buckets mit Bucket-Policy-Isolation zwischen dem Data Lake und dem Matrix-Artefakt-Speicher. Durable Objects werden zu DynamoDB-Tabellen mit zeilenspezifischen Scope-Schlusseln. Queues werden zu SQS, wobei EventBridge das Fan-out ubernimmt.

Secrets leben in AWS Secrets Manager, je Funktion begrenzt. KMS-Schlussel werden je Umgebung ausgestellt. Die IAM-Policy auf jedem Lambda beschrankt es auf die Buckets, Tabellen und Queues, die es tatsachlich benotigt. Das Lambda, das Anthropic aufruft, kann nicht in den Data Lake schreiben. Das Lambda, das Webhooks einliest, kann keine Matrix-Artefakte uberschreiben. Dieselbe Trennung der Anmeldedaten, die auf Cloudflare gilt, gilt auch auf AWS.

Wir liefern das Terraform-Modul. Ihre IT fuhrt das Apply aus. Kontoeigentumerschaft, Abrechnung und der IAM-Root liegen bei Ihnen.

[ 05 ]  ·  NAMED: AZURE

Functions, Blob Storage, Cosmos DB, Service Bus.

Das Azure-Deployment verwendet Azure Functions fur die Worker-Schicht, Blob Storage fur den Data Lake und den Matrix-Artefakt-Speicher, Cosmos DB fur die Matrix-spezifischen Zustandstabellen und Service Bus fur die Queue-Schicht. Key Vault halt die Secrets. Verwaltete Identitaten begrenzen den Zugang jeder Function auf die Ressourcen, mit denen sie arbeitet.

Azure-Deployments sind in regulierten Branchen verbreitet. Das Harness wird mit den Azure-Policy-Vorlagen geliefert, die fur DSGVO- und Loi 25 Quebec-Residenz-Konfigurationen benotigt werden. Ressourcengruppen konnen an eine Region angeheftet werden, und Cosmos-DB-Konten konnen auf eine einzelne Region ohne regionsushergreifende Replikation gesperrt werden.

[ 06 ]  ·  NAMED: ON-PREMISE

Kubernetes, Postgres, MinIO, NATS.

On-Premise-Kunden betreiben das Harness auf Kubernetes. Workers werden zu Container-Deployments. Speicherung wird zu MinIO mit derselben Zwei-Bucket-Trennung wie die Cloud-Varianten. Der Matrix-spezifische Zustand wird zu einem Postgres-Schema mit Row-Level-Security, die auf dem Matrix-Identifier schlussel. Queues werden zu NATS JetStream.

On-Premise ist die Konfiguration fur Kunden mit expliziten Datenresidenz-Anforderungen, die keine Public Cloud erfullen kann, oder die bereits eine private Kubernetes-Plattform betreiben, die ihr Sicherheitsteam gepruft hat. Dieselben Partner-Aufrufe gelten: ausgehendes HTTPS zu Anthropic und ElevenLabs unter denselben No-Training- und No-Retention-Vertragen. Wenn diese Aufrufe auch durch Richtlinien verboten sind, lauft das Deployment im Air-Gapped-Modus mit On-Premise-Inferenz und On-Premise-Sprachsynthese. Der Kompromiss ist die Qualitat des Interview-Agenten und die Kosten pro Gesprach.

[ 07 ]  ·  NAMED: DATENRESIDENZ

Die Daten liegen dort, wo Sie sie platzieren.

Speicherung und Compute konnen zum Deployment-Zeitpunkt an eine Gerichtsbarkeit angeheftet werden. Auf Cloudflare ist das der R2-Bucket-Gerichtsbarkeit-Flag plus Durable-Object-Standorthinweise. Auf AWS ist das die Region des S3-Buckets und der Lambda-Funktion. Auf Azure ist das die Region der Ressourcengruppe. On-Premise ist das der physische Standort des Clusters.

Fur Kunden mit EU-Residenz-Anforderungen kann jedes Stuck Infrastruktur an EU-Regionen angeheftet werden. Fur Kunden im kanadischen offentlichen Sektor oder in Quebec unter Loi 25 sind die kanadischen Regionen jedes Anbieters verfugbar. Das Deployment-Runbook listet die genauen Regions-IDs auf, die wir je Gerichtsbarkeit verwenden.

[ 08 ]  ·  NAMED: BETRIEBSGRENZE

Was Nexa innerhalb Ihres Kontos tut.

Innerhalb Ihres Kontos betreibt Nexa das Harness. Das bedeutet, wir rollen Releases aus, fuhren Incident-Response durch, uberwachen Observability, stimmen die Anreicherungspipeline auf Ihren Korpus ab, kalibrieren die dimensionsspezifischen Halbwertszeiten und liefern Patches. Wir exportieren Ihre Daten nicht. Wir fuhren kein Training damit durch. Der Datenpfad verbleibt innerhalb des Perimeters, den Sie besitzen.

Die Betriebsgrenze ist im Vertrag benannt. Ihre IT kontrolliert die Schlussel, die Abrechnung und die Root-Anmeldedaten. Unser Zugang ist auf die Betriebsoberflachen begrenzt, die wir benotigen. Audit-Logs von Betreiberaktionen befinden sich in Ihrem Konto, wo Ihr Sicherheitsteam sie pruft.

Wenn Sie die Anbieterbeziehung beenden, lauft das Deployment auf Ihrem Konto ohne uns weiter. Siehe Datenunabhangigkeit fur die Kontinuitatsgarantie.