Daten- und KI-Infrastruktur in der Industrie: Architekturentscheidungen, die Souveränität und Praxis verbinden

Aus Engineering-Sicht scheitern die meisten industriellen KI-Initiativen nicht am Modell, sondern an der Dateninfrastruktur. Wer die Pipeline nicht im Griff hat – von OT-Schnittstellen über Speicherformate bis zu Governance und Deployment – zahlt später mit instabilen Systemen, regulatorischem Risiko und ewigem „POC-Theater“. Dieser Beitrag adressiert konkrete Architekturentscheidungen für industrielle Umfelder: Data Lake vs Data Mesh vs Data Warehouse, DSGVO-konforme Datensouveränität, MLOps-Praxis und die Frage On-Prem-GPU-Cluster vs Cloud-Training. Keine Technologie-Show, sondern belastbare Muster und Trade-offs.

Problemrahmen in der Industrie

  • Heterogene Quellen: SPS/PLCs, OPC UA, MQTT, industrielle Bildverarbeitung, Timeseries aus dem Historian, ERP/MES/SCADA, Qualitätsprotokolle, Wartungslogs, CAD/PLM-Daten, Handbücher in PDF.
  • Netzwerk- und Sicherheitszonen: OT/IT-Trennung, Air-Gap-Ansätze, eingeschränkte Bandbreiten, Change-Fenster, Data-Diode-Setups.
  • Regulatorik: DSGVO, Betriebsgeheimnisse, Exportkontrollen; Lieferkette; Auditierbarkeit.
  • Lebenszyklen: Maschinen 10–20 Jahre, Software muss wartbar bleiben, Vendor-Neutralität essenziell.
  • Realtime-Anforderungen: Inferenz am Edge unter Latenz- und Zuverlässigkeitszwängen, harte SLAs.
  • Souveränität: Keine Abhängigkeit von US-Clouds, Datenlokalität, eigene Schlüssel, On-Prem-Betrieb.

In so einem Umfeld ist die erste Architekturentscheidung: Datenlogistik vor Modellwahl. Erst wenn Rohdaten verlässlich, nachvollziehbar und DSGVO-fest fließen, lohnen sich Hyperparameter.

Data Lake, Data Mesh, Data Warehouse – was passt wofür?

Es gibt keine Einheitslösung. In der Praxis kombinieren wir Architekturen entlang von Workloads, Domänenverantwortung und Governance.

Data Warehouse

  • Stärken: Kuratierte, starre Schemata; konsistente KPIs; geeignet für BI/Reporting.

  • Schwächen: Geringe Schema-Evolvierbarkeit; oft teuer bei unstrukturierten Daten (Bilder, PDF, Sensordaten).

  • Industriepraxis: ERP/MES/Finance-Kennzahlen landen sinnvoll im Warehouse. Für ML-Trainingsdaten ungeeignet.

Data Lake

  • Stärken: Günstige Speicherung großer, heterogener Daten (Parquet, ORC, Bilder, Video, JSON); Schema-on-read; gut für ML.

  • Schwächen: Ohne Governance verkommt der Lake zum Sumpf; Datenqualität schwer durchzusetzen.

  • Industriepraxis: Rohbilder aus Kameras, Sensorstreams, unstrukturierte Doku; wichtig: formale Schichten (Bronze/Silver/Gold) und strikte Verträge.

Lakehouse (Data Lake + ACID-Tabellenformate)

  • Stärken: Transaktionen, Time-Travel, Schema-Evolution auf Data-Lake-Speicher; vereinheitlicht BI und ML teilweise.

  • Formate: Delta Lake, Apache Iceberg, Apache Hudi.

  • Industriepraxis: Für ML-Features und reproduzierbare Trainingsschnitte ist ein Lakehouse die tragfähige Basis, vor allem Iceberg/Delta mit Parquet auf objektbasiertem Storage (On-Prem S3-kompatibel).

Data Mesh

  • Idee: Domänen-Teams verantworten „Data Products“ mit klaren Verträgen; föderierte Governance.

  • Gefahr: Ohne starke Plattform- und Governance-Schicht droht Tool-Wildwuchs, Inkonsistenz, Sicherheitslücken.

  • Industriepraxis: Sinnvoll ab einer gewissen Größe (mehrere Werke/Business Units). Kern ist nicht die Autonomie, sondern die Standardisierung: einheitliche Speicherformate, Kontrakte, Sicherheits- und Katalogdienste, die die Domänen nutzen müssen.

Empfehlung für industrielle KI

  • Warehouse behalten für klassische BI.

  • Lakehouse als primäre Grundlage für ML/AI: Rohdaten (Bronze) in nativen Formaten, kuratierte Datasets (Silver) in Parquet + Iceberg/Delta, modellnahe Feature-/Label-Sichten (Gold) mit Data Contracts.

  • Data Mesh selektiv: Domänen-Roadmap, Data-Product-Templates, Freigabeprozess, zentral bereitgestellte „Paved Roads“ (Ingestion-Operatoren, Formatvorgaben, Katalog, Governance).

Konkrete Datenpfade und Formate

  • Ingestion aus OT:
  • OPC UA-Subscriptions, MQTT von Edge-Gateways; Backpressure-resistent per Kafka/Redpanda.
  • Historian-Exporte per Batch (Fensterweise) oder CDC aus MES/ERP (z. B. über Change Data Capture Connectors).
  • Bilddaten: Direktes Schreiben der Kameras/Edge-Gateways in On-Prem-Objektspeicher (S3-API), Metadaten als Parquet-Tabellen.
  • Speicher:
  • Objektspeicher On-Prem (z. B. S3-kompatibel) für Rohdaten; Iceberg/Delta als Tabellenlayer auf demselben Storage.
  • Timeseries: Entweder in Parquet-partitionierten Tabellen (für Batch/Backtesting) plus eine Time-Series-DB (z. B. TimescaleDB) für Online-Analysen.
  • Datenverarbeitung:
  • Batch: Spark auf Kubernetes oder Dask/Ray für verteilte Verarbeitung.
  • Streaming: Kafka Streams/Flink für Feature-Pipelines in Echtzeit; Schema-Registrierung (Avro/Protobuf).
  • Data Contracts:
  • Protobuf/Avro-Schemata, versioniert; Validierung im Ingestion-Path; De-/Serialization als Gate.
  • Qualität und Lineage:
  • Data-Tests (z. B. Expectation-Suites) auf jeder Schicht; technische Lineage über Orchestrator/Katalog; fachliche Lineage als Teil des Data Products.

Datensouveränität und DSGVO – Architektur statt Papier

„DSGVO-konform“ ist kein Aufkleber, sondern eine technische Eigenschaft der Plattform. Kernelemente:

Datenlokalität und Sovereign Operations

  • On-Prem- oder EU-Cloud ohne US-Rechtszugriff; eigene Kryptoschlüssel (HSM oder On-Prem-KMS).

  • Keine Abhängigkeit von externen Foundation-API-Calls für produktive Pfade. Falls externe Services im Prototyp verwendet werden, dann strikt mit anonymisierten Datasets und ohne Produktionszugriff.

Datenminimierung und Pseudonymisierung

  • PII in der Industrie existiert: Schichtpläne, Wartungslogs, Ticketing, Audittrails, Stimme/Video, Office-Dokumente.

  • Pipeline-Pattern:

  • Klassifikation: PII/Secrets-Erkennung beim Ingest (Regeln + ML-basierte DLP).

  • Pseudonymisierung: deterministisch, formatwahrend (z. B. FPE) für IDs, mit Salt in HSM; reversible nur mit strengem Schlüsselzugriff.

  • Anonymisierung bei Bedarf für Analyse (Aggregationen, Rauschen), aber mit Vorsicht bei Timeseries (Re-Identifizierbarkeit!).

  • Retention und Right-to-Erasure:

  • Objekt-Lifecycle-Policies je Bucket/Tabelle; WORM/Legal-Hold nur, wo rechtlich nötig.

  • Löschanfragen: Mapping von Pseudonym zu Original via Key-Escrow, Audit der Löschkette.

Zugriffskontrolle und Audit

  • Zero-Trust, mTLS, Service-Identitäten (z. B. SPIFFE/SPIRE).

  • Feingranulare Policies: ABAC/RBAC via zentraler Policy Engine (Policy-as-Code, z. B. OPA) und einheitliche Durchsetzung (Gateway, Storage, Query Engine).

  • Auditlog end-to-end: Datenzugriffe, Modellabrufe, Prompt-/Kontext-Logging bei LLM-Anwendungen mit On-the-fly-Redaktion (PII-Maskierung).