• Air-Gapped Edge-Cluster: Für Defense/KRITIS. Compute-Knoten mit redundanter Netzwerkstruktur, kein Internet. Datenabfluss nur über genehmigte Export-Pfade (Wechselmedien, Data-Diode). Modell- und Software-Updates als signierte Bundles, geprüft über Offline-PKI.
  • Semi-Connected Edge: „Offline-first“. Edge-Dienste arbeiten autonom, persistieren Ereignisse in einer Append-Only-Log-Form (Event Store). Bei Verbindung synchronisieren sie per Store-and-Forward auf die On-Prem-Backbone. Konflikte werden deterministisch gelöst (Lamport-/Vector-Clocks, Last-Writer-Wins nur als ultima ratio).
  • On-Prem Object Storage: S3-kompatible Buckets hinter der Werkfirewall für Rohdaten, Feature-Store, Modellartefakte. Vorteile: Einfache Integration, kostengünstige Skalierung, klare physische Kontrolle. Kombiniert mit Versionierung und WORM-Policies für Audit.
  • Observability by Design: Metriken, Logs, Traces werden als Erstbürger behandelt. Edge- und On-Prem-Services propagieren eine Trace-ID end-to-end (z. B. über HTTP/gRPC/MQTT-User-Props). In Air-Gap-Szenarien erfolgt späterer Export der Telemetrie im Batch.
  • Zero-Trust intern: Auch im Werk ist jede Service-zu-Service-Kommunikation mTLS-gesichert, autorisiert über SPIFFE-ähnliche Identitäten oder Service-Accounts mit minimalen Rechten. Kein implizites Vertrauen nach „Netzwerkgrenzen“.

Hybrid-Architektur: Edge-Inferenz, zentrales Training – ohne Souveränitätsbruch

Das Muster ist simpel, aber die Umsetzung hat Tücken:

  • Datenerfassung: Edge-Node segmentiert Daten in drei Klassen:

1) Hochsensitiv (bleibt lokal, nur abgeleitete Metriken verlassen die Zelle)
2) Sensitiv (darf On-Prem gespeichert, aber nicht extern transferiert werden)
3) Pseudonymisiert/abgeleitet (für zentrales Training zulässig)

  • Labeling on-prem: Für Computer Vision lohnt sich eine Labeling-Station im Werknetz. So bleiben Rohbilder intern. Für Trainingszwecke verlassen nur Crops oder Feature-Vektoren mit ausreichend Entkopplung das Werk.
  • Trainingsumgebung: Entweder On-Prem-GPU-Cluster oder – wenn Souveränitätskriterien erfüllt sind – eine dedizierte, juristisch passende Cloud-Region für synthetische/abgeleitete Daten. Wichtig ist die klare Trennung: Kein Pull der Rohdaten aus der Edge-Sphäre.
  • Modell-Registry: Modelle werden als immutables Artefakt versioniert, signiert, mit vollständiger Provenienz (Code-Commit, Daten-Schnappschuss, Trainingskonfiguration, Evaluationsmetriken). Die Registry liegt On-Prem; Edge-Nodes akzeptieren nur signierte Modelle bekannter Herausgeber.
  • Rollout-Strategien: Shadow-Mode (inferenziert parallel, ohne zu steuern), Canary (kleiner Prozentsatz der Linien), Health Gates (Latenz, Fehlerrate, Drift-Indikatoren). Rollbacks sind technisch trivial: signiertes Vorgängermodell reaktivieren. Organisatorisch gilt: Freigabeprozesse, Vier-Augen-Prinzip, Auditlog.

Fleet-Management für tausende Edge-Geräte: Kontrolle ohne Cloud-Abhängigkeit

