Luftgetrennte KI: Wie KI-Systeme ohne Internet- oder Cloud-Zugriff funktionieren

Air-Gapped-KI ist ein KI-System, das innerhalb einer Sicherheitsdomäne bereitgestellt wird, die keine physische Netzwerkverbindung zu den externen Systemen hat, von denen sie getrennt ist, wobei jede Übertragung über diese Grenze hinweg durch bewusst kontrollierte, nicht automatisierte Verfahren erfolgt. Das KI-Modell, die Laufzeitumgebung, die Daten, die Retrieval-Indizes, die Tools und die betrieblichen Abhängigkeiten, die für die Inferenz erforderlich sind, müssen daher innerhalb der isolierten Umgebung verfügbar sein. Air-Gapped-KI ist nicht einfach „ein lokales Modell“ oder „ein On-Premise-Server“: Die definierende Eigenschaft ist die Netzwerk- und Übertragungsgrenze um das gesamte System.

Was Air-Gapped-KI wirklich bedeutet

Das Wort KI ändert nichts am grundlegenden Sicherheitskonzept. Ein Air Gap ist eine Grenze zwischen Sicherheitsdomänen. KI macht die isolierte Seite lediglich betrieblich anspruchsvoller, da moderne KI-Stacks normalerweise herunterladbare Modelle, Paketregistrierungen, Telemetrie, APIs, Modell-Hubs und häufige Software-Updates voraussetzen.

Die isolierte Umgebung kann dennoch viele verbundene Maschinen enthalten. Ein interner Cluster kann GPUs, Anwendungsserver, Speicher, Datenbanken, Identitätsdienste und Überwachung enthalten, die untereinander verbunden sind. Der Air Gap besteht zwischen dieser Enklave und der Außendomäne.

Die relevante Frage ist daher nicht „Hat diese GPU WLAN?“, sondern „Kann diese KI-Umgebung Informationen mit der externen Domäne über einen automatisierten physischen oder logischen Pfad austauschen?“

Das einfachste Beispiel

Stellen Sie sich vor, ein Unternehmen möchte einen internen Assistenten für vertrauliche technische Dokumente, aber die Umgebung darf diese Dokumente nicht ins Internet senden.

Das Unternehmen lädt ein genehmigtes LLM, ein Embedding-Modell, Container-Images und Softwarepakete in einer verbundenen Staging-Umgebung herunter. Nach der Validierung werden genehmigte Artefakte in die isolierte Umgebung übertragen.

Innerhalb der Enklave laufen der Modellserver, der Dokumentenparser, die Vektordatenbank, die Anwendung und die Identitätsdienste lokal. Benutzer können Fragen stellen und RAG gegen interne Dokumente nutzen, ohne ein Cloud-Modell oder eine öffentliche Modellregistrierung.

Wenn ein Update erforderlich ist, durchläuft das Update erneut den kontrollierten Importprozess, anstatt direkt vom Produktions-KI-Server heruntergeladen zu werden.

Wo das einfache Beispiel endet

Eine produktive air-gapped Umgebung kann viel größer sein als eine einzelne Workstation. Sie kann Kubernetes/OpenShift, interne Registrierungen, Objektspeicher, Identitätsanbieter, Vektordatenbanken, Observability, Backup-Infrastruktur und mehrere Modell-Serving-Knoten umfassen.

Je mehr Dienste innerhalb der Enklave existieren, desto mehr muss die Organisation Fähigkeiten reproduzieren, die verbundene Umgebungen normalerweise aus dem Internet beziehen.

Air-Gapping verschiebt daher die Komplexität. Es reduziert die direkte externe Konnektivität, erhöht jedoch die Verantwortung für Artefaktverwaltung, Patches, Abhängigkeiten, Lieferkette und Betrieb innerhalb der isolierten Domäne.

Air-Gapped vs. Offline vs. Lokal vs. On-Premises vs. Privat vs. Souveräne KI

Diese Begriffe können sich überschneiden, sind aber keine Synonyme. Ein lokaler Ollama-Server, der mit dem Internet verbunden ist, ist lokale KI, keine Air-Gapped-KI. Eine On-Premises-RAG-Plattform, die ein Cloud-Modell aufruft, ist On-Premises-Anwendungsinfrastruktur mit Cloud-Inferenz, keine Air-Gapped-KI.

