Datensouveränität als Architekturprinzip: Wie man eine belastbare Daten- und KI-Infrastruktur für die Industrie baut

Vorweg: In der Industrie scheitern KI-Initiativen selten am Modell. Sie scheitern an Datenlogistik, an fehlender Nachvollziehbarkeit und an Grenzbedingungen wie DSGVO, Exportkontrolle oder Betriebsgeheimnissen. Wer Sicherheit, Nachvollziehbarkeit und Verfügbarkeit nicht als technische Nichtfunktionalitäten, sondern als Primäranforderungen versteht, baut andere Architekturen. Souveränität ist dabei kein politisches Statement, sondern ein Architekturprinzip: Wer seine Datenwege kontrolliert, kann Modelle zuverlässig entwickeln, deployen und betreiben.

Dieser Artikel beschreibt aus Praxisperspektive, wie eine Daten- und KI-Infrastruktur für industrielle Anwendungen aufgebaut wird, die

  • domänenspezifische Daten (Bilder, Zeitreihen, Protokolle, Text) beherrscht,

  • DSGVO-Anforderungen end-to-end adressiert,

  • on-premise funktioniert (und wo sinnvoll mit Cloud koppelt),

  • MLOps als Qualitätsdisziplin verankert,

  • und LLM-basierte Systeme mit Observability und Governance betreibbar macht.

Use Cases als Techniktreiber

Echte Industrie-Workloads sind heterogen. Ein Produktionswerk kann gleichzeitig brauchen:

  • Visuelle Qualitätssicherung: Hochvolumige Bilder/Videos, harte Latenzgrenzen in der Linie, deterministisches Verhalten, Versionierbarkeit der Referenzdatensätze.

  • Prädiktive Instandhaltung: Mehrkanal-Zeitreihen (Vibration, Strom, Temperatur), Streaming-Ingestion, Concept Drift, Edge/On-Prem-Training gegen historische Daten.

  • Flottenintelligenz (z. B. Bahn): Viele Quellen, asynchrone Anbindung, inkrementelle Verarbeitung, robuste Offline-Fähigkeit.

  • Wissensassistenz/LLM für Prozesse: Umgang mit sensiblen Texten, Protokollen und Handbüchern, Auditierbarkeit von Retrieval und Tool-Aufrufen, strenge Zugriffskontrollen.

Diese Mix-Realität bestimmt Architekturentscheidungen stärker als Modebegriffe. Eine Plattform muss Bilder und Binärdaten effizient speichern, Zeitreihen streamen, strukturierte Daten zuverlässig abfragen und Governance lückenlos nachvollziehbar machen.

Data Lake, Data Warehouse, Data Mesh – worum geht es wirklich?

Data Warehouse

  • Stärken: Saubere, modellierte Daten für Berichte, KPI-Definition, stabile SQL-Workloads.

  • Schwächen: Ungeeignet als alleinige Quelle für Rohdaten wie Bilder, große Binärblobs; Schema-Änderungen sind träge; Event- und Streaming-Verarbeitung nur bedingt.

  • Industrie-Einsatz: Finanz-/ERP-nahe Analytik, Compliance-Reporting, Plan/Ist-Auswertungen.

Data Lake

  • Stärken: Kosteneffiziente Speicherung heterogener Rohdaten (Parquet, Avro, Bilder), Schema-on-read, gut für ML-Workloads.

  • Schwächen: Governance- und Qualitätsprobleme, wenn keine Disziplin herrscht (Data Swamp); ACID-Semantik fehlt ohne zusätzliche Schicht.

  • Industrie-Einsatz: Zentrale Rohdatendrehscheibe für ML, Langzeit-Archiv, Feature-Generierung.

Lakehouse (praktisches Pattern)

  • Idee: Data-Lake-Speicher plus ACID-Tabellenformate und Metadaten-Katalog. So lassen sich ML- und BI-Workloads konsistent bedienen.

  • Umsetzung: Objekt-Storage (on-prem S3-kompatibel) + Tabellenformate mit Transaktionen und Time-Travel + Metastore/Katalog + Governance-Layer.

Data Mesh (organisationsseitiges Pattern)

  • Stärken: Datenverantwortung in die Domänen verlagern; klare Verträge (Data Contracts), Data Products mit Ownership; Skalierung über Teams hinweg.

  • Schwächen: Erfordert Reife in Organisation und Plattform; ohne zentrale Leitplanken droht Fragmentierung.

  • Industrie-Einsatz: Mehrwerk- oder Konzernstrukturen, mehrere Sparten mit eigenen Datenprodukten; wichtig ist ein zentrales Plattform-Team als Enablement, nicht als Flaschenhals.

