• Cloud-basierte Pilotenausbildung: Hier war Cloud richtig. Trainingsinhalte skalieren global, Lastspitzen während Kursstarts sind ideal für elastische Ressourcen. Die entscheidende Architekturentscheidung: strikte Trennung zwischen Lerninhalten und personenbezogenen Leistungsdaten; sensible Daten wurden regional begrenzt und stark minimiert. Latenzanforderungen sind moderat – Video-Streaming und Interaktion tolerieren Netzjitter. Ergebnis: Hohe Verfügbarkeit, schnelles Feature-Tempo ohne Souveränitätskompromisse.
  • On-Prem Fleet Intelligence im Bahnkontext: Tausende Fahrzeuge, schlechte und unvorhersehbare Konnektivität. Architektur als Event-Sourcing-System: Lokale Edge-Nodes filtern, aggregieren, klassifizieren Ereignisse, persistieren sie append-only. Bei Verbindung synchronisieren sie zum Standort-Backbone, der wiederum zentrale Analysen versorgt. Modelle werden gestaffelt ausgerollt, Shadow-Mode validiert neue Versionen. Kein externer Cloud-Abhängigkeitspunkt – der Betrieb bleibt auch bei landesweitem WAN-Ausfall funktionsfähig.

Checkliste: Edge-/On-Prem-Bereitschaft

  • Haben wir ein Latenzbudget pro Anwendungsfall, inklusive Reserven für Outliers?
  • Ist unsere Protokollkette klar: OPC UA an der Zelle, MQTT zum Aggregator, Kafka im Rechenzentrum – mit defined boundaries?
  • Existiert eine PKI, die Geräte- und Service-Identitäten ausstellt und rotiert?
  • Sind Artefakte (Container, Modelle) signiert, und verifizieren Edge-Nodes vor Aktivierung?
  • Haben wir eine Observability-Story, die auch ohne Internet greift?
  • Ist die Datenklassifizierung implementiert und technisch erzwungen?
  • Haben wir einen getesteten Rollback-Pfad für Modelle und Software?
  • Sind Policies für Agenten-/Automationsaktionen als Code definiert und auditiert?

Häufig gestellte, technische Fragen

1) Wie validiere ich ein Latenzbudget, bevor die Anlage live geht?

  • Messen, nicht schätzen. Bauen Sie einen synthetischen Workload-Generator am Edge, der reale Sensor- und Aktorpfade simuliert. Instrumentieren Sie jeden Schritt mit Zeitstempeln (ingest → preprocess → infer → decide → actuate). Testen Sie unter Störszenarien: Drosselung der CPU, Netzjitter, Paketverlust. Das 99,9-Perzentil und die Maximalwerte sind Ihre Leitplanken. Legen Sie dann harte Timeouts und Fallback-Aktionen fest.

2) Wie kombiniere ich OPC UA und Kafka sicher und verlustfrei?

  • Nutzen Sie dedizierte Bridge-Services mit klarer Verantwortung: UA-Subscription mit Quality-of-Service, Mapping auf interne einheitliche Schemas, idempotente Producer in Kafka. Fehlerfälle: Bei UA-Verbindungsabbruch Puffern im Bridge-Node (persistenter Ringbuffer). Bei Kafka-Backpressure Priorisierung von kritischen Signalen. Security: mTLS zu beiden Seiten, Least-Privilege-ACLs, Zertifikatsrotation über Ihre PKI.

3) Wie rolle ich neue Modelle aus, ohne die Produktion zu stören?

  • Standardvorgehen: Shadow-Mode auf repräsentativer Stichprobe, automatisches Scoring gegen Ground-Truth-Proben oder heuristische Qualitätsmaße (Konfidenzen, Drift-Indikatoren). Canary-Rollout auf 5–10% der Stationen, Health Gates (Latenz, Fehlerrate) als K.o.-Kriterium. Rollback ist ein API-Call, kein Projekt. Voraussetzungen: Signierte Modelle, deterministischer Feature-Pipeline, reproduzierbarer Preprocessing-Code.

4) Wie verhindere ich Datenexfiltration durch Agentensysteme oder Tools?

  • Whitelist-basiertes Tooling, kein generischer Netzwerkkonnektor. Retrieval nur gegen On-Prem-Stores. Response-Filter, die strukturierte Ausgaben erzwingen. Policies, die externe Calls komplett deaktivieren. Und: Ein konsequentes Ausführungslog, das jede Anfrage, jeden Kontext und jede Aktion persistiert – so wird Exfiltration nicht nur erschwert, sondern auch nachweisbar.

5) Wie orchestriere ich Updates in Netzen mit schlechter oder intermittierender Konnektivität?

  • Hierarchische Distribution mit Standort-Caches, Resume-fähige Downloads, Content-Addressing (Hash-basierte Integritätsprüfung) und Bandbreitenfenster außerhalb der Spitzenzeiten. Kommandos mit TTL und Acknowledge-Protokoll. Kein „ssh in die Anlage“ – stattdessen ein deklarativer Zielzustand pro Gerät und ein Agent, der lokal konvergiert. Im Fehlerfall automatische Retries mit Exponential Backoff; nach N Fehlversuchen Quarantäne und manueller Eingriff.

Fazit: Souveränität ist ein Architekturmerkmal, kein „nice to have“

Cloud ist ein Werkzeug. In Trainings- und Distributionsszenarien mit klarer Datenklassifizierung kann sie Zeit und Kosten sparen. Aber sobald Latenz und Determinismus harte Grenzen setzen – oder sobald Daten, Schlüssel und Prozesse unter Ihrer Hoheit bleiben müssen – führt kein Weg an Edge und On-Premise vorbei. Die gute Nachricht: Die notwendigen Bausteine sind ausgereift. Mit einer klaren Protokollkette (OPC UA/MQTT/Kafka), einer robusten Update- und PKI-Story, deterministischen Datenpfaden und strikter Observability lassen sich Industrial-AI-Systeme bauen, die gleichzeitig modern, auditierbar und souverän sind.

Und wenn Sie Agentensysteme in diesen Kontext bringen, gilt umso mehr: Observability und Governance zuerst, dann Automatisierung. Wer das beherzigt, baut Systeme, die auch in zehn Jahren noch betreibbar sind – unabhängig von der nächsten Plattformmode. Souveränität ermöglicht Intelligenz. Genau so.