Industrielle KI ohne tragfähige Dateninfrastruktur ist ein teurer Proof-of-Concept-Friedhof

Das wiederkehrende Muster in Fabriken, Flotten und kritischen Infrastrukturen: Ein vielversprechendes ML-Pilotprojekt liefert in der Sandbox gute Kurven, scheitert dann aber zwischen OT-Netzwerk, DSGVO, fehlender Datenqualität und „Wer betreibt das eigentlich dauerhaft?“. Die eigentliche Ingenieursaufgabe ist selten das Modell selbst, sondern die Datenlogistik, Governance und der zuverlässige Betrieb – unter harten Souveränitätsanforderungen, oft on‑premise und teils air-gapped.

In diesem Beitrag zeige ich, wie wir Daten- und KI-Infrastrukturen in der Industrie aufbauen, die diesen Realitäten standhalten: Data Lake vs. Data Mesh vs. Data Warehouse, DSGVO-konforme Architekturen, MLOps im Betrieb und eine nüchterne Abwägung von On‑Prem‑GPU‑Cluster vs. Cloud.

1) Data Lake vs. Data Warehouse vs. Data Mesh – was passt in der Industrie?

Problem zuerst: Industrielle Daten sind heterogen und flüchtig. Sie kommen als

  • hochfrequente Zeitreihen aus SPS/SCADA/Historian,
  • Videostreams und hochauflösende Bilder von Qualitätskameras,
  • unstrukturierte Dokumente (SOPs, Handbücher, Wartungsberichte),
  • Ereignisse aus MES/ERP/PLM,
  • Telemetrie von Flottenfahrzeugen.

Gleichzeitig gibt es klassische BI‑Bedarfe (Kennzahlen, Berichte) und ML‑Bedarfe (Feature‑Engineering, Experimentierfreude, große Volumina). Diese Spannungen lassen sich mit einem einzigen „heiligen“ Architekturpattern nicht auflösen.

  • Data Warehouse: Stark für strukturierte, kuratierte Daten und BI‑Berichte. Schwach bei Semistrukturiertem/Unstrukturiertem, Schemaevolution, Rohdatenhaltung und ML‑Workloads. Typisch: SQL‑Marts, star/snowflake‑Schemas, ETL/ELT mit stabilen Contracts.
  • Data Lake: Stark für Rohdaten aller Formate, günstige Skalierung, ML‑freundlich (Parquet/ORC, Spaltenformate, Schema‑on‑read). Schwach, wenn Governance, Qualität und Zugriffssteuerung fehlen – aus Lakes werden sonst „Swamps“.
  • Data Mesh: Kein Tool, sondern ein Organisationsmodell: Domänen (z. B. Instandhaltung, Qualität, Betrieb) sind für ihre „Datenprodukte“ verantwortlich – inklusive Schema, SLOs, Dokumentation, Zugriff. Erfordert eine starke Plattform (Self‑Service Standards, Katalog, Observability, Policies) und klare Ownership.

In der Praxis funktioniert in der Industrie ein hybrider Ansatz:

  • Lakehouse als Substrat: Objekt‑Storage mit tabellarischer Schicht (z. B. via Formaten wie Parquet und tabellenähnlichen Metadaten mit Iceberg/Delta‑Prinzipien), sodass sowohl ML als auch transaktionale Upserts/Time‑Travel möglich sind. Hier leben Rohdaten (bronze), bereinigte/angereicherte Daten (silver) und kuratierte Datensichten (gold).
  • Warehouse für traditionelle BI: Dedizierte Marts werden aus der gold‑Schicht versorgt. Das sichert Performanz für Berichte, ohne ML‑Freiheit zu opfern.
  • Mesh als Organisationsprinzip: Die Plattform liefert Standards, Katalog, Governance und Self‑Service; die Fachbereiche veröffentlichen versionierte, qualitätsgesicherte Datenprodukte mit klaren SLAs und Zugriffspolicies.

Konkrete industrielle Abbildung:

  • Zeitreihen und Ereignisse: Ingest als Avro/Protobuf‑schematisierte Streams; Persistenz als Parquet‑Partitionen (z. B. by plant/machine/date), plus Timeseries‑Index für Abfragen. Historian‑Dumps werden in die bronze‑Schicht überführt.

  • Bild/Video: Rohdaten auf Edge komprimiert und stichprobenartig/ereignisgesteuert in den Lake synchronisiert. Annotationen als separate, versionierte Datenprodukte mit strikter Referenzierung (keine losen CSVs auf Fileshares).

  • Dokumente: OCR‑Pipeline, semantische Indizierung, Metadatenkatalog. Revisionssichere Ablage (WORM‑Buckets) für Audit‑Pflichten.