Was passt wann?

  • Visuelle KI und komplexe ML-Pipelines: Lakehouse als technisches Rückgrat; Data Mesh als Organisationsprinzip, sobald mehrere Domänen beteiligt sind.

  • Zeitreihen/Streaming: Event-Backbone (z. B. Log/Messages), persistiert in Lakehouse-Tabellen; optional spezialisierte TSDBs für niedrige Latenz.

  • Klassische BI/Controlling: Warehouse, gespeist aus kuratierten Lakehouse-Zonen.

  • Kleine Organisationen: Starten mit Lakehouse-Kern und klaren Datenzonen; Data Mesh erst einführen, wenn mindestens zwei Domänen eigenständig Data Products verantworten.

DSGVO und Souveränität als Systemanforderung

In industriellen Kontexten reicht „wir verschlüsseln schon“ nicht. Sie brauchen:

  • Datenklassifizierung: Welche Datentypen mit welcher Schutzbedürftigkeit? PII, Betriebsgeheimnisse, Exportkontrolle, Schutz von kritischen Infrastrukturen.

  • Zweckbindung und Minimalprinzip: Für jedes Dataset muss der Verarbeitungszweck definiert und technisch durchgesetzt werden (z. B. getrennte Zonen, Policies).

  • Zugriffskontrolle: RBAC/ABAC bis auf Spalten-/Feldebene; Service-Konten strikt getrennt; Secrets-Management; mTLS zwischen Diensten.

  • Pseudonymisierung/Anonymisierung: PII in Rohdaten vor ML-Verarbeitung entfernen oder pseudonymisieren; Re-Identifikationswege streng kontrollieren.

  • Nachvollziehbarkeit: Datenherkunft (Lineage), wer hat wann worauf zugegriffen, welcher Job hat welche Artefakte produziert; unveränderliche Audit-Logs.

  • Datenresidenz: On-Premise oder EU-Hosting reduzieren Übermittlungsrisiken; hybride Modelle nur mit klarer Trennung sensibler Workloads.

Architekturbausteine für On-Prem ML-Infrastruktur

Compute

  • GPU-Knoten: Planen Sie Workloads (Training vs. Inferenz), Speicherdurchsatz (NVMe), Netz (25/100 Gbit), ggf. GPU-Partitionierung (MIG) für bessere Auslastung.

  • Orchestrierung: Kubernetes für Container-Workloads und Inferenzdienste; Slurm o. Ä. für HPC-ähnliches Batch-Training; Mischbetrieb ist möglich.

  • Scheduling: GPU-Device-Plugins, Topology-Awareness (NVLink), Node-Labels/taints für Trennung von SLOs.

Storage

  • Objekt-Storage (S3-kompatibel on-prem): Zentrale Ablage für Rohdaten, Modelle, Artefakte. Replikation, Versionierung, Bucket-Policies.

  • Lakehouse-Ebene: ACID-Tabellenformate, Time-Travel, Schema-Evolution, Partitionierung.

  • Low-latency-Speicher: NVMe-Cache für Training; getrennter Persistent Storage für State (z. B. Metadaten, Registries).

Datenbewegung und Orchestrierung

  • Ingestion: Konnektoren für Maschinen, SPS, SCADA, MES, ERP, PLM; Edge-Gateways für Offline-Puffer und sichere Weiterleitung.

  • Streaming: Event-Bus für Sensorik und Logdaten; Backpressure-Management statt Blind-Ingestion.

  • Workflows: Containerisierte Pipelines (z. B. orchestriert via Workflow-Engine); idempotent, wiederaufsetzbar; Artefakte strikt versioniert.

Sicherheit und Netze

  • Netzwerksegmentierung: Trennung nach Zonen (Produktion/Office/DMZ), Ost-West-Mikrosegmentierung.

  • Identity & Access: Einheitlicher IdP, kurzlebige Tokens, Service-to-Service-Auth, Secret-Rotation.

  • Observability: Metriken, Logs, Traces; verteiltes Tracing für Datenjobs; saturationsnahe Alerts (GPU, IO, Queue-Lags).

MLOps als Qualitätsdisziplin