• Daten-/Modellversionierung:
  • Datasets als Snapshots (Iceberg time-travel, LakeFS/DVC)
  • Modelle mit Hash, Signatur, Provenienz in Registry
  • Pipelines als Code:
  • Orchestrierte DAGs, deterministische Container, pinned Dependencies
  • Evaluations- und Freigabeprozesse:
  • Standardisierte Metriken je Use Case (z. B. Missed Defects Rate, False Alarm Rate, Latenz)
  • Human-in-the-loop Gates für produktionskritische Releases
  • Drift-/Datenqualitätsmonitoring:
  • Verteilungsshifts, Feature-Range-Checks, Outlier-Quoten
  • Alarme in Betriebssystem (Pager/SIEM), Playbooks für Rollbacks
  • LLM-/Agenten-Governance on-prem:
  • Prompt-/Response-Logging im eigenen Stack; PII-Filter, Policy-Checks vor Ausführung kritischer Aktionen
  • Offline-Evaluierung gegen realistische Szenarien; definierte Tooling-Rechte (Least Privilege)
  • Für LLM-Agenten in industriellen Kontexten empfehlen wir eine dedizierte Observability- und Governance-Schicht, die auf der bestehenden Plattform sitzt und dieselben Souveränitätsprinzipien befolgt (on-prem Deployment, vollständige Auditierbarkeit).

9) On-Prem GPU-Cluster vs. Cloud-Training – Entscheidung an der Daten- und Zweckbindung ausrichten

  • Daten-Schwerkraft:
  • Wenn der Großteil der Trainingsdaten on-prem liegt und nicht aus der Produktion heraus darf, ist on-prem Training naheliegend
  • Latenz und Verfügbarkeit:
  • Edge/Inline-Inferenz braucht lokale Kapazität; Cloud macht Sinn für nicht sensible Vortrainingsphasen – sofern rechtlich/vertraglich zulässig
  • Betriebsfähigkeit:
  • K8s mit GPU-Plugins, Slurm oder gemischt; Monitoring (DCGM), Kapazitätsplanung, Image-Registry on-prem
  • Speicher-Durchsatz und Netzwerk sind oft limitierender als GPU-Anzahl
  • Kosten- und Planbarkeit:
  • Cloud-Bursts sehen flexibel aus, sind aber bei Souveränitätsauflagen oft ausgeschlossen oder schwer auditierbar
  • Eigene Cluster erfordern Disziplin in Auslastungsplanung und Lifecycle-Management

Unter souveränen Bedingungen ist ein moderner, gut automatisierter On-Prem-Stack mit klaren Betriebsprozessen meist die robusteste Lösung.

10) Ein pragmatischer 90-Tage-Plan für den Start

  • Tage 1–15: Inventur und Leitplanken
  • Datenlandkarte: Quellen, Datentypen, Sensitivität, Latenz
  • Architekturentscheidung für den ersten Use Case (Warehouse- vs Lakehouse-zentriert)
  • Table-Format-Entscheidung (Iceberg/Delta), S3-Objekt-Storage Auswahl, Identity/RBAC-Mechanismus
  • Tage 16–45: Minimaler, aber tragfähiger Platform Slice
  • S3-Storage, Kafka, Schema Registry, Orchestrator (Airflow/Argo), Catalog, Policy Engine
  • Bronze/Silver/Gold-Standards als Code; Pseudonymisierungspipeline
  • CI/CD für Datenpipelines und ML-Jobs; Registry für Artefakte
  • Tage 46–75: Erster Domänen-Use-Case live
  • End-to-End-Pipeline: Ingestion → Kuratierung → Feature → Training → Inferenz
  • Datenqualitätstests, Metriken, Drift-Monitoring
  • Tage 76–90: Härtung und Mesh-Vorbereitung
  • Data Product Definitionen, SLOs, Dokumentation im Katalog
  • Rechte-/Rollenkonzepte, Audit- und Lineage-Reports
  • Lessons Learned in Standards gießen; zweiter Use Case andocken

