Flottenmanagement ist die Stelle, an der Cloud oft Mehrwert liefert – als Control Plane, nicht als kritischer Datenpfad. Für Defense- und isolierte Netze muss die Control Plane lokal gespiegelt werden.

  • Artefakt-Lieferkette:
  • GitOps für deklarative Zustände (Kubernetes/Container), signierte Artefakte, SBOM für jedes Release.
  • Supply-Chain-Sicherheit (z. B. Signaturen entlang der Build-Kette), Policy Enforcement am Edge vor Deployment.
  • Update-Strategien:
  • Canary/Blue-Green auf Edge-Clustern, Wellen-Rollouts nach Standort/Zone, automatische Rollbacks bei SLO-Verletzung.
  • OTA in verbundenen Netzen; Offline-Update via signierten Wechseldatenträgern in Air-Gap-Umgebungen.
  • Integrität und Attestation:
  • Secure Boot, gemessener Boot-Pfad, TPM-gestützte Attestation. Ein Knoten bekommt erst dann Workloads, wenn seine Identität und sein Zustand verifiziert sind.
  • Telemetrie und Health:
  • Heartbeats, Ressourcenauslastung, Modell-Drift-Indikatoren; Backpressure, wenn Übermittlungsfenster klein sind.

Pragmatischer Kompromiss:

  • Cloudgestützte Control Plane, gespiegelt on-prem für Inselbetrieb.

  • Datenebene grundsätzlich on-prem; selektive Exporte über abgesicherte Kanäle, asynchron.

7. Hybrid richtig bauen: Edge-Inferenz, zentrales Training – ohne Souveränität zu verlieren

KI im industriellen Kontext trennt Pflichten: Entscheidungen in Nähe der Sensorik, Lernen unter kontrollierten Bedingungen.

  • Inferenz am Rand:
  • Modelle quantisiert/optimiert (z. B. INT8), deterministische Laufzeitprofile, hardwaregebundene Optimierungen.
  • Shadow- und A/B-Modi lokal, bevor ein Modell „scharf“ geht. Metriken (Latenz, Confidence, Fehlklassen) lokal aufgezeichnet.
  • Features statt Rohdaten exportieren:
  • Für Retraining werden Feature-Drifts, Fehlerlabels, Aggregatstatistiken exportiert. Rohdaten bleiben; Freigaben für Stichproben sind technischer Sonderfall mit expliziter Freigabe.
  • Zentrales Training:
  • Trainingsumgebung unter eigener Kontrolle (on-prem Cluster oder europäische Cloud-Region unter klaren SLAs ohne US-Cloud-Abhängigkeit). Modell- und Datensatzversionierung, reproduzierbare Pipelines.
  • Modell-Registry on-prem gespiegelt, Signaturen verpflichtend.
  • Rollout-Governance:
  • Policies, die festlegen: in welchen Zonen sind welche Modelle erlaubt? Wer darf anlernen? Welche Metriken müssen vor Freischaltung erfüllt sein?
  • Auditfähigkeit: Welche Entscheidung basierte wann auf welchem Modell mit welcher Konfiguration?

Die Governance-Fragen bei LLM-Agenten und bei ML-Edge-Inferenz sind ähnlich: Ohne Observability, Versionierung, klare Policies und Audittrails wird jede KI-Einführung zur Risikoabwägung ohne Netz und doppelten Boden.

8. Sicherheitszonen und Vertrauensgrenzen: zuerst vereinfachen, dann härten

Komplexität ist der Feind der Sicherheit. Ein robustes Zonenmodell hilft, Angriffsflächen zu lokalisieren.

  • Zone 0/1: Steuerungen und sicherheitskritische Netze – keine direkten Verbindungen in höhere Zonen. Gateways mit strikt begrenzten Protokollen.
  • Zone 2: Edge-Compute – Container-Orchestrierung (z. B. k3s/Kubernetes), lokale Broker/Stores, Härtung (nur notwendige Syscalls, Drop Capabilities).
  • Zone 3: Werksaggregation – Kafka/S3-kompatibler Storage on-prem (z. B. MinIO), Analytics, Model Registry.
  • Zone 4: Externe Anbindung – dedizierte egress-Kanäle, Daten-Diode/Proxy, strikte Filter.

