Air-gapped MLOps in der Industrie: Reproduzierbare Modell-Rollouts ohne Cloud, mit deterministischer Latenz und Audit-Trail

Das Problem
Viele Produktionsumgebungen, die KI gerade wirklich brauchen, sind aus gutem Grund vom Internet getrennt. Defense, Bahn-Leitstellen, Brownfield-Fertigung mit sensiblen Lieferketten: Air-gap ist keine Option, sondern Betriebsvorgabe. Das kollidiert frontal mit dem, was die meisten „MLOps“-Best Practices voraussetzen: Managed Services, Cloud-Pipelines, Remote-Telemetrie. Ergebnis: Modelle werden händisch als USB-Zip ausgerollt, Treiber-Drift frisst Latenzbudgets, und im Audit kann niemand erklären, warum am 12.03. um 14:07 Uhr eine gutteilige Charge ausgesondert wurde.

In diesem Artikel beschreibe ich, wie wir KI-Modelle und -Agenten in abgeschotteten Netzen stabil betreiben: hermetische Builds, reproduzierbare Artefakte, deterministische Inferenz-Pfade, signierte Updates über Air-Gap, Observability ohne Cloud – und vor allem: ein auditierbarer Change-Prozess, der in rauen OT-Umgebungen funktioniert.

Architekturgrundlagen: Zwei Netze, eine Diode, null Überraschungen
Die Ausgangslage ist fast immer ähnlich:

  • IT-Zone (Entwicklung/Test): Internetzugang erlaubt, Standard-Tooling (Git, CI, Container-Registry).

  • OT-Zone (Produktion): Kein Internet, restriktive Firewall, oft kein Routing zwischen Zellen, hartes Change-Management.

  • DMZ/Transfer-Zone: Ein definierter Übergabepunkt (idealerweise mit Einwegtransfer – physisch oder logisch), an dem Artefakte verifiziert und übernommen werden.

Konsequenzen für das Design:

  • Upstream ist tot. Jedes Byte, das Sie in der OT brauchen, muss bewusst importiert, versioniert und signiert werden – Treiber, Laufzeit, Python-Wheels, CUDA/OneDNN/ONNXRuntime, sogar Zeitzonen-Datenbanken.

  • Keine „späten“ Entscheidungen. Dynamisches „apt-get“ oder „pip install“ zur Laufzeit ist ein Anti-Pattern. Builds sind hermetisch, zur Not mit vendorten Wheels.

  • Observability und Governance sind on-prem: Metriken, Logs, Model- und Agent-Events laufen in eine lokale Instanz – nicht ins Internet.

Hermetische Builds: Ohne deterministische Artefakte ist alles nachgelagert instabil
Ziel ist, dass ein Modell-Bundle auf einer definierten Zielklasse (z. B. x86_64 + GPU A + Treiber X + Runtime Y) bitgenau reproduzierbar ist. Praktikables Vorgehen:

  • Toolchain pinnen:

  • Compiler, Python-Version, Pip/Conda, Build-Werkzeuge fixieren.

  • Container-Basisimages minimal halten und fest verdrahten; möglichst distro-less oder eine schlanke LTS-Basis.

  • Vendoren statt Ziehen:

  • Python-Wheels für alle Abhängigkeiten aus dem Internet spiegeln und in ein internes, signiertes Wheel-Repository legen.

  • Native Bibliotheken (z. B. CUDA/cuDNN/OneDNN/OpenVINO) als exakt versionierte Tarballs in die Artifactory, nie „latest“.

  • Reproduzierbare Container:

  • Build-Argumente und Umgebungsvariablen einfrieren, deterministische Paketmanager (z. B. Nix/Bazel/Bazelisk) in Erwägung ziehen.

  • SBOM generieren (Software Bill of Materials) – nicht für das Marketing, sondern um Treiber-Drift zu erkennen, bevor die Linie steht.

  • Tests gegen Zielmatrix:

  • Mindestens eine Stage baut das Artefakt gegen die exakten Ziel-Runtimes (z. B. nvidia-container-runtime mit dem definierten Host-Treiber). Keine „läuft schon mit 535.x“-Annahmen.