Ein Air-Gapped-System ist oft von Natur aus privat, weil Daten innerhalb der Enklave bleiben, aber Privatsphäre hängt auch von Autorisierung, Protokollierung, Datenhandhabung, physischer Sicherheit und Betriebsrichtlinien ab.

Strikte Air Gap vs. praktische getrennte Bereitstellung

Eine praktische Air-Gapped-KI-Architektur

Eine vollständige Architektur sollte starten und betrieben werden können, ohne DNS-Abfragen, Lizenzprüfungen, Paketdownloads oder API-Aufrufe an öffentliche Dienste, es sei denn, diese Abhängigkeiten haben genehmigte interne Ersatzlösungen.

Ein nützlicher Designtest besteht darin, die Bereitstellung von jedem externen Dienst zu trennen und den Stack kalt zu starten. Versteckte Abhängigkeiten treten tendenziell während des Starts, des Modellladens, der Authentifizierung, der Paketauflösung oder der Telemetrieinitialisierung auf.

Modelle müssen vorab bereitgestellt werden

Cloud-Modell-APIs sind per Definition nicht verfügbar, wenn die isolierte Workload keinen Pfad zu ihnen hat. Die Enklave benötigt daher lokal ausführbare Modellartefakte oder einen intern gehosteten Inferenzdienst.

NVIDIAs aktuelle NIM-Air-Gap-Dokumentation verwendet ausdrücklich ein zweiphasiges Muster: Modellressourcen auf einer verbundenen Maschine herunterladen und vorbereiten, übertragen und dann das isolierte NIM aus lokalem Speicher ausführen, ohne ausgehenden Registry-Zugriff oder Cloud-API-Schlüssel.

Modellgewichte sind nur ein Teil des Abhängigkeitssatzes. Tokenizer, Konfigurationsdateien, Adapter, Quantisierungsmetadaten und jeglicher erforderliche Laufzeitcode müssen ebenfalls vorhanden sein.

Modelle mit Remote-Code-Abhängigkeiten sind eine Air-Gap-Gefahr

Einige Modell-Repositories enthalten benutzerdefinierten Python-Code oder Laufzeit-Hooks, die normalerweise zusätzlichen Code oder Assets abrufen.

Die aktuelle Red Hat AI Inference-Dokumentation warnt ausdrücklich davor, dass einige Hugging Face-Modelle, die Remote-Code erfordern, in getrennten Umgebungen nicht normal funktionieren können, da die Bibliothek auch bei konfiguriertem Offline-Modus Netzwerkzugriffe versucht.

Die praktische Lehre ist, den gesamten Ladepfad eines Modells offline zu testen, bevor es für eine isolierte Bereitstellung freigegeben wird. „Ich habe die Gewichte heruntergeladen“ ist kein Beweis dafür, dass das Modell eigenständig ist.

Container, Pakete und Treiber werden zu lokalen Lieferketten-Artefakten

Verbundene Umgebungen beziehen routinemäßig Container-Images, Python-Pakete, Betriebssystem-Updates und GPU-Komponenten aus öffentlichen Registries. Eine air-gapped-Umgebung kann keinen dieser Dienste voraussetzen.

Red Hats Modell für getrennte KI-Bereitstellung verwendet interne Mirror-Registries für Container-Images und Operator-Kataloge. Modelle können als OCI-Artefakte gespiegelt oder auf persistenten Speicher übertragen werden.

Für umfassendere Stacks gilt dasselbe Muster oft für Sprachpakete, Linux-Repositories, JavaScript-Pakete und interne Binärdateien: Genehmigte Artefakte gelangen einmalig über den Übertragungsprozess hinein und werden dann aus vertrauenswürdigen internen Repositories bereitgestellt.

Kennen Sie die vollständige Abhängigkeitsrechnung

Interne Mirrors sind Infrastruktur, keine Bequemlichkeit

Eine getrennte Bereitstellung wird wartbar, wenn die isolierte Domäne bekannte interne Quellen für genehmigte Artefakte hat.

Red Hats dokumentierter Ansatz verwendet eine Mirror-Registry, die dem getrennten Cluster zur Verfügung steht, sodass Workloads keine öffentlichen Registries benötigen.

Dieselbe architektonische Idee kann auf Modellspeicher und Paket-Repositories angewendet werden. Das Ziel ist, Herkunft, Version und Genehmigung von Artefakten explizit zu machen, anstatt zufällige Dateien manuell auf jeden Server zu kopieren.

RAG kann vollständig air-gapped funktionieren

RAG erfordert nicht das öffentliche Internet. Es erfordert einen abrufbaren Korpus, eine Ingestion-/Indexierungspipeline und ein Modell, das den abgerufenen Kontext nutzen kann.

In einer air-gapped-Umgebung können der Dokumentenspeicher, Parser/OCR, das Embedding-Modell, der Vektor- oder lexikalische Index, der Reranker und das Generierungsmodell alle lokal ausgeführt werden.

Was sich ändert, ist die Quellenbeschaffung. Live-Websuche und Cloud-Dokumentenkonnektoren sind nicht verfügbar, es sei denn, äquivalente Daten werden über die kontrollierte Grenze importiert.

Der Korpus wird daher zu einem verwalteten Artefakt. Jeder Import sollte Quellenidentität, Datum/Version und Provenienz bewahren, damit Benutzer wissen, welches Wissen das isolierte System tatsächlich enthält.

Agenten können air-gapped laufen – aber nur mit erreichbaren Tools

Eine Agentenschleife kann vollständig innerhalb einer isolierten Enklave laufen, wenn die Modell-/Laufzeitumgebung und die erforderlichen Tools lokal oder im internen Netzwerk erreichbar sind.

Ein Tool, das von GitHub, öffentlicher Websuche, Cloud-E-Mail oder einer externen SaaS-API abhängt, wird fehlschlagen, es sei denn, die Architektur bietet ein genehmigtes internes Äquivalent oder einen kontrollierten asynchronen Austauschprozess.

Deshalb sollte das Design von air-gapped Agenten mit einer Fähigkeitsinventur beginnen: Jeder Tool-Endpunkt muss als intern, importiert, nicht verfügbar oder bewusst ausgeschlossen klassifiziert werden.

MCP umgeht die Air Gap nicht

MCP kann lokale Tools und Ressourcen innerhalb einer isolierten KI-Umgebung bereitstellen, aber das Protokoll schafft keine Konnektivität durch die Sicherheitsgrenze.

Ein lokaler MCP-Server, der interne Dokumente liest, kann perfekt offline arbeiten. Ein entfernter MCP-Server im öffentlichen Internet kann von einer strengen air-gapped Enklave aus nicht erreicht werden.

Dasselbe Prinzip gilt für jedes Konnektorprotokoll: Interoperabilität ist getrennt von Netzwerkautorität.

Identität und Authentifizierung müssen auch offline funktionieren

Eine KI-Anwendung kann lokal gehostet werden und dennoch von einem Cloud-Identitätsanbieter abhängen. Diese versteckte Abhängigkeit bricht den wirklich getrennten Betrieb.

Air-gapped Designs benötigen daher eine Identitätsarchitektur, die innerhalb der Enklave funktioniert: lokales Verzeichnis, interner Identitätsanbieter, interne PKI, lokale Dienstkonten oder ein anderer genehmigter Mechanismus.

Autorisierung bleibt notwendig, obwohl das Internet fehlt. Air Gaps ersetzen nicht RBAC, Mandantentrennung oder Least Privilege.

Zeit, Zertifikate und Trust Stores werden zu lokalen Abhängigkeiten

Viele Authentifizierungs- und Protokollierungssysteme hängen von zuverlässiger Zeit ab. Zertifikate laufen ab. Trust Stores ändern sich. Signierte Artefakte müssen validiert werden.

Eine getrennte Enklave sollte daher eine interne Zeitsynchronisation und einen Zertifikats-/Vertrauenslebenszyklus haben, der im normalen Betrieb nicht davon abhängt, öffentliche Dienste zu erreichen.

Dies sind gewöhnliche Infrastrukturbelange, die erst sichtbar werden, wenn eine Architektur ohne Internetzugang getestet wird.

Telemetrie und Absturzberichte benötigen eine explizite Richtlinie

Viele moderne Bibliotheken versuchen standardmäßig Analysen, Update-Prüfungen oder Fehlerberichte.

In einer isolierten Umgebung sollten diese Aufrufe entweder deaktiviert oder auf interne Observability umgeleitet werden. Wiederholte fehlgeschlagene Telemetrieversuche können Verzögerungen, verrauschte Logs und unerwartetes Startverhalten verursachen.

Eine Air-Gap-Bereitstellung sollte wissen, welche Komponenten ausgehende Verbindungen versuchen, selbst wenn die Firewall sie blockieren würde.

Air-Gap-Systeme benötigen trotzdem Patches

Netzwerkisolation verhindert nicht, dass Software Schwachstellen entwickelt. Sie ändert nur, wie Patches das System erreichen.

NIST beschreibt Patch-Management als vorbeugende Wartung: Organisationen müssen Patches und Updates weiterhin identifizieren, beschaffen, priorisieren, installieren und überprüfen.

Air-Gap-Betrieb erfordert daher eine wiederholbare Import-Kadenz für Betriebssystem-Pakete, Container-Images, Treiber, KI-Laufzeitumgebungen und Sicherheitsupdates. Der Kompromiss liegt zwischen Isolationsstabilität und Schwachstellenexposition durch veraltete Software.

Ein kontrollierter Update-Pfad

Die Übertragungsgrenze ist die sensibelste betriebliche Schnittstelle

Wenn externe Informationen in ein Air-Gap-System gelangen müssen, wird der Importkanal zu einem wichtigen Sicherheitskontrollpunkt.

Das NSA Cybersecurity Technical Cyber Threat Framework erkennt ausdrücklich die Replikation über Wechselmedien als einen Weg an, den Angreifer nutzen können, um in getrennte oder Air-Gap-Netzwerke einzudringen.

Deshalb können kontrollierter Medienumgang, Inspektion, Provenienz, Verschlüsselung wo erforderlich, Malware-Scans und Rollentrennung genauso wichtig sein wie der KI-Stack selbst.

Wechselmedien sind keine neutrale Leitung

USB-Sticks und andere tragbare Medien können sowohl legitime Modell-/Datenartefakte als auch schädliche Inhalte transportieren.

Die Medien-Sanitization-Richtlinien von NIST behandeln Speichermedien als Vertraulichkeits-Lebenszyklusobjekt, das je nach Sensibilität und Wiederverwendungsbedarf gelöscht, bereinigt oder zerstört werden muss.

Das genaue Übertragungsverfahren ist organisationsspezifisch, aber das architektonische Prinzip ist stabil: Grenzüberschreitende Medien sollten als Sicherheitsasset verwaltet und nicht als informelle Bequemlichkeit behandelt werden.

Air-Gapping erhöht die Bedeutung der Lieferkette

Ein isoliertes System erhält weniger externe Live-Eingaben, aber jede importierte Binärdatei, jedes Modell, jeder Container und jedes Paket wird bedeutsamer, weil die Enklave ihm möglicherweise lange Zeit vertraut.

Die NIST-Richtlinien zur Software-Lieferkette betonen Herkunft, Lieferantenrisiko, Schwachstellenmanagement, Softwareverifikation und SBOM-orientierte Praktiken. Diese Belange werden direkt relevant für den Offline-Import von KI-Artefakten.

Die Modell-Lieferkette verdient dieselbe Aufmerksamkeit wie die Anwendungs-Lieferkette: Modellherkunft, Lizenz, Hash, Format, erforderlicher Code, Tokenizer, Adapter und Evaluierungsstatus sollten vor dem Import bekannt sein.

Air-Gap-Bereitschaft sollte getestet, nicht angenommen werden

Einmal zwischengespeichert ist nicht dasselbe wie Air-Gap-bereit

Ein System kann offline erscheinen, weil das Modell und die Pakete bereits aus früherem Internetzugriff zwischengespeichert sind.

Das Löschen von Caches oder die Bereitstellung auf einem sauberen Knoten kann fehlende Tokenizer-Dateien, Python-Pakete, Modellmanifeste oder Remote-Code-Abhängigkeiten aufdecken.

Die Air-Gap-Bereitschaft sollte daher anhand sauberer interner Artefakte validiert werden, nicht nur von einem Entwickler-Arbeitsplatz, der zuvor verbunden war.

Welche Bedrohungen bleiben innerhalb eines Air Gaps bestehen?

Was ein Air Gap tatsächlich verbessert

Ein echter Air Gap kann Angriffspfade, die auf direkter Fernkonnektivität beruhen, wesentlich reduzieren: externe Command-and-Control, Missbrauch von Cloud-Anmeldeinformationen, Ausnutzung internetzugewandter Dienste und versehentliche Datenexfiltration über gewöhnliche ausgehende APIs.

Er macht auch die Datenresidenz in einem engen Sinne einfach: Inferenzdaten können nicht an einen externen Cloud-Dienst gesendet werden, wenn kein Pfad existiert.

Diese Vorteile sind am stärksten, wenn die Transfergrenze und die internen Zugriffskontrollen gleichermaßen diszipliniert sind. Ein schlecht verwalteter USB-Prozess kann die beabsichtigte Isolation untergraben.

Was ein Air Gap schwieriger macht

Air-Gapped-KI vs. private KI

Bei privater KI geht es in erster Linie um die Kontrolle sensibler Daten und der KI-Verarbeitung. Eine private KI-Plattform kann vor Ort betrieben werden und dennoch auf genehmigte Cloud-Modelle oder externe Dienste zugreifen.

Air-Gapped-KI ist strenger in Bezug auf Konnektivität. Ein System kann privat sein, ohne air-gapped zu sein, und ein air-gapped System kann dennoch eine schlechte Privatsphäre aufweisen, wenn jeder interne Benutzer uneingeschränkten Zugriff hat.

Das Sicherheitsziel sollte die Architektur bestimmen: Vertraulichkeit, Souveränität, Resilienz und Isolation sind verwandte, aber unterschiedliche Anforderungen.

Air-Gapped-KI vs. souveräne KI

Souveräne KI betrifft die Kontrolle über die breitere Abhängigkeitskette: Daten, Modelle, Infrastruktur, Betreiber, Gerichtsbarkeit und strategische Abhängigkeiten.

Eine Air Gap kann die Souveränität unterstützen, indem sie die externe Laufzeitabhängigkeit reduziert, aber sie garantiert keine souveräne Kontrolle. Die Enklave kann weiterhin von ausländischer Hardware, proprietären Modelllizenzen oder externen Update-Anbietern abhängen.

Der nächste kanonische Artikel trennt diese Kontrolldimensionen explizit.

Nachweise aus der ursprünglichen Implementierung: Was der Aaasaasa AI Client beweist — und was nicht

Der AI Hub trennt Agent/Client, Anbieter, Modell und Verbindungsstandort. Er unterstützt lokale Ollama-Inferenz und lokalen Codex-Betrieb als unterschiedliche Optionen, anstatt anzunehmen, dass jede KI-Anfrage an ein Cloud-Modell geht.

Das Repository weist ausdrücklich darauf hin, dass eine lokale Laufzeit weiterhin ein Cloud-Modell verwenden kann, während der direkte Ollama-Chat lokale Inferenz ist. Diese Unterscheidung ist direkt relevant für die Air-Gap-Architektur: Lokale Ausführung beweist nicht, dass das Modell oder die umgebenden Abhängigkeiten getrennt sind.

Anbieterabstraktion, lokale Modellerkennung und lokale Inferenz sind daher Bausteine für eine air-gap-fähige Produktarchitektur, aber die Netzwerkgrenze, der Offline-Abhängigkeitsspiegel, der kontrollierte Übertragungsprozess und die Offline-Identität/-Operationen müssen weiterhin separat entwickelt werden.

Wann ist Air-Gapped-KI gerechtfertigt?

Air-Gapping sollte eine Anforderung sein, die sich aus einem Bedrohungsmodell oder einer Richtlinie ableitet, nicht ein Prestigemerkmal. Es hat echten Sicherheitswert, wenn der eliminierte Konnektivitätspfad selbst inakzeptabel ist.

Für viele Unternehmensanwendungsfälle kann ein streng kontrolliertes privates Netzwerk mit Egress-Beschränkungen, lokaler Inferenz und genehmigten Update-Kanälen ein besseres Gleichgewicht zwischen Sicherheit und Wartbarkeit bieten als ein strikter physischer Air Gap.

Eine praktische air-gapped KI-Designsequenz

Checkliste für air-gapped KI-Architektur

Häufige Fehlermodi bei air-gapped KI

Häufige Missverständnisse

Einschränkungen

Strikte Air Gaps verlangsamen die Aktualität externen Wissens, weil jede neue Quelle einen Transferprozess durchlaufen muss.

Sie können die Modellauswahl einschränken, wenn Lizenzen, Remote-Code-Anforderungen, Hardwareanforderungen oder anbietergebundene APIs offline nicht erfüllt werden können.

Sie erhöhen die Betriebskosten, weil Infrastruktur, die normalerweise als Cloud-Dienste bezogen wird, intern besessen und gewartet werden muss.

Sie können außerdem Patch-Latenz erzeugen: stärkere Änderungskontrolle kann Systeme stabil halten, während dringende Schwachstellenbehebung verzögert wird.

Air-gapped KI sollte daher als eine Sicherheitsarchitektur unter mehreren bewertet werden und nicht als universell überlegen angenommen werden.

Was würde diese Antwort ändern?

Die Anbieterunterstützung für getrennten Betrieb ändert sich schnell. Neue Modellformate, signierte OCI-Artefakte, Offline-Lizenzmechanismen und integrierte Modellregistries können den Betriebsaufwand verringern.

Die Unterscheidung zwischen striktem Air Gap und getrenntem Deployment wird wichtig bleiben, selbst wenn Anbieter die Begriffe weiterhin locker verwenden.

Das stabile Prinzip ist, dass echte Air-Gap-Behauptungen von der Systemgrenze und dem Transfermechanismus abhängen, nicht davon, ob das LLM zufällig lokal läuft.

Verwandtes kanonisches Wissen

Air-Gapped AI ist ein Knoten für Bereitstellungs-/Sicherheitsarchitektur. Private AI, Sovereign AI und Provider-Abstraktion beantworten unterschiedliche Fragen zu Vertraulichkeit, Kontrolle und Abhängigkeit.

MLOps/LLMOps wird in einer getrennten Umgebung anspruchsvoller, weil Modell-, Paket- und Update-Lebenszyklen über interne Repositories und kontrollierte Übertragung ablaufen müssen.

RAG und Agentic AI bleiben gültige Muster innerhalb der Enklave, solange ihre Daten und Werkzeuge intern verfügbar sind.

Häufig gestellte Fragen

Glossar

Fazit

Air-gapped AI ist keine besondere Art von Modell. Es ist eine KI-Architektur, die innerhalb einer bewusst isolierten Sicherheitsdomäne betrieben wird.

Das Modell kann der einfache Teil sein. Produktionsreife hängt davon ab, ob jede umgebende Abhängigkeit – Modellassets, Pakete, Registries, Identität, RAG, Werkzeuge, Monitoring, Updates und Wiederherstellung – ohne einen automatisierten externen Pfad funktionieren kann.

Die kürzeste zuverlässige Regel lautet: Lokale Inferenz beweist, wo das Modell läuft; Air-Gap-Nachweise belegen, wie das vollständige System getrennt ist und wie jede zulässige Übertragung diese Grenze überschreitet.

Primärquellen und aktuelle Implementierungsreferenzen

Die folgenden Quellen legen die Sicherheitsdefinition, aktuelle Muster für getrennte KI-Bereitstellung und Lebenszyklusrisiken dar. Die Verwendung von „air-gapped“ durch Anbieter wird bewusst von der strengeren NIST-Definition unterschieden.