Skalierung passiert nicht zufällig. Die Kernbausteine:

  • Geräte-Identität und Bootstrap: Jedes Gerät besitzt einen hardwaregebundenen Schlüssel (TPM/SE). Beim ersten Kontakt im Werk wird ein Geräte-Zertifikat von der Werk-PKI ausgestellt. Keine „shared secrets“. Der Bootstrap-Server läuft On-Prem.
  • „Device Twin“ als Wahrheit: Konfigurationen, gewünschter Zustand (z. B. Modellversion v17), aktueller Zustand (v16), Health-Status, letzte Seen-Zeit. Aktualisierung über einen kontrollierten Command-Kanal. Idempotent, versioniert, mit Dead-Letter-Queues für Fehlfälle.
  • Update-Pipeline: Artefakte (Container, Modelle) sind signiert. Distribution erfolgt hierarchisch: Zentraler Repository → Standort-Cache → Edge-Geräte. Das reduziert WAN-Last und isoliert Standorte. Updates sind resumable und verifizieren Signatur vor Aktivierung.
  • Kommunikationsrichtung: Edge baut ausgehende, mTLS-geschützte Verbindungen zum Standort-Aggregator auf. Keine eingehenden Verbindungen nötig (NAT-/Firewall-freundlich). Kommandos werden über Long-Polling/WebSocket oder MQTT-Push zugestellt.
  • Zeitdisziplin: NTP/PTP innerhalb des Standorts, um korrekte Zeitstempel und deterministische Joins im Stream Processing zu gewährleisten. Kein Verlass auf Internetzeitserver.
  • Betrieb bei Flaps: Bei intermittierender Konnektivität muss der Edge autonom arbeiten. Die zentrale Flottensteuerung markiert Geräte als „degraded“ ohne Alarmflut. Recovery-Prozeduren sind automatisiert (Backoff, Re-Sync, Snapshot-Delta).

Sichere Agentensysteme in der Produktion: Observability und Policy vor „Magie“

LLM-Agenten, die Dokumente parsen, SOPs anwenden oder Workflows anstoßen, betreiben wir nur unter strenger Beobachtung:

  • Datenzugriffe sind whitelisted: Retrieval nur gegen vordefinierte, On-Prem gehostete Vektorspeicher und Dokumentkorpora. Keine spontane Internetrecherche, keine externen Tools.
  • Policy Engine: Was darf ein Agent ausführen? Beispielsweise: „Maximal 5 Kommandos pro Minute“, „Nie Produktionsparameter ändern ohne menschliche Freigabe“. Policies werden versionskontrolliert und getestet wie Code.
  • Prompt-/Template-Versionierung: Jeder Lauf ist reproduzierbar. Prompt, Tools, Kontexte, verwendete Modelle – alles wird persistiert. Ohne diese Metadaten ist kein Audit möglich.
  • Safety Gates: Output-Filtern, Schema-Enforcement (JSON-Schemas), und bei Abweichung harte Stops. Für Schnittstellen zu OT-Systemen: mensch-in-der-Schleife als Default.
  • Observability: Token- und Latenzmetriken, Fehlerraten, Tool-Call-Historie. In Air-Gap-Setups offline gesammelt und später ins zentrale Observability-System exportiert.

Cloud – ja, aber nur wenn die Rahmenbedingungen passen

Es gibt rationale Cloud-Entscheidungen. Typische, souveränitätsverträgliche Einsatzfelder:

  • Elastisches Training auf synthetischen oder ausreichend anonymisierten Daten, mit klarer Datenklassifizierung und ohne Abfluss von Rohdaten aus der On-Prem-Sphäre.
  • Globale Auslieferung von Lerninhalten, Dashboards oder Benutzerportalen ohne sensible Produktionsdaten.
  • Aggregierte Telemetrie und Benchmarks über mehrere Standorte, wenn Aggregation innerhalb des Werks erfolgt und nur verdichtete, freigegebene KPIs transferiert werden.
  • Simulationen und CI/CD-Workloads, die keine produktionsnahen Daten benötigen.

Und die No-Go-Zonen für Public Cloud bleiben klar:

  • Defense und kritische Infrastruktur mit Air-Gap-/Isolationsanforderungen.
  • Vertrauliche CAD/BOM/IP-Daten, die Wettbewerbsvorteile verkörpern.
  • Produktionsnahe Telemetrie, die Auslastung, Stückzahlen oder Prozessrezepte offenlegt.
  • Personenbezogene Daten aus Hochrisiko-Kontexten, wenn die Datenflüsse und Schlüsselhoheit nicht 100% intern kontrollierbar sind.

Zwei Praxisvignetten: Warum die Entscheidung zählt