Datensouveränität in der Praxis: Architektur-Bausteine für DSGVO-konforme KI in der Industrie

Problem zuerst: In der Industrie scheitern viele KI-Initiativen nicht an Modellen, sondern an der Infrastruktur. Der Proof-of-Concept liefert nette Kurven, aber beim Schritt in den produktiven Betrieb brechen die Fundamente weg: unklare Datenhoheit, fehlende Auditierbarkeit, keine Reproduzierbarkeit, Vermischung von personenbezogenen und Betriebsdaten, unkontrollierte SaaS-Abhängigkeiten. Ohne eine saubere, souveräne Daten- und KI-Infrastruktur bleibt jedes ML-Modell eine Randnotiz.

Dieser Beitrag zeigt konkret, wie eine DSGVO-konforme, on-premise-fähige KI-Plattform für industrielle Umgebungen aussieht. Keine Marketing-Schablonen, sondern Architekturbausteine, Deploymentschemata, typische Fallstricke und Trade-offs. Perspektive: Wir bauen solche Systeme – und wir beginnen immer bei der Daten-Pipeline.

1) Souveränität ist eine Systemanforderung, keine Haltungsfrage

Industrie-KI operiert im Spannungsfeld aus:

  • Heterogenen Datenquellen: Maschinen-Telemetrie, Bilddaten, ERP/MES, Instandhaltung, Sensorik, Flotten.

  • Strengen Verfügbarkeits- und Sicherheitszielen: Produktion, Bahn, Verteidigung, Energie.

  • Datenschutz: Personenbezug in Logistik- und Qualitätsdaten, Trainingsdaten für Assistenzsysteme, Support-Tickets, Dokumente.

  • Lieferketten- und IP-Schutz: Konstruktionsunterlagen, Fertigungsparameter, Diagnostikdaten.

Das leitet harte nicht-funktionale Anforderungen ab:

  • Datenlokalität: Wo liegen Rohdaten, Feature-Snapshots, Modelle, Vektordatenbanken?

  • Zugriffssouveränität: Wer darf wann worauf zugreifen? Durchsetzbar, testbar, auditierbar.

  • Reproduzierbarkeit: Jeder Modellstand muss rückführbar auf Daten-Snapshots, Code, Parameter, Policies sein.

  • Reversibilität: Vendor-Lock-in vermeiden; Exit-Strategie ist architektureller Bestandteil.

  • Minimalprinzip: Personenbezug nur, wo nötig. Standardmäßig pseudonymisiert/aggregiert.

Typische Anti-Patterns in der Praxis:

  • Cloud-only MLOps, gehostet außerhalb der EU, inklusive Trainingsdaten und Prompt-Logs.

  • Vector DB als Schnelleinbau, befüllt mit unredigierten Dokumenten (Personenbezug, Betriebsgeheimnisse).

  • Closed-Source-LLM-APIs als Backend für produktive Assistenzsysteme mit sensiblen Daten.

  • Fehlende Datenklassifikation: Dev/QA/Prod mischen sich; Zugriff per „shared credentials“.

2) Leitarchitektur: On-Prem-Lakehouse + Policy-driven MLOps

Wir bauen Plattformen um eine klare Trennung von Datenzonen und eine Policy-Engine, die technische und organisatorische Regeln erzwingt. Ein mögliches Blueprint:

