KI in einer vollständig isolierten Umgebung betreiben

Was vollständig isoliert wirklich bedeutet

Vollständig isoliert heißt: Die Bereitstellung hat keinen Weg ins öffentliche Internet. Keine Aufrufe von Modell-APIs, keine Telemetrie, keine Lizenzprüfung, keine Paket-Downloads zur Laufzeit, keine Ausnahmen. Alles, was das System braucht, wird vorab in Ihr Netzwerk gespiegelt: Container-Images, Modellgewichte, Embedding-Modelle und jede Abhängigkeit.

Das ist deutlich strenger als „im eigenen Rechenzentrum“ oder „Private Cloud“. Beide behalten meist irgendeinen ausgehenden Weg und hängen oft davon ab. Es ist eine harte Netzwerkisolierung, und die Mühe lohnt sich, weil sie sich belegen lässt: Sie können sie einem Prüfer mit einer Netzwerkrichtlinie nachweisen, statt sie mit einem Diagramm zu beschreiben.

Für die Architektur folgt daraus, dass die Isolierung die erste Vorgabe sein muss und keine spätere Konfiguration. Fast jede Designentscheidung unten ergibt sich daraus.

Orchestrierung: die Basis

Beginnen Sie mit dem, was die Workloads plant und skaliert. Container verpacken jede Komponente in ein portables Image. Kubernetes, oder OpenShift als gehärtete Enterprise-Distribution, orchestriert diese Images auf Ihren eigenen Servern und GPUs.

Das entscheidende Detail ist die Registry. Sie betreiben eine private Container-Registry in Ihrem Netzwerk und spiegeln jedes Image dorthin, damit kein Pod je versucht, etwas von außen zu laden. Das klingt trivial, und genau hier scheitern die meisten Versuche zuerst, meist an einem Basis-Image oder einem Sidecar, von dem niemand wusste. OpenShift bewährt sich in regulierten Umgebungen, weil es standardmäßig mit eingeschränkten Sicherheitskontexten, integrierter Image-Signierung und eingebauten Richtlinien arbeitet. Die Härtung unten beginnt damit von einer besseren Ausgangslage.

Modell-Serving: offene Modelle im Cluster

Weil es kein gehostetes Modell zum Aufrufen gibt, stellen Sie offene Modelle selbst bereit. Ein Inferenzserver wie vLLM oder Text Generation Inference von Hugging Face läuft als Dienst im Cluster, mit GPU-Scheduling, Request-Batching und Autoscaling.

Die Gewichte werden aus vorab bereitgestelltem lokalem Speicher geladen und nie zur Laufzeit abgerufen. Dimensionieren Sie die GPU-Pods nach dem Modell und der Parallelität, die Sie tatsächlich brauchen, nicht nach dem größten verfügbaren Modell. Stellen Sie die Inferenz nur im internen Cluster-Netzwerk bereit, damit von außerhalb Ihres Netzwerks nicht einmal theoretisch etwas erreichbar ist.

Retrieval, das im Netzwerk bleibt

Ein Modell ist nur so nützlich wie das Material, auf das es seine Antworten stützen kann. Deshalb muss auch der Retrieval-Stack in Ihrem Netzwerk liegen: ein Vektorspeicher, ein im Cluster bereitgestelltes Embedding-Modell und eine Ingestion-Pipeline, die Ihre Dokumente indexiert.

Jeder Schritt (Embedding, Speicherung, Abfrage) findet in Ihrem Netzwerk statt, das Quellmaterial wird also zu keinem Zeitpunkt irgendwohin übertragen. Das ist der Unterschied zwischen einem generischen Offline-Chatbot, der nur begrenzt nützlich ist, und einem System, das aus geheimem oder reguliertem Material antworten kann. Genau dafür gibt es die Bereitstellung.

Härtung: nicht nur isoliert, sondern belegbar

Die Isolierung bringt Sie den größten Teil des Weges. Die Härtung macht es möglich, sie Punkt für Punkt jemandem zu belegen, dessen Aufgabe es ist, Ihnen nicht zu glauben.

• Begrenzen Sie den Ost-West-Verkehr mit Netzwerkrichtlinien, damit nur die Komponenten miteinander sprechen, die das müssen, und ein kompromittierter Pod weder das Modell noch den Index erreicht.
• Sichern Sie die Herkunft von Images mit Signierung und Admission Control, damit ein nicht verifiziertes Image nicht läuft, selbst wenn es in die Registry gelangt.
• Bewahren Sie Geheimnisse in einem versiegelten Speicher im Cluster auf, nicht in Umgebungsvariablen oder Manifesten, wo sie in Logs und Backups landen.
• Aktivieren Sie umfassende Audit-Logs, damit sich jede Inferenz und jede Konfigurationsänderung einer Identität und einem Zeitpunkt zuordnen lässt.

Die Schicht, vor der die meisten Anleitungen aufhören

Das Modell zu betreiben ist das Infrastrukturproblem, und es ist das leichtere. Governance wird nicht überflüssig, nur weil das Netzwerk isoliert ist. Auch ein isolierter Assistent kann aus einem schwachen Retrieval-Ergebnis selbstsicher antworten, Material eines Geschäftsbereichs einem anderen zeigen, Zugangsdaten in ein Log schreiben und Sie ratlos lassen, wenn Sie rekonstruieren wollen, was er im letzten März getan hat.

Deshalb gelten in Ihrem Netzwerk dieselben Kontrollen wie außerhalb: eine Konfidenzuntergrenze, unter der das System ablehnt statt zu antworten, die Trennung von Dokumenten zwischen Kunden oder Geschäftsbereichen, Schwärzung und ein vollständiges Protokoll aller Interaktionen. NeuralSeek wird über denselben Container im selben Cluster bereitgestellt und liefert diese Schicht ohne einen einzigen ausgehenden Aufruf. Dazu gehört auch, die bereitgestellten offenen Modelle an Ihrem eigenen Material zu vergleichen statt an einer öffentlichen Rangliste.

Die Infrastruktur macht isolierte KI möglich. Die Governance macht sie sicher genug, um sie tatsächlich jemandem in die Hand zu geben.