Modell-Paketierung: ONNX, TensorRT oder doch CPU? Stabilität vor Marketing-Spezifikationen
Die Verpackung des Modells bestimmt, ob Ihr Latenzbudget hält und ob die Ausführung deterministisch ist.

  • Formate:

  • ONNX als neutrales Austauschformat ist sinnvoll, solange die Ziel-Inferenz-Engine es robust unterstützt.

  • GPU-Pfade (z. B. TensorRT) liefern Latenzreserven, aber erhöhen die Komplexität (Kalibrierung bei INT8, Engine-Rebuilds beim geringsten Drift).

  • CPU-Pfade (OneDNN) sind in manchen Brownfield-Anlagen einfacher zu betreiben, wenn 30–50 ms Latenz ausreichend sind und deterministisches Verhalten wichtiger ist.

  • Deterministische Inferenz:

  • Zufallsquellen hart bändigen: Seeds setzen, Algorithmen auf deterministische Varianten pinnen (bei Deep-Learning-Frameworks entsprechende Flags aktivieren).

  • Nicht-deterministische Kernel vermeiden: In GPU-Stacks existieren Pfade, die performance-optimiert, aber nicht deterministisch sind. Diese gezielt deaktivieren und die Auswirkungen messen.

  • Speicher und Threads pre-allokieren: Keine dynamische Allokation im „heißen“ Pfad; feste Thread-Pools, gebundene CPU-Kerne, NUMA-Bewusstsein.

  • Pipeline ohne Kopierschlachten:

  • Zero-Copy-Transfers, Pinned Memory, GPU-Direct (wo verfügbar) – jede Kopie kostet und jittert.

  • GStreamer/DeepStream oder eigenentwickelte C++-Pipelines mit Shared-Memory-Ringen, wenn Latenz unter 10–20 ms zwingend ist.

Edge-Datenpfade: Von Kamera bis SPS ohne Jitter
Ein robuster End-to-End-Datenpfad ist mehr als ein schnelles Modell:

  • Ingestion:

  • Industrietaugliche Kameras mit Hardware-Triggern und stabilem Treiber-Stack. Timestamping nahe an der Quelle, monotone Uhren verwenden.

  • Priorisierte Threads für Erfassung, getrennt vom Inferenz-Thread. Backpressure-Mechanismen statt unendlicher Queues.

  • Entscheidungslogik:

  • KI-Output nie direkt in die Aktorik. Stattdessen eine deterministische Entscheidungslogik (z. B. Regelwerk mit Konfidenz-Schwellen, Mehrheitsentscheid über N Frames, Safe-Fallback).

  • Herzschlag- und Watchdog-Signale in Richtung SPS, damit bei Störung ein definierter Bypass greift.

  • SPS-Integration:

  • Entkopplung über einen dedizierten OPC-UA-Server oder leichte I/O-Koppler. Zeitliche Budgets explizit vereinbaren (z. B. 30 ms Entscheidungsfenster).

  • Schnittstelle strikt versionieren, Payload minimal halten (keine Rohbilder, nur Decisions/Meta).

Signierte Updates über Air-Gap: USB ist kein Prozess
Die Realität: Physischer Transfer bleibt. Aber USB-Sticks sind nicht das Problem – fehlende Signaturen und Prozesse sind es.

  • Artefaktformat:

  • Versionierte, signierte Bundles, die Applikation, Modell, Konfig, SBOM und Migrationsskripte enthalten. Ein Bundle = eine Version = ein Hash.

  • TUF-ähnlicher Prozess (The Update Framework Prinzipien): Trennung von Rollen (Root, Targets), Offline-Root-Keys, delegierte Signaturen für Teams.

  • Transferkette:

  • Build-Pipeline signiert und legt in eine DMZ-Registry/Artifact-Store.

  • Air-Gap-Transfer nur von signierten Exporten, Hardware-Token oder HSM-gesicherte Schlüssel.

  • In der OT: Verifikation gegen ein lokal gepflegtes, nur durch Change-Board aktualisierbares Trust-Anchor-Set.

  • Installation:

  • Atomare Deployments: Blue/Green oder A/B-Slots auf dem Edge-Host. Rollback jederzeit ohne Netz verfügbar.

  • Migrationsschritte idempotent und nachvollziehbar (z. B. DB-Schema, Kalibrierdateien).