Air-gapped KI-Agenten: was Zero Egress wirklich bedeutet

Jedes ernsthafte Deployment-Gespräch mit einer sicherheitsbewussten Institution erreicht denselben Kontrollpunkt, und den führt das Netzwerkteam, nicht das Datenteam: "Was muss es erreichen?" Die meisten Enterprise-KI-Produkte antworten mit einer Liste - Modell-API, Lizenzserver, Telemetrie-Endpoint, Update-Kanal - und verhandeln dann, welche Einträge wirklich nötig sind. DataQube ist so gebaut, dass die Verhandlung entfällt: Die Plattform selbst erreicht nichts, und die eine Abhängigkeit, die wirklich ein Modell braucht - das Modell - läuft dort, wo Sie es entscheiden.

Zwei ehrliche Klarstellungen vor der Technik. Erstens: Voll-Air-Gap ist eine unterstützte Betriebsart von DataQube, nicht die einzige. Die meisten Kunden wählen kommerzielle Frontier-Modelle in ihrem bestehenden Cloud-Footprint - in der eigenen Tenancy, unter Zero-Data-Retention-Bedingungen, innerhalb von Vereinbarungen, die ihr Sicherheitsteam bereits geprüft hat. Zweitens: Die Air-Gap-Obergrenze prägt trotzdem das Produkt. Für den härtesten Fall zu entwerfen ist der Grund, warum die leichteren Fälle sauber sind: Eine Plattform ohne Telemetrie, ohne Lizenz-Callbacks und ohne Update-Kanal verhält sich identisch - ob der Modell-Endpoint im Cluster nebenan liegt oder in ihrer Cloud. Dieser Artikel handelt von dieser Obergrenze - was sie wirklich verlangt.

Wo das Modell läuft, ist Ihr Regler, nicht unserer

Der Modell-Endpoint ist Konfiguration, und die Konfiguration spannt ein Spektrum auf. Am einen Ende: ein OpenAI-kompatibler Endpoint in Ihrer eigenen Cloud-Tenancy - die Frontier-Modelle, die Ihre Teams bereits kennen, mit Zero Data Retention: Prompts und Outputs werden weder gespeichert noch für Training verwendet, und der Traffic verlässt die Vereinbarungen nicht, die Sie ohnehin governen. Hier landen die meisten Kunden, weil es Frontier-Qualität kauft, ohne eine einzige neue Datenbeziehung zu schaffen.

Am anderen Ende: ein voll air-gapped Deployment mit einem In-Cluster-Inferenzdienst auf Ihren eigenen GPUs, der Open-Weight-Modelle Ihrer Wahl serviert. Gar keine Route nach draußen - die Konfiguration für geschlossene Netze, und der Modus, den der Rest dieses Artikels auf die Probe stellt.

Was beide Enden teilen, ist die Eigenschaft, die für einen Auditor zählt: Die Modellwahl liegt unter Ihrer Änderungskontrolle. Ein Modell-Upgrade ist ein Change-Ticket - getestet, genehmigt, umkehrbar - und kein Anbieter, der still die Gewichte unter einer API austauscht. Wenn jemand fragt "Welches Modell hat die Zahlen des letzten Quartals produziert, und wer hat es genehmigt?", steht die Antwort in Ihrer Change-Historie - in beiden Fällen.

Delivery: ein genehmigter Pfad für alles

Software in ein Netz ohne Internet zu bringen ist ein gelöstes Logistikproblem - jede air-gapped Institution betreibt bereits einen Pfad für genehmigte Artefakte mit einem Registry-Mirror dahinter. Die Designpflicht des Anbieters ist, nur diesen Pfad zu brauchen, für jedes Artefakt, ohne Ausnahmen, die später als Überraschung auftauchen:

