Trade-offs:

  • Starke Sicherheit ohne Cloud ist möglich, aber nur mit Prozessdisziplin: Schlüsseldrehungen, Zertifikats-Lebenszyklen, Backups.

6) Observability und Governance offline denken

Monitoring „per Push in die Cloud“ ist in regulierten Netzen keine Option. Lokale Telemetrie mit spätem Export, plus Governance-Automation, ist das Muster.

  • Telemetrie:

  • Metriken: Prometheus vor Ort; Föderation an die Zentrale über schmale Fenster.

  • Traces/Logs: OpenTelemetry Collector als Router; lokales Log-Storage (z. B. Loki); Sampling/Redaktion sensibler Felder bereits am Edge.

  • Health-Modelle pro Standort, nicht nur Einzelmetriken (z. B. „Sind alle Inferenzpipelines in SLO?“).

  • LLM-/Agent-Governance:
  • Vollständige Prompt-/Context-Observability on-prem, mit PII-Redaktion vor Persistenz.
  • Policy-Checks vor Response (z. B. Regelsätze gegen Datenexfiltration, Rollentrennung bei Retrieval).
  • Audit-Trails, die nachvollziehen, welche Wissensquelle welche Antwort beeinflusst hat.
  • Solche Funktionen liefert z. B. eine dedizierte Observability- und Governance-Schicht für LLM-Agenten; wichtig ist die On-Prem-Fähigkeit und klare Schnittstellen zu Retrieval, Vektorspeicher und UI.

7) MLOps on-prem: Reproduzierbarkeit statt „Works on my GPU“

Ohne Public Cloud werden die Pipeline-Details wichtig:

  • Build- und Trainings-Pipelines:

  • CI/CD on-prem (z. B. Tekton, Jenkins) mit reproduzierbaren Container-Images.

  • Abhängigkeiten pinnen, Offline-Spiegel für PyPI/Conda, CUDA/Treiberstände versionieren.

  • SBOM-Erzeugung (z. B. Syft) und Signierung aller Artefakte.

  • Modell- und Datenlebenszyklus:
  • Model Registry (z. B. MLflow Registry) mit Stages (Staging/Prod), verknüpft mit Datensatzversionen (z. B. DVC).
  • Feature-Extraktion deterministisch; Feature-Store nur, wenn operative Wiederverwendung nachweislich existiert (sonst erhöht er nur den Betriebsballast).
  • Inferenz:
  • GPU-Scheduling lokal (Kubernetes Device Plugins oder dedizierte Inferenzknoten).
  • Triton/ONNX Runtime/ggml-Stacks on-prem – abhängig von Modellformaten.
  • Canary-Inferenz via Shadow-Traffic und deterministische Metriken (Latenz, Confidence, Abweichungen).

Trade-offs:

  • On-prem MLOps bedeutet mehr Vorarbeit (Caches, Artefaktspiegel). Der Payoff ist Reproduzierbarkeit, Unabhängigkeit und Auditierbarkeit.

8) Update-Strategien in Air-Gapped- oder Low-Connect-Umgebungen

Kein „schneller Hotfix in der Cloud“. Updates müssen planbar, rollbar, auditierbar sein.

  • Bundles als OCI-Artefakte (Container, Helm-Charts, DB-Migrationsskripte, Policies) signiert ausliefern.

  • Staged Rollouts: Lab -> Pilot-Standorte -> Flächendeckend; Canaries über Feature-Flags, nicht nur Deployments.

  • Betriebssystem-/Base-Layer atomic aktualisieren (z. B. OSTree/immutable OS), um Drifts zu vermeiden.

  • Datenbankmigrationen strikt vorwärts- und rückwärtskompatibel; Blue/Green auf Datenebene nur, wenn die Domäne es erlaubt.

  • Digitale Zwillinge/Simulationsdaten für Last- und Szenariotests vor Ort – ersetzt fehlendes Cloud-A/B-Testing.

Trade-offs:

  • Sorgfältige Migrationsdisziplin verlangsamt Feature-Tempo, spart aber Wochen an Incident-Feuerwehr in kritischen Umgebungen.

9) Datensouveränität praktisch: Minimierung, Pseudonymisierung, lokales RAG

Datenschutz ist mehr als „Server in der EU“.

  • Datenminimierung am Edge: Nur benötigte Felder exportieren, standardmäßig pseudonymisieren (z. B. Hash + Salting + Rotationsplan).

  • On-Device-Embeddings und lokaler Vektorspeicher (z. B. Qdrant/Milvus) für RAG; Wissensquellen sind versioniert, referenziert und auditierbar.

  • Kein Outbound-by-default: Egress nur explizit per Policy, standardmäßig blockiert.

  • Protokollierung: Wer hat welche Kopplung (z. B. LLM + Retrieval + Policy) geändert, wann, warum.

10) Architekturbeispiel: Fleet Intelligence für Bahn

Anforderungen:

  • Telemetrie aus 500 Zügen; schwankende Konnektivität; Standorte in 6 Depots.

  • Defektfrüherkennung via ML; Einsichten im zentralen Leitstand und mobil.

  • DSGVO-konforme Verarbeitung; keine Public-Cloud-Nutzung; Auditpflicht.

Referenz-Topologie:

  • Je Zug:

  • Edge-Node (x86/ARM), lokaler Agent mit NATS-Client, Timeseries-DB.

  • ML-Inferenz (z. B. ONNX Runtime) für Anomalien; Pufferung bei Offline.

  • Heartbeat, lokale Health-Checks, Crash-Resilience.

  • Je Depot:
  • NATS-Cluster (JetStream), Object Storage (S3-kompatibel), Prometheus/Loki.
  • GitOps-Agent für Deployments der Depot-Services, lokaler IdP-Spoke für mTLS-Ausstellung.
  • Batch-Export definierter Ereignisse in die Zentrale.
  • Zentrale:
  • Kontroll-Ebene: GitOps, Registry, Policy, IdP, Artefakt-Signing, Audit.
  • Analytik: Kafka-Cluster für Depot-zu-Zentrale-Ingestion, Model Registry, Feature-Pipelines.
  • Leitstand: Web-UI; Rollentrennung (Leitstand/Service/Management).
  • LLM-Assistenz on-prem: RAG mit lokalem Vektorstore; Governance-Layer mit vollständiger Protokollierung.

Betrieb:

  • Updates als signierte Bundles pro Depot ausrollen; Telemetrie föderiert einsammeln.

  • KPIs: Mean Time to Detect, Mean Time to Update, Reproduzierbarkeit der Inferenz (gleiche Hashes von Modell+Features).

11) Kosten- und Organisationsrealität: Minimum Viable Complexity

Komplexität ist eine Schuld, die Sie über Jahre verzinsen. Typische Fehlentscheidungen:

  • Vollwertiges Kubernetes + Service Mesh + zehn Operatoren für ein Drei-Node-Depot – das Team kollabiert im Zertifikatsdreieck.

  • „Echte“ Echtzeitansprüche per Microservices erzwingen – Latency-Jitter zerstört die SLOs.

  • Globale IdP-Architektur nach Enterprise-Handbuch – in Air-Gaps schlicht nicht betreibbar.

Gegenmuster:

  • Starten Sie mit K3s oder Nomad, ohne Mesh. Erst bei nachweislichem Bedarf aufrüsten.

  • Modulmonolith am Edge; Microservices dort, wo Skalierungsprofile trennen.

  • GitOps minimal, aber strikt: ein Repository pro Domäne, klare Rollen, obligatorische Signierung.

  • Runbooks, die auch ein neuer On-Call um 3 Uhr morgens versteht. Chaos-Drills lokal.

Entscheidungs-Checkliste

  • Standorttopologie klar?
  • Ownership je Datenklasse definiert (edge vs. zentral)?
  • Netzwerk-Annahmen dokumentiert (Worst-Case-Latenz, Offline-Dauer)?
  • Datenpfad robust?
  • Event-Backbone mit Store-and-Forward, Quoten, Schema-Evolution?
  • Pseudonymisierung vor dem ersten Persistenzpunkt?
  • Deployments beherrschbar?
  • Signierte Artefakte, reproduzierbare Builds, rollbare Migrationspfade?
  • GitOps und PKI-Prozesse auditiert?
  • Observability ohne Cloud?
  • Föderierte Metriken/Logs/Traces, Redaktionsregeln, Health-Modelle?
  • LLM-/Agentenpfade vollständig nachvollziehbar?
  • Team fit zur Architektur?
  • Können 3–5 Engineers das 24/7 betreiben?
  • Existiert eine Exit-Strategie aus „Experimente“ in „Produkt“?

Mein Fazit