11) Anti-Pattern, die wir in der Praxis meiden

  • Cloud-Referenzarchitekturen 1:1 in Air-Gap-Umgebungen kopieren
  • Ergebnis: unpatchbare Images, kaputte CI/CD, versteckte Abhängigkeiten
  • Zentraler Data Lake ohne Verträge/Standards
  • Ergebnis: Datenmüllhalde, niemand vertraut irgendwas, ML stagniert
  • „Data Mesh“ ohne Plattform
  • Ergebnis: jeder nutzt andere Formate/Tools, Governance nicht durchsetzbar
  • US-SaaS für Logs/Monitoring in sensiblen Bereichen
  • Ergebnis: Compliance-Risiken, intransparent
  • Modelle ohne reproduzierbares Dataset und Freigabeprozess deployen
  • Ergebnis: nicht auditierbar, regressionsanfällig

Fazit

Architekturentscheidungen für industrielle KI sind keine Geschmacksfrage: Sie müssen OT/IT-Realitäten, DSGVO und Souveränität aushalten. Ein Lakehouse-Ansatz mit starken Governance-Mechanismen deckt gemischte Datentypen und ML-Bedürfnisse gut ab. Warehouse-Elemente ergänzen, wo konsistente KPI und Reporting dominieren. Data Mesh ist ein Skalierungsprinzip – aber nur tragfähig mit einer robusten, souveränen Plattform. Wer Pseudonymisierung, Lineage, Reproduzierbarkeit und on-prem Betriebsfähigkeit als Erstklassbürger behandelt, liefert verlässlich produktive KI statt Prototypen.

FAQ

Frage 1: Iceberg, Delta oder Hudi – welches Table-Format soll ich wählen?
Antwort: Entscheidend sind Ihre Laufzeitumgebung und Workload-Profile. Für on-prem Lakehouse mit gemischten Batch/Streaming-Workloads und strikter Schema-Evolution sind Iceberg und Delta beides solide Optionen. Wählen Sie das Format, für das Sie in Ihrem Stack (z. B. Spark/Flink, Catalog-Integration, Engines) zuverlässig Support betreiben können. Technisch wichtig: ACID-Transaktionen, Time-Travel/Snapshots, saubere Partitionierung und ein Katalog, den Sie on-prem kontrollieren.

Frage 2: Wie bringe ich SCADA/PLC-Daten DSGVO-konform in den Lake?
Antwort: Nutzen Sie Edge-Collectoren in der OT-Zone mit:

  • Protokolladaptern (OPC UA/Modbus), Pufferung für Netzunterbrechungen

  • Früher Pseudonymisierung (z. B. Bediener-IDs) und Reduktion auf erforderliche Signale

  • Signierte, versionierte Übertragung in eine DMZ (Kafka) und weiter in S3/Iceberg

  • Konsistente Zeitbasis (NTP), klare Zeitstempelstrategie

  • Policies, die in der Pipeline durchgesetzt werden (Maskierung, Zweckbindung)

Frage 3: Brauche ich für ML zwingend einen Feature Store?
Antwort: Wenn Sie mehrere Modelle oder Teams betreiben, ja. Ein Feature Store erzwingt Wiederverwendbarkeit, Konsistenz zwischen Training und Inferenz und erleichtert Drift-Monitoring. Für einen ersten, isolierten Use Case können kuratierte Gold-Tabellen genügen – aber planen Sie die Migration in einen Feature-Store-Pfad frühzeitig ein, um Wildwuchs zu vermeiden.

Frage 4: Wie sichere ich Reproduzierbarkeit in einer Air-Gap-Umgebung?
Antwort: Bauen Sie Ihren gesamten ML/Daten-Stack als deterministische, versionierte Artefakte:

  • Container-Images aus internem Registry-Mirror, Dependencies gepinnt

  • Datasets als Snapshots (Iceberg Time-Travel/LakeFS), Artefakte in Registry mit Hash/Signatur

  • Pipelines als Code (Argo/Airflow), Konfigurationen versioniert

  • Modell-Freigaben über definierte Gates mit Metriken und Prüfschritten

So können Sie ein Ergebnis jederzeit mit denselben Inputs und demselben Code neu erzeugen.

Frage 5: Echtzeit-Inferenz an der Linie – zentral oder am Edge?
Antwort: Für harte Latenz- und Verfügbarkeitsanforderungen gehört das Modell an den Edge (z. B. Industrie-PC mit GPU) und läuft offline-fähig. Die zentrale Plattform liefert Updates, sammelt Telemetrie und übernimmt Training/Monitoring. Verwenden Sie einen Online-Feature-Store (z. B. Redis) lokal und synchronisieren Sie nur aggregierte Metriken zurück. So bleiben Sie deterministisch, souverän und ausfallsicher.