Air-Gapped-KI hat schon vor einiger Zeit aufgehört, eine Nischenanfrage zu sein. Eine Branchenschätzung bezifferte air-gapped oder vollständig On-Premises betriebene Unternehmens-LLMs im ersten Quartal 2026 auf 14 bis 19 Prozent der Unternehmen mit mehr als 5.000 Mitarbeitenden, wobei Verteidigung, Nachrichtendienste und Behörden rund 38 Prozent dieser Ausgaben ausmachten, Gesundheitswesen 19 Prozent, regulierte Finanzwirtschaft 17 Prozent und der Rechtsbereich 9 Prozent. Das ist kein Randfall, das ist ein Segment.
Der Grund liegt auf der Hand, sobald man betrachtet, was ein Air Gap tatsächlich schützt. Er hält Prompts, Ausgaben, Modellgewichte, Retrieval-Korpora, Logs und Identitäten innerhalb einer geschlossenen Grenze. Für Verschlusssachen, für Betreiber kritischer Infrastruktur, die keine über das Internet eingetragenen Kompromittierungspfade in operative Systeme hinnehmen können, und für Organisationen, deren Quellcode, Transaktionsunterlagen oder Forschungsdaten das Geschäft sind, ist diese Grenze die Kontrolle. Keine vertragliche Zusicherung eines Modellanbieters ersetzt sie.
Schieflagen entstehen in der Lücke zwischen Behauptung und Architektur. Teams betreiben ein Open-Weight-Modell auf eigenen GPUs, stellen eine Firewall davor und nennen das Ergebnis air-gapped. Dann zieht das Container-Image beim Neustart aus einer öffentlichen Registry, ein Python-Paket aktualisiert sich bei einem Rebuild, oder eine Komponente meldet still die Nutzung an einen Anbieter-Endpunkt. Jeder dieser Fälle ist ein routbarer Pfad, und jeder bedeutet, dass die Isolationsbehauptung ein Audit nicht übersteht.
Was Isolation tatsächlich verlangt
Ein air-gapped LLM hat im Normalbetrieb keinen routbaren Pfad ins öffentliche Internet. Das ist eine stärkere Aussage als “hinter einer Firewall”, und sie zwingt jede Laufzeitabhängigkeit ins Lokale: Inferenz, Retrieval, Embeddings, Identität, Auditlogging und die Agentenschleife, falls vorhanden.
Die unmittelbare Folge: Gehostete Frontier-APIs fallen aus. Jeder externe Aufruf durchbricht die Enklave, womit die Modellwahl auf Open-Weight-Familien beschränkt ist, die Sie rechtlich und technisch innerhalb der Grenze spiegeln dürfen. Diese Einschränkung sollte den Auswahlprozess von Anfang an prägen, statt entdeckt zu werden, nachdem ein Pilot auf einer gehosteten API die Qualitätserwartung gesetzt hat.
Die weniger offensichtliche Folge: Mehrere Dienste, an die kaum ein Team denkt, werden Ihre Verantwortung. DNS-Auflösung, Zeitsynchronisation, Zertifikatsprüfung, Lizenzabfragen, Authentifizierungs-Backends und Paketverwaltung setzen in ihren Voreinstellungen alle Konnektivität voraus. Interne NTP- oder GPS-Zeitquellen und internes IAM, LDAP und PKI sind in reifen Deployments genau deshalb Standard, weil Monitoring und Auditdatensätze wertlos sind, wenn Uhr und Identitätsdienst nicht vertrauenswürdig sind.
Die Transferstrecke
Air-Gapped-Umgebungen ersetzen Auto-Update durch eine kontrollierte Transferstrecke. Die Stufen sind über die Deployments hinweg, die wir funktionieren gesehen haben, konsistent.
- In einer verbundenen Staging-Zone bauen. Modellgewichte, Tokenizer- und Config-Dateien, Serving-Container-Images, Dependency-Bündel, Sicherheitspatches, Evaluationsdatensätze und Regressionstests zuerst in eine vernetzte Umgebung laden.
- Vor dem Transfer prüfen. Hashes, Signaturen, Lizenzbedingungen und Herkunft kontrollieren. Viele Programme ergänzen hier eine Sicherheitsprüfung und die Protokollierung der Nachweiskette, und genau dieser Nachweis ist das, was Sie später einem Prüfer zeigen.
- Den Gap bewusst überqueren. Freigegebene physische Medien oder ein Einwegmechanismus wie eine Datendiode, gewählt nach Risikomodell und nicht nach Bequemlichkeit.
- In interne Registries importieren. Images und Pakete in lokale Artefakt-Registries vorladen, damit die Produktion nie nach einem öffentlichen Repository greift, auch nicht bei einem Neustart um drei Uhr morgens.
- Nach dem Import erneut validieren. Bestätigen, dass das Modell offline auf den Ziel-GPUs läuft, dann über interne Freigabestufen befördern.
Der Schritt, den Teams überspringen, ist der Rollback. Ein Vorwärtsprozess ohne internen Rückwärtspfad bedeutet, dass eine schlechte Modellversion nur durch einen weiteren vollständigen Transferzyklus aufgelöst wird, was in einer kontrollierten Umgebung Tage statt Minuten dauert. Halten Sie das vorherige geprüfte Bündel in der internen Registry vor und üben Sie die Rückkehr dorthin.
Auch die Lizenzierung verdient hier eine ausdrückliche Prüfstufe. Offline-Rechte und Weitergabebedingungen unterscheiden sich zwischen Open-Weight-Familien, und ein Modell, das Sie nicht rechtmäßig in eine Enklave spiegeln dürfen, ist ein Modell, das Sie nicht nutzen können, unabhängig von seinen Benchmarks.
Offline-RAG
Retrieval funktioniert offline, wenn die gesamte Retrieval-Kette innerhalb der Grenze liegt. Die Ingestion ist lokal: Dokumente werden auf interner Infrastruktur gescannt, in Chunks zerlegt, eingebettet und indexiert. Embeddings stammen aus einem lokalen Modell statt aus einer gehosteten Embedding-API, was häufig übersehen wird, weil sich Embedding-Aufrufe eher wie Infrastruktur als wie Modellnutzung anfühlen. Die Vektordatenbank sitzt innerhalb derselben Sicherheitsgrenze wie die Inferenzebene.
Am stärksten unterscheidet sich Offline-RAG bei der Zugriffskontrolle. Retrieval muss Dokumentenklassifizierung und Kenntnis-nur-wenn-nötig respektieren, durchgesetzt gegen einen lokalen Identitätsdienst, denn eine Retrieval-Schicht, die jeden indexierten Chunk an jeden authentifizierten Nutzer zurückgibt, hat den Korpus faktisch herabgestuft. Setzen Sie den Filter zur Abfragezeit gegen die Nutzeridentität durch, statt sich darauf zu verlassen, dass der Prompt begrenzt, was das Modell preisgibt.
Es gibt außerdem keine externe Erdung. Keine Websuche, keine externen Zitate. Braucht das System aktuelle Informationen, kommen sie aus internen Spiegeln, internen Wissensbeständen oder einem geführten Cross-Domain-Ingestionsprozess. Und dieser Ingestionsprozess ist selbst eine Lieferkette: Dokumente, Embeddings und Indizes lassen sich alle vergiften, wenn die Ingestion nicht kontrolliert und protokolliert wird. Behandeln Sie die Korpus-Ingestion mit derselben Strenge wie Container-Images.
Monitoring, wenn nichts nach Hause telefonieren darf
Anbieter-Dashboards, SaaS-Telemetrie und cloudgehostete Observability stehen sämtlich nicht zur Verfügung, Observability muss also von Anfang an lokal gebaut werden.
- Metriken, Logs, Traces und Auditdatensätze schreiben in internen Storage.
- Ausgehende Telemetrie wird in der Konfiguration abgeschaltet, nicht nur auf Netzwerkebene geblockt. Viele Werkzeuge wiederholen, puffern und scheitern auf verwirrende Weise, wenn ihr Telemetrie-Endpunkt unerreichbar ist, das saubere Abschalten ist also Sicherheits- und Zuverlässigkeitsmaßnahme zugleich.
- Auditlogs sind append-only oder signiert, damit sie einer forensischen Prüfung standhalten.
- Health Checks decken GPU-Speicher, Token-Durchsatz, Queue-Tiefe, Ladestatus des Modells, Latenz des Vector Stores und Crash Recovery ab, lokal überwacht statt über einen Anbieter-Endpunkt.
Auf dieser Ebene wird die Betriebslast sichtbar. Manuelle Transfers, erneute Prüfungen und gestufte Beförderung machen den Air-Gap-Betrieb konstruktionsbedingt langsamer als Cloud-KI. Personalpläne, die innerhalb einer Enklave Iteration in Cloud-Geschwindigkeit unterstellen, erzeugen frustrierte Teams und ungepatchte Systeme, und das ist sicherheitstechnisch schlechter als das, was der Air Gap liefern sollte.
Übliche Fehlermuster
Die Fallstricke wiederholen sich über Programme hinweg. Ein netzwerkbeschränktes System air-gapped zu nennen. Die versteckten Abhängigkeiten von DNS, Zeit, Lizenzierung, Auth und Paketmanagern zu übersehen. Ein Modell zu wählen, das rechtlich oder technisch nicht offline gespiegelt werden kann. Die Rollback-Planung zu überspringen. Die RAG-Ingestion ungeführt zu lassen, sodass der Korpus zu einem unüberwachten Eingangspfad wird. Telemetrie aktiviert zu lassen, weil sie voreingestellt an war. Den Betriebsaufwand zu unterschätzen und dann still die Kontrollen zu lockern, um Schritt zu halten.
Jeder einzelne Punkt ist im Entwurf billiger zu adressieren als in der Nachbesserung, und alle werden in einer einzigen Übung sichtbar.
Wo Sie anfangen
Fahren Sie den Egress-Test, bevor Sie die Architektur schreiben. Nehmen Sie den vorgesehenen Stack, sperren Sie im Labor sämtlichen ausgehenden Verkehr und starten Sie jede Komponente neu, auch die, bei denen Sie sich sicher sind. Die Ausfallliste ist Ihr wahres Abhängigkeitsinventar, und sie ist fast immer länger als das Entwurfsdokument behauptet.
Bauen Sie von dort die zwei Zonen ausdrücklich: eine verbundene Staging-Zone für Downloads, Scans, Signaturen und Validierung und eine isolierte Produktionszone für Inferenz, Retrieval, Identität und Logging. Dazwischen liegt genau eine freigegebene Transfermethode mit Nachweiskette. Innerhalb der Produktionszone eine interne Artefakt-Registry und lokale Security Operations für Audit, Alarmierung und Incident Response.
Entscheiden Sie dann die Modellfrage früh, denn sie schränkt alles Weitere ein. Wählen Sie aus Open-Weight-Familien, deren Lizenzen die Offline-Spiegelung erlauben, dimensionieren Sie das Deployment für Hardware, die Sie ohne Fernzugriff des Anbieters warten können, und validieren Sie das Modell gegen Ihr eigenes Evaluationsset innerhalb der Enklave, statt Ergebnissen von einem verbundenen System zu vertrauen. Die Isolation ist der Zweck, und sie hält nur, wenn jede Lebenszyklusstufe sie respektiert.
Häufige Fragen
Ist ein Deployment hinter der Firewall dasselbe wie Air-Gapped?
Nein, und diese Unterscheidung wird in Anbietermaterial am häufigsten verwischt. Ein System ist air-gapped, wenn es im Normalbetrieb keinen routbaren Pfad ins öffentliche Internet hat. Erreicht es weiterhin eine gehostete Modell-API, ein Paketrepository, einen Lizenzserver oder einen Telemetrie-Endpunkt, ist es netzwerkbeschränkt, was eine legitime, aber eine andere Position ist. Der Test ist praktisch: Sperren Sie sämtlichen Egress am Perimeter und sehen Sie, was bricht. Alles, was ausfällt, ist eine Abhängigkeit, von der Sie nichts wussten, und sie muss aufgelöst sein, bevor Sie Isolation behaupten können.
Wie funktionieren Modell-Updates ohne Internetzugang?
Über eine kontrollierte Transferstrecke statt über einen Update-Mechanismus. Sie bauen in einer verbundenen Staging-Zone und laden dort Gewichte, Container-Images, Dependency-Wheels und signierte Artefakte herunter. Sie prüfen Hashes, Signaturen, Lizenzen und Herkunft, mit lückenloser Nachweiskette im Log. Sie bringen das Bündel über freigegebene physische Medien oder ein Einweggerät wie eine Datendiode über den Gap. Dann importieren Sie in interne Registries und validieren erneut, dass das Modell offline auf der Zielhardware läuft, bevor Sie es durch die internen Freigabestufen befördern. Planen Sie den Rollback-Pfad gleichzeitig, nicht danach.
Können wir Evaluation und Monitoring betreiben, ohne Telemetrie nach außen zu senden?
Ja, und es muss von vornherein eingeplant und nicht nachträglich angeschraubt werden. Metriken, Logs, Traces und Auditdatensätze gehen ausschließlich in internen Storage, ausgehende Telemetrie wird in der Konfiguration abgeschaltet und nicht nur an der Firewall geblockt, denn viele Werkzeuge setzen Konnektivität voreingestellt voraus. Nutzen Sie interne Zeit- und Identitätsdienste, damit Zeitstempel und Identitäten ohne externe Abhängigkeiten vertrauenswürdig bleiben. Führen Sie Auditlogs append-only oder signiert für die forensische Auswertung. Health Checks decken lokal GPU-Speicher, Token-Durchsatz, Queue-Tiefe, Ladestatus des Modells und Latenz des Vector Stores ab.