Wesentliche Trade‑offs:

  • Kuratierung vs. Agilität: Zu viel Vorabmodellierung bremst ML; zu wenig Governance macht unbetriebsfähig. Bronze/Silver/Gold diszipliniert die Evolution.

  • Zentral vs. domänenorientiert: Zentralteams vermeiden Tool‑Wildwuchs; Domänen kennen die Daten. Data Mesh löst das durch „federated governance“: zentral definierte Standards, dezentral verantwortete Datenprodukte.

  • Echtzeit vs. Batch: „Echtzeit überall“ ist unnötig teuer. Meist reichen Minutenlatenzen; Echtzeit nur dort, wo Safety/Prozesssteuerung es zwingend erfordert.

2) Datensouveränität und DSGVO: Architektur statt Checkboxen

Im Industriekontext ist „nur Maschinendaten“ eine trügerische Annahme. Personenbezug taucht schnell auf – etwa in:

  • Bediener‑Events im MES (Schicht, Benutzer‑IDs),

  • Videoaufnahmen mit Personen im Sichtfeld,

  • Wartungsprotokollen und Ticketsystemen,

  • Telemetrie mit Standortdaten.

Souveränität heißt: Datenverarbeitung so gestalten, dass keine unkontrollierten Abflüsse entstehen und Rechtsgrundlagen eingehalten werden – technisch und organisatorisch.

Bausteine einer DSGVO‑konformen, souveränen Architektur:

  • Datenminimierung am Edge: Pseudonymisierung/Maskierung möglichst vor der Übertragung. Beispiel: Gesichter/Personen in Produktionsvideos am Edge schwärzen; Benutzer‑IDs in Ereignissen durch Domänen‑Pseudonyme ersetzen.

  • Segmentierung und Zonen: Trennung OT/IT (z. B. gemäß ISA/IEC 62443), dedizierte DMZ‑Gateways, wo Datenbroker (z. B. MQTT/Kafka‑Bridge) stehen. Für High‑Sovereignty‑Setups: Einweg‑Replikation via Data Diode.

  • Verschlüsselung by default: mTLS in allen Services; Verschlüsselung at rest (z. B. LUKS, S3‑Side‑Encryption). Schlüsselverwaltung on‑prem (HSM/KMS), keine Abhängigkeit von US‑Cloud‑KMS.

  • Identität und Zugriffe: Zentrale IAM (z. B. OIDC/SAML), fein‑granulare ABAC/RBAC‑Policies, durchsetzbar im Storage (Bucket‑Policies), im Query‑Layer (Row/Column‑Level Security) und in den Tools. Policy‑as‑Code (z. B. OPA‑Gatekeeper‑Prinzipien) für Reproduzierbarkeit.

  • Datenverträge und Katalog: Jedes Datenprodukt hat Schema, Verantwortliche, Zweck, Rechtsgrundlage, Aufbewahrungs‑ und Löschregeln. Data Lineage mit automatischer Erfassung (OpenLineage‑Prinzip), um Compliance‑Fragen zu beantworten: „Welche Modelle haben welche personenbezogenen Felder gesehen?“

  • Edge‑Retention und selektive Synchronisierung: Hohe Datenvolumina (Video/Rohsensorik) werden nur bei Ereignissen/Lernbedarfen in die Zentrale geholt. Damit reduzieren sich Risiko und Bandbreitenbedarf.

Konsequente Entscheidung: Für sensible Domänen vermeiden wir Abhängigkeiten, bei denen außereuropäische Rechtszugriffe drohen. On‑premise oder EU‑Souverän‑Clouds, offene Standards, Self‑Hosting von Kernbausteinen (Object Store, Catalog, Pipelines), um Auditierbarkeit und Kontrolle sicherzustellen.

3) MLOps in der Industrie: Trainieren, deployen, überwachen – unter Betriebszwängen

MLOps ist nicht „ein Tool“, sondern ein Workflow, der technische und organisatorische Risiken abfedert. In industriellen Umgebungen verschärfen sich einige Anforderungen: