Blog
Sicherheit

Air-Gapped-KI: LLMs vollständig offline mit Ollama betreiben

Eine praktische Architektur für KI ohne ausgehende Konnektivität: Ollama als lokales LLM, LanceDB für Vektoren, DLP-Redaktion bei jedem Prompt, alles in einem Offline-Container.

Simmetric Team7 Min. Lesezeit28/05/2026

Warum Air-Gap eine Deployment-Form ist, kein Feature-Flag

Die meisten "self-hosted" KI-Produkte verlieren trotzdem Daten. Hier ein Modell-API-Aufruf, dort eine Embedding-Anfrage, ein Telemetrie-Ping, eine Lizenzprüfung, die nach Hause telefoniert - jedes Einzelne für sich vertretbar, und zusammen bedeuten sie, dass Ihre internen Dokumente, Prompts und Antworten eine Netzwerkgrenze überqueren, die Sie nicht kontrollieren. Für Verteidigungsauftragnehmer, Krankenhäuser, Banken und jede Organisation mit Datenresidenz-Pflicht ist das ein Ausschlusskriterium. Die Anforderung lautet nicht "größtenteils offline" - sie lautet: ein KI-System, das mit gezogenem Netzwerkkabel funktioniert.

Simmetric Chat ist um diese Anforderung herum gebaut. Der Air-Gap-Betrieb ist kein Modus, den Sie freischalten, und kein Plugin, das Sie kaufen: Die Standardkonfiguration der Community-Plattform ist bereits die Offline-Konfiguration - ein lokales LLM, lokale Embeddings, ein dateibasierter lokaler Vektorspeicher und eine Dokumentenpipeline, die niemals das Internet braucht. Dieser Artikel geht jede Schicht durch, die Konnektivität ohne ausgehenden Verkehr möglich macht, und was Sie dafür aufgeben - sehr wenig - wenn Sie den Perimeter schließen.

Der lokale Stack: jede Schicht hat einen Offline-Standard

Ein KI-Chat hat in einer typischen SaaS-Architektur vier externe Abhängigkeiten: das Sprachmodell, das Embedding-Modell, den Vektorspeicher und die Dokumentenpipeline. Die Standards von Simmetric Chat ersetzen alle vier durch lokale Komponenten:

  • Das LLM läuft in Ollama. Der Standard-Provider der Plattform ist Ollama im lokalen Netzwerk, und das Standardmodell (gemma4:latest) wird zur Einrichtungszeit geladen, damit der Chat funktioniert, bevor zur Laufzeit ein Modell-Download stattfindet. Ollama spricht OpenAI-kompatibles HTTP in Ihrem eigenen Netzwerk, und die Provider-Konfiguration zeigt mit einer URL darauf - nicht auf einen Cloud-Endpunkt.
  • Embeddings laufen lokal. Der Standard-Embedding-Provider ist ein lokales Transformers-Modell (384 Dimensionen, läuft in-process im Collector), keine gehostete Embedding-API. Lokale Embeddings sind air-gap-kompatibel per Konstruktion, und die Embedding-Mismatch-Guard sorgt dafür, dass der spätere Wechsel zwischen lokalen und remote Providern sicher ist - das Retrieval degradiert zu Keyword-Suche, bis die Neuindizierung abgeschlossen ist, statt Scores aus gemischten Räumen zu liefern.
  • Vektoren leben in LanceDB. Der Standard-Vektorspeicher ist dateibasiert, liegt im Storage-Verzeichnis des Deployments selbst, mit einer Collection pro Workspace. Kein Vektor-Datenbankserver, kein Netzwerksprung. Qdrant, pgvector und Chroma bleiben für Teams verfügbar, deren Skalierung einen vernetzten Index verlangt, aber nichts erfordert sie.
  • Dokumenten-Parsing geschieht in Ihrem Netzwerk. Der Collector - der Dienst, der Uploads parst, chunkt und einbettet - ist Teil Ihres Deployments. PDFs, Word- und Excel-Dateien, Präsentationen und YouTube-Transkripte werden innerhalb des Perimeters verarbeitet, einschließlich gescannter Dokumente, die über die serverseitige Vision-Modell-OCR-Pipeline laufen, welche ein lokales Vision-Modell verwendet.

Nichts in dieser Liste ist besonders behandelt oder nachträglich angeschraubt. Das Strategie-Pattern an jeder Grenze macht die lokale Option einfach zum Standard-Provider, ausgewählt per Konfiguration wie jeder andere.

DLP: Redaktion, bevor etwas hinausgeht - oder bevor es sich überhaupt bewegt

Ausgehende Konnektivität zu schließen schließt nicht jeden Exfiltrationspfad, denn Inhalte bewegen sich auch innerhalb Ihres Netzwerks: Prompts gelangen in die Plattform, Antworten fließen zu Nutzern hinaus, und beide passieren Chat-Oberflächen, aus denen Menschen kopieren. Der Data-Loss-Prevention-Filter von Simmetric Chat durchsucht beide Richtungen - den eingehenden Prompt und die ausgehende Antwort, einschließlich tokenweiser Streaming-Flushes - und redigiert Treffer, bevor Inhalte gespeichert oder angezeigt werden.

Der Scanner erkennt die PII-Klassen, die im Chat-Kontext zählen: E-Mail-Adressen, Kreditkartennummern, API-Schlüssel und private Schlüssel sowie - hinzugefügt in v0.22 - strukturierte europäische Identifikatoren: italienische Partita IVA, codice fiscale und IBAN, als eingebaute Patterns ausgeliefert, die idempotent und label-verankert sind, damit gewöhnliche Zahlen sie nie auslösen. Die Pattern-Konfiguration wird von Admins verwaltet und ist datenbankgestützt: Aktivieren oder deaktivieren Sie jedes Pattern, fügen Sie bis zu fünfzig eigene Patterns mit Live-Compile-Validierung und Test-Vorschau hinzu, und inspizieren Sie ein Trefferhistorie-Panel, gefiltert nach Quelle.

Die Designabsicht ist, dass DLP die letzte Linie ist, nicht die erste. Die erste Linie ist die Architektur: Mit lokalen Modellen, lokalen Embeddings und lokalen Vektoren gibt es gar keinen Drittanbieter-Endpunkt, den sensible Inhalte erreichen könnten. DLP deckt dann die Pfade ab, die bleiben - Inhalte, die die Plattform in Richtung Ihrer eigenen Nutzer verlassen, oder die ein wohlmeinender Mitarbeiter in einen Prompt einfügt. Es deckt auch die Widget-Oberfläche ab, sodass besuchergerichtete Konversationen auf Ihrer Website von derselben Filterkette redigiert werden, wobei der Audit-Trail Chat- von Widget-Verkehr unterscheidet.

Das Single-Container-Deployment: alles auf einem Host

Den Perimeter zu schließen ist das eine; die Software in einen Perimeter zu bringen das andere. Air-Gap-Umgebungen können in der Regel keinen Compose-Stack aus fünf Diensten bequem betreiben - sie betreiben einen Host mit einem einzigen Image, und je weniger bewegliche Teile, desto weniger Artefakte müssen geprüft und transferiert werden.

Simmetric Chat liefert für genau diesen Fall ein All-in-One-Image als einzelnen Container. Ein Container, überwacht von einem Prozessmanager, führt alles aus: PostgreSQL 16 (mit der pgvector-Erweiterung, zur Image-Build-Zeit aus dem Quellcode kompiliert, also offline installiert), den API-Server, den Dokumenten-Collector und den Widget-Dienst. Der Container exponiert drei Ports - 3000 für die API, 3210 für den Collector, 3211 für das Widget - und überwacht seinen eigenen /api/health-Endpunkt, der den Status von Datenbank, Collector und Festplatte meldet.

Das Image hineinzubekommen folgt derselben Disziplin wie bei jedem anderen Artefakt: Übertragen Sie das Image-Tarball (oder den geprüften Registry-Mirror), laden Sie es und führen Sie es aus. Die Environment-Standards im Image sind Gerüst-Platzhalter - die Produktion überschreibt JWT_SECRET, COLLECTOR_SECRET und den Verschlüsselungsschlüssel über die Umgebungskonfiguration, und der Server schlägt beim Start laut fehl, wenn Produktionsgeheimnisse fehlen, damit ein halb konfiguriertes Air-Gap-Deployment niemals still startet. Nach dem Start sind Software-Updates neue Image-Versionen, keine Paketinstallationen - zu keinem Zeitpunkt des Lebenszyklus ist Internetzugang erforderlich.

bash
# In den Perimeter übertragen, dann:
docker load -i simmetric-chat-all-in-one.tar
docker run -d \
-p 3000:3000 -p 3210:3210 -p 3211:3211 \
-v simmetric-storage:/app/storage \
-e JWT_SECRET=$(openssl rand -hex 32) \
-e COLLECTOR_SECRET=$(openssl rand -hex 32) \
simmetric-chat:all-in-one

Die Modellgewichte folgen demselben Weg. Ollama-Modelle werden auf einem verbundenen Rechner geladen, als Blobs gespeichert und innerhalb des Perimeters importiert - die Plattform behandelt sie danach wie jedes andere lokale Modell. Nichts im Stack telefoniert nach Hause, um ein Modell, eine Lizenz oder sich selbst zu verifizieren: Telemetrie ist standardmäßig deaktiviert, es gibt keine externe Fehlerberichts-Abhängigkeit, und die Lizenzvalidierung ist eine lokale RS256-Signaturprüfung gegen einen eingebetteten öffentlichen Schlüssel.

Was offline noch funktioniert - und was wirklich fehlt

Ein Air-Gap-Deployment sollte ehrlich über seine Ränder sein. Was mit null ausgehender Konnektivität funktioniert:

  • Chat mit lokalen LLMs über Ollama, tokenweise per SSE gestreamt
  • Dokumenten-Upload und -Ingestion - Parsing, Chunking, lokale Embeddings, LanceDB-Vektoren
  • Hybrides Retrieval mit Zitaten, Metadaten-Filterung und Synthese-Pipelines
  • RBAC, Workspaces, Projekte, Audit-Trails und die vollständige Admin-Oberfläche
  • Webhooks (an Ihre eigenen Empfänger zugestellt), Web Push (VAPID von Ihrem eigenen Server) und API-Schlüssel
  • Das einbettbare Widget, das gegen Ihren eigenen Widget-Dienst läuft

Was wirklich fehlt: Cloud-LLM-Provider, gehostete Embeddings, externe Websuche und alles andere, das einen ausgehenden Aufruf erfordert. Das Graceful-Degradation-Design bedeutet, dass jede dieser Integrationen ein Konfigurationszusatz ist, keine Codeänderung - aber der Offline-Standard wird schlicht ohne sie ausgeliefert. Die Plattform startet, bedient Anfragen und verarbeitet Dokumente identisch, ob der Perimeter offen oder geschlossen ist.

Das Ergebnis ist ein KI-Workspace, dessen Sicherheitslage nicht vom Vertrauen in die Datenverwaltung eines Anbieters abhängt, weil kein Anbieter im Datenpfad liegt. Alles, was Ihre Dokumente berührt - das Modell, die Embeddings, der Vektorindex, der Parser - läuft auf Hardware, die Sie besitzen, in einem Netzwerk, das Sie kontrollieren, in einem Container-Image, das Sie auditieren können.

Lies die vollständige Anleitung in der Doku →

Ähnliche Artikel