Ein Release besteht aus Container-Images, Deployment-Charts, Modellgewichten, wo wir welche liefern - und der Lizenz, die absichtlich langweilig ist: eine signierte Datei, lokal gegen unseren öffentlichen Schlüssel validiert, kein Lizenzserver, kein Aktivierungsaufruf, Verlängerung als Dateitausch über denselben Pfad. Nichts im Set erwartet, irgendetwas anderes nachzuladen: Zero Egress heißt, dass die gesamte Abhängigkeits-Hülle - bis hin zu sperrigen Artefakten wie Browser-Engines - zur Build-Zeit sichtbar wird und gepinnt ausgeliefert wird, statt über einen Download anzukommen, den niemand geprüft hat. Digest-Pinning macht den ganzen Pfad vertrauenswürdig: Was Ihr Team an der Grenze geprüft hat, läuft Byte für Byte identisch im Inneren, und die Digests im Deployment-Protokoll beantworten "Was genau läuft hier?" für jedes Audit, für immer. Reproduzierbare Builds schließen den Kreis - ein laufender Digest lässt sich auf ein Quell-Release zurückführen, ohne uns beim Wort nehmen zu müssen.

Support ohne Tunnel

Die Frage, die auf Delivery folgt: "Wenn etwas kaputtgeht - wie helfen Sie uns, wenn Sie sich nicht verbinden können?" Sie verdient eine konkrete Antwort, denn "Das kriegen wir schon hin" ist die Art, wie Remote-Zugriffs-Ausnahmen geboren werden.

Unsere Antwort hat drei Teile. Erstens: Die Audit- und Diagnose-Logs sind per Design strukturiert und exportierbar - dieselben Aufzeichnungen, die der Compliance dienen, dienen dem Support, und sie enthalten nie Daten, Credentials oder personenbezogene Informationen, sodass ihr Export durch einen Prüfprozess praktikabel ist. Zweitens: Reproduzierbare Builds bedeuten, dass ein gemeldetes Problem gegen einen Digest ein reproduzierbares Problem in unserem Labor ist - wir führen dieselben Bytes aus, keine Vermutung darüber. Drittens: Fixes reisen über den Artefaktpfad wie jedes Release - nach Ihrem Change-Kalender, nicht nach unserem.

Dieser letzte Halbsatz ist ein echter Preis, also gehört er auf den Tisch. Zero Egress hat uns Dinge aufgeben lassen, die Anbieter mögen: stille Auto-Updates (Kunden aktualisieren bewusst, nach ihrem Zeitplan), Nutzungsanalytik (wir lernen von Design-Partnern und Drills, nicht von Telemetrie) und Remote-Debugging (die Logs müssen gut genug sein - was sie dazu zwingt, es zu werden). Wir halten jeden dieser Trades für ein Feature im Kostüm eines Preises - jeder entfernt einen Kanal, den Ihr Security-Review sonst modellieren müsste.

Die Checkliste für jeden Anbieter, der Air-Gap behauptet

"Air-gap-fähig" reicht von "ernsthaft dafür entworfen" bis "lief einmal in einer Demo mit ausgeschaltetem WLAN". Fünf Fragen trennen die Enden dieser Spanne. Wo kann das Modell laufen - und ist vollständig innen eine unterstützte Antwort, kein Roadmap-Punkt? Ruft die Lizenzierung jemals nach draußen, auch nur einmal? Lässt sich jedes Artefakt eines Releases spiegeln und per Digest verifizieren - auch die sperrigen wie Browser-Engines und Modellgewichte? Was genau erhält der Support, wenn etwas bricht, und kommt in irgendeiner Antwort ein Tunnel vor? Und die zusammenfassende Frage, die das Netzwerkteam ohnehin stellt: Was muss die Plattform selbst erreichen?

Unsere Antworten stehen auf der Security-Seite, und das Deployment-Spektrum - Cloud-Tenancy mit Zero Data Retention bis Voll-Air-Gap - ist genau das, wofür der Sovereign-Tarif auf unserer Preisseite existiert. Eine Demo läuft problemlos mit gezogenem Internetstecker - das ist gewissermaßen der Punkt.