Kernkomponenten

  • Speicher-Backbone:

  • Objektspeicher on-prem (z. B. Ceph, MinIO) als Datenlake-Backend.

  • Tabellenformat mit Transaktionslog (z. B. Apache Iceberg oder Delta Lake) für ACID, Time Travel, Schemaevolution.

  • WORM-Fähigkeiten (Write Once Read Many) für unveränderliche Audit-Logs.

  • Datenzonen:

  • Raw: Unverändert, nur lesbar; strikte Zugriffskontrolle; Retention kurz.

  • Staging/Cleansed: Validierte, bereinigte Daten; Pseudonymisierung/Tokenisierung angewandt.

  • Curated/Feature: Domänenspezifische, dokumentierte Datasets und Features mit Versionierung.

  • Metadaten & Lineage:

  • Data Catalog (z. B. OpenMetadata, Amundsen) mit Glossar, Owner, Data Contracts.

  • Lineage-Erfassung (z. B. OpenLineage) über ETL/ELT-, Feature- und Trainingspipelines.

  • Streaming & Orchestrierung:

  • Ereignisbus (z. B. Kafka/Redpanda) für Telemetrie, Online-Features, asynchrones Inferenz-Feedback.

  • Workflow-Orchestrierung (z. B. Airflow, Argo Workflows) für ETL/ELT, Trainings- und Evaluations-Jobs.

  • Feature- und Modellartefakte:

  • Feature Store (z. B. Feast self-hosted) on-prem, offline/online getrennt; Feature-Views versioniert.

  • Modell-Registry (z. B. MLflow, oder OCI-Registry mit Artifactory) mit Signaturen, Promotierungs-Gates, Evaluationsberichten.

  • Compute-Orchestrierung:

  • Kubernetes on-prem als Standard; GPU-Operator für Scheduling/NCCL-Topologie; Alternativ/ergänzend SLURM für HPC-Jobs.

  • GitOps (ArgoCD/Flux) für deklarative Deployments von Diensten, Pipelines, Modellen.

  • Sicherheit & Schlüssel:

  • Secrets-Management (z. B. HashiCorp Vault), KMS/HSM für Schlüssel, Envelope Encryption.

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

  • Supply-Chain-Sicherheit: Signierte Container (Cosign), SBOMs, Private Registry Mirror.

  • Policy & Audit:

  • Zentrale Policy Engine (z. B. OPA/Rego): Attributbasierte Zugriffskontrolle (ABAC), DSGVO-Regeln, Data Minimization, Zweckbindung, Retention.

  • Audit-Service: Unveränderliche Events zu Zugriffen, Datenbewegungen, Modellaktionen.

Datenschutz und Personenbezug technisch erzwingen

  • PII-Erkennung und -Behandlung:

  • Erkennungs-Services für PII/PHI in Text/Bild (z. B. mit regelbasierten und ML-basierten Scannern).

  • Standardpfad: Pseudonymisierung/Tokenisierung vor Persistierung in Staging; Originale nur im streng geschützten Raw mit verkürzter Retention.

  • Reversible Token nur mit Zugriffspfad über HSM-geschützten De-Tokenisierungsdienst und fein granularen Policies.

  • Datenminimierung by design:

  • Feature-Engineering bevorzugt auf Aggregaten; analytische IDs statt natürlicher Identifikatoren.

  • „Privacy Zones“: Trainingscluster/Workspaces ohne De-Tokenisierungspfad.

  • Rechte betroffener Personen:

  • Identitätsindex (Mapping Pseudonym Person) im HSM-gesicherten Tresor.

  • Löschkaskaden: Datenlake, Feature Store, Vektor-DB, Caches, Backups.

  • Unlearning-Prozesse: Markierung betroffener Datasets, Retrain/Prune-Jobs geplant, modellversionsspezifisch dokumentiert.

Reproduzierbarkeit und Nachvollziehbarkeit

  • Jede Pipeline schreibt:

  • Eingabedataset-IDs (Iceberg Snapshot/Manifest), Code-Commit, Container-Digest, Hyperparameter, Policies, Seed.

  • Evaluationsmetrik, Bias-/Robustheits-Suiten, Datenzeitraum, Freigabeentscheidung mit Begründung.

  • Für den Betrieb:

  • Canary-Rollouts, Shadow-Inferencing, Daten- und Konzeptdrift-Detektion (abgeleitet aus Feature-Verteilungen).

  • Immutable Audit-Pfad verknüpft Daten, Code und Entscheidungen.

3) LLM-spezifische Architekturentscheidungen

RAG on-prem ohne Datenleck

  • Einbettungen lokal erzeugen: Embedding-Modelle on-prem, kein Versand von Dokumenten an Drittanbieter.

  • PII-Schutz in der Vektor-Pipeline:

  • Vorverarbeitung mit PII-Redaktion/Maskierung; wo inhaltlich möglich, semantische Generalisierung (z. B. Gehaltsangaben in Spannweiten).

  • Chunking-Strategie mit Kontextkontrolle (keine Vermischung von Tenants/Domänen).

  • Vektor-Datenbanken on-prem:

  • Optionen: pgvector (PostgreSQL), Milvus, Qdrant; Datenklassifikation und ABAC erzwingen; Verschlüsselung at rest.

  • Abfrage-Governance:

  • Retrieval-Whitelists nach Mandant/Projekt/Use Case.

  • Prompt-Filter, Antwort-Policies, Content-Safety lokal.