• Muss das System bei Netzverlust über Stunden/Tage autark und sicher weiterlaufen?
  • Gibt es Latenzbudgets <200 ms im Mensch-in-der-Schleife, <50 ms in Regelkreisen oder harte Jitter-Anforderungen?
  • Dürfen Rohdaten den Standort verlassen? In welcher Form und in welcher Verzögerung?
  • Wer stellt Identitäten/Schlüssel bereit? Kann dieser Anker unabhängig von Drittanbietern betrieben werden?
  • Welche Bandbreite steht verlässlich zur Verfügung? Was kostet ein dauerhaftes Exfiltrieren?
  • Ist Auditierbarkeit end-to-end erforderlich, inkl. Offline-Fällen?
  • Sind PLC-/Maschinenintegrationen dominierend (OPC UA/TSN)? Wie sieht das Werksnetz aus?
  • Wie werden Modelle/Policies getestet, freigegeben und zurückgerollt?
  • Wie groß ist die Flotte und wie heterogen ist die Hardware?
  • Welche regulatorischen oder vertraglichen Bindungen erzwingen On-Premise-Betrieb?

Mein Fazit

„Cloud-first“ oder „Edge-first“ sind keine Strategien, sondern Dogmen. Im industriellen Kontext ist Souveränität die eigentliche Anforderung. Daraus ergeben sich Latenz-, Bandbreiten- und Governance-Entscheidungen, die bestimmte Architekturbausteine faktisch erzwingen. Inferenz an der Kante, kuratierte Datenlogistik, ein starker, souveräner Hub für Training und Flottensteuerung – so sieht ein tragfähiger Pfad aus. Wer den Control-Plane selbst beherrscht, kann Cloud dort nutzen, wo sie wirklich hilft, ohne das System an Dritte zu verpfänden. Souveränität ermöglicht Intelligenz – in dieser Reihenfolge.

FAQ

Frage 1: Müssen wir komplett auf die Cloud verzichten, wenn Datensouveränität nicht verhandelbar ist?
Antwort: Nein. Die Cloud als Rechen- und Speicherebene kann sinnvoll bleiben, wenn der Control-Plane (Identitäten, Policies, Signaturen, Registries) und kritische Datenpfade souverän beherrscht werden – beispielsweise durch On-Prem-Alternativen und klare Fallbacks. Häufig ist ein Hybridansatz ideal: Inferenz und Entscheidungen am Rand, Training und Flottensteuerung im eigenen Cluster oder in einer kontrollierten, europäischen Cloud.

Frage 2: Wie aktualisieren wir sicher tausende Edge-Geräte mit minimalem Risiko?
Antwort: Signierte, delta-basierte Updates mit gestaffelten Rollouts. Beginnen Sie mit repräsentativen Canary-Gruppen, definieren Sie Metrik-Gates für automatische Abbrüche und halten Sie stets einen funktionsfähigen Rollback bereit. Updates sollten idempotent und atomar sein (z. B. unveränderliche OS-Basis + Container-Workloads). Der Prozess muss offline-tolerant sein; Statusmeldungen werden asynchron nachgeliefert.

Frage 3: Welche Protokolle empfehlen Sie für Command/Control und für Datenströme?
Antwort: Für Command/Control ist MQTT mit mutual TLS, restriktiven ACLs und Retained Messages bewährt. Für Rohdatenströme zwischen Gateway und Zentrale eignet sich ein Streaming-Bus wie Kafka mit Schema-Registry. Für Maschinendaten und PLC-Integration bleibt OPC UA das Mittel der Wahl. Das Muster „OPC UA/Proprietär → Edge-Normalisierung → MQTT intern → Kafka zentral“ hält Komplexität niedrig.

Frage 4: Wie stellen wir sicher, dass keine sensiblen Daten das Werksgelände verlassen?
Antwort: Durchsetzung der Policies am Gateway: Outbound nur whitelisted Topics/Fields, Pseudonymisierung/ Aggregation direkt nach der Erfassung, lokale Persistenz sensibler Rohdaten mit strengem Zugriff. Zusätzlich helfen Shadow-Inferenz und aktive Unsicherheitsmessung: Nur interessante Segmente werden kuratiert exportiert. Governance-seitig: Freigabeprozesse, Signaturen, Audit-Trails – auch offline erfasst und später synchronisiert.

Frage 5: Wie dimensionieren wir Rechenleistung am Rand für ML-Inferenz?
Antwort: Starten Sie vom Latenz- und Durchsatzbudget: Wie viele Inferenzaufrufe pro Sekunde bei welcher Modellgröße und welchem Ziel-Jitter? Wählen Sie darauf bezogen CPU/GPU/TPU-Profile. Planen Sie 20–30 % Headroom für Spitzen und Parallelität (Vorverarbeitung, Kompression, Logging). Messen Sie früh mit realistischen Pipelines, nicht nur mit Modell-Benchmarks, und denken Sie an Thermik und Dauerlast im Gehäuse.

Diese Prinzipien sind nicht theoretisch – sie unterscheiden den Prototypen von einem in der Fläche tragenden System. Wer Souveränität von Anfang an als technische Anforderung durchdekliniert, landet automatisch bei Architekturen, die robust, auditierbar und erweiterbar sind. Und dann wird die Entscheidung „Edge vs. Cloud“ plötzlich rational und reproduzierbar.