Überall: Zero Trust-Prinzipien, mTLS, kurzlebige Zertifikate, minimal notwendige Rechte. Geheimnisse niemals in Images, nur aus lokaler Secret-Engine injizieren.

9. Fallvignetten: Wo Cloud sinnvoll ist – und wo Edge nicht verhandelbar ist

  • Cloud-fähig: Pilotentrainingsplattform
  • Problem: Personalisierte Lernpfade, Flotten-übergreifendes Feedback, Skalierung je nach Kurslast.
  • Architektur: EU-Cloud als Control- und Data-Plane, Multi-Tenant-Isolation, Infrastructure as Code, CI/CD. Daten unter klaren Verträgen, personenbezogene Daten minimiert und verschlüsselt.
  • Warum Cloud? Hohe Elastizität, keine harten Latenz-/Determinismus-Anforderungen im Kernbetrieb, regulatorisch steuerbar.
  • Edge-only: Flottenintelligenz im Bahnnetz
  • Problem: Zustandsüberwachung und Anomalieerkennung für Züge/Weichen in Netzen mit instabiler Konnektivität; sicherheitskritische Entscheidungen lokal.
  • Architektur: Edge-Knoten in Zügen/Depots, lokale Inferenz, MQTT lokal, Werks-/Depot-Kafka on-prem, Control Plane gespiegelt. OTA-Rollouts in Depots, Inselbetrieb unterwegs. Export nur aggregierter Features.
  • Warum Edge? Latenz, Verfügbarkeit (Funklöcher, Tunnels), Souveränität (kritische Infrastruktur), Datenvolumen (Sensorik).
  • Defense: Air-Gap als Norm
  • Problem: Keine externe Konnektivität, strenge Geheimhaltung, kompromisslose Integrität.
  • Architektur: Vollständig on-prem/air-gapped, interner Container-Registry-Mirror, signierte Artefakte, Updates via geprüfte Datenträger, lokal betriebene PKI/KMS, Attestation vor Deployment.
  • Warum Edge? Souveränität, Risikoobergrenze, Determinismus. Cloud spielt hier maximal als Entwicklungsumgebung ohne Produktivdaten eine Rolle.

10. Entscheidungs-Playbook: 7 Fragen für CTOs und Head of Digital

Wenn eine dieser Fragen mit Ja beantwortet wird, ist On-Premise/Edge mindestens für den kritischen Pfad gesetzt:

1) Benötigt ein Teil Ihres Systems deterministische End-to-End-Latenz <100 ms inklusive minimalem Jitter?
2) Muss die Anlage bei WAN-/Internet-Ausfall vollständig funktionsfähig bleiben (inkl. Entscheidungslogik)?
3) Unterliegt der Datenraum strikter Souveränität (z. B. Defense, kritische Infrastruktur), sodass Schlüsselmaterial und Policies ausschließlich unter Ihrer Kontrolle liegen müssen?
4) Überschreiten Rohdatenvolumina die wirtschaftlich sinnvolle WAN-Bandbreite dauerhaft?
5) Führen Cloud-Abhängigkeiten zu inakzeptablen Angriffspfaden oder Compliance-Risiken in Ihrer Sicherheitszonierung?
6) Benötigen Sie Feldintegration mit PLCs/OPC UA, bei der TSN/Layer-2-Determinismus eine Rolle spielt?
7) Gibt es Safety-Funktionen, die harte Verfügbarkeits-SLAs haben, die mit best-effort-Netzen nicht abbildbar sind?

Wenn die Antworten gemischt sind, landet man oft bei Hybrid: Inferenz und Betrieb am Edge, Flottenmanagement/Analytics zentral – aber unter Ihrer Souveränität.

11. Betriebskosten und Evolvierbarkeit: Cloud ist nicht automatisch günstiger

Ein oft übersehener Punkt: TCO hängt nicht nur an Compute-Preisen.