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

Die meisten Industrieunternehmen scheitern nicht an Modellen, sondern an Infrastruktur. Wenn Datenzufluss, Rechtemanagement, Versionierung und Überwachung nicht sauber gelöst sind, ist jedes ML- oder LLM-Projekt ein Compliance-Risiko. Der eigentliche Engineering-Job lautet: Wie bauen wir eine KI-Infrastruktur, die hochsicher, auditierbar und schnell genug für den Betrieb ist – ohne Daten an Dritte abzugeben und ohne in langsame Freigabeschleifen zu kippen? Dieser Beitrag beschreibt, wie wir Datensouveränität unter DSGVO-Bedingungen praktisch umsetzen: als konkrete Architektur, mit klaren Trade-offs, und mit einem Weg von 0 auf produktiv in 90 Tagen.

Das Kernproblem: Souveränität ist ein Systemthema, kein Checkbox-Thema

Typisches Anti-Pattern: Daten unstrukturiert in einen Cloud-Data-Lake kippen, ACLs darum bauen, „irgendwann“ Data Governance nachrüsten und nebenbei ein paar Modelle trainieren. Ergebnis: Schattenkopien, inkonsistente Sichten, keine belastbare Datenherkunft, fragwürdige Löschkonzepte, rechtliche Unsicherheiten – und Regressionsangst vor jedem Release.

Souveränität setzt dagegen auf:

  • Minimierung: so wenig personenbezogene Daten wie möglich, so kurz wie nötig.

  • Trennung: Daten, Schlüssel, Compute und Netzbereiche sind sauber segmentiert.

  • Nachvollziehbarkeit: jede abgeleitete Artefaktkette ist versioniert und auditierbar.

  • Zweckbindung: Zugriffe sind an Use-Cases gebunden, nicht „wer ist der Nutzer?“ sondern „wozu?“.

Eine souveräne KI-Architektur: Schichten und Bausteine

Wir empfehlen eine schichtweise Architektur, die Data Lakehouse-Prinzipien mit strengem Policy- und Observability-Layer verbindet. Die konkrete Technologieauswahl kann variieren; entscheidend sind die Eigenschaften.

1) Infrastruktur- und Sicherheitsbasis

  • Compute: On-Premises Kubernetes-Cluster mit getrennten Node-Pools für CPU- und GPU-Workloads. GPU-Knoten mit lokalem NVMe-Cache für Trainingsjobs; Netzwerk mit RDMA, wo nötig. Für strenge Umgebungen: Air-Gap oder kontrollierter Diode-Transfer.

  • Storage:

  • Objektspeicher (S3-kompatibel) für Roh- und Kurationsdaten; versioniert.

  • Block-/Dateispeicher für Datenbanken, Artefakte und schnelle Zwischenergebnisse.

  • Netzwerksegmentierung: strikte Zonen (Ingestion, Processing, Model Training, Serving, Management). Ost-West-Traffic über Service-Mesh mit mTLS und Policies.

  • Schlüssel- und Geheimnisverwaltung: zentrales KMS/Secrets-Management; getrennte Aufbewahrung der Schlüssel vom Datenspeicher; regelmäßige Rotation.

  • Härtung und Lieferkette: reproduzierbare Images, SBOMs, Signierung von Container- und Modellartefakten; nur signierte Artefakte dürfen laufen.

2) Datenebene: Lakehouse mit ACID, Versionierung und Data Contracts

  • Einheitliches Tabellenformat auf Objektspeicher mit ACID und Time-Travel (z. B. Iceberg/Delta/Hudi). Es geht um die Eigenschaft: Schema-Evolution, Transaktionen, Snapshot-Isolation sind Pflicht.

  • Datenversionierung: Git-ähnliche Versionierung auf Datasets und Features; Branch/Tag-Strategie für Raw, Curated, Feature.

  • Data Catalog: zentrale Quelle für Schemata, Klassifikation (personenbezogen vs nicht), Herkunft (Lineage) und Aufbewahrungsregeln.

  • Data Contracts: zwischen Quellsystem und Lake definieren, inklusive Validierungsregeln. Fehlende Felder, falsche Einheiten oder Out-of-Range-Werte blockieren die Pipeline früh.

  • Ingestion: Streaming (z. B. über einen Event-Bus) plus Batch; CDC für operative Systeme. Jeder Ingestion-Job hängt an einer Policy-Pipeline (siehe Governance).

3) Governance- und Policy-Layer (Policy as Code)

  • Datenklassifizierung: automatisiert und manuell. PII/PHI/PII-ähnliche Felder werden markiert; Pseudonymisierungsschritte sind Teil der Pipeline, nicht der Ad-hoc-Verarbeitung.

  • DLP und Pseudonymisierung: deterministische Tokenisierung für Join-Fähigkeit, irreversible Hashes mit Salt für IDs, Maskierung von Freitextfeldern. Bei Bildern: automatische Unkenntlichmachung sensibler Bereiche.

  • Zugriffskontrolle: Attributbasiert (ABAC) mit Zweckbindung. Zugriffsentscheidungen betrachten Nutzerrolle, Dataset-Klassifikation, Verarbeitungszweck und Laufzeitbedingungen. Policies sind versioniert, getestet und auditiert.

  • Audit-Logging: unveränderliche, manipulationssichere Protokolle über Datenzugriffe, Policy-Entscheide, Modelltrainings und Servings. Export für Audits.

  • Aufbewahrung und Löschung: Time-to-Live auf Datensatzebene, Tombstones, automatische Downstream-Markierung betroffener Artefakte. Lösch-Workflows bis ins Trainings-Repository.

4) MLOps-Plattform: Reproduzierbarkeit und Rückführbarkeit

  • Orchestrierung: deklarative Pipelines für Feature-Konstruktion, Training, Evaluierung, Validierung und Deployment. Jeder Schritt erzeugt überprüfbare Metadaten.

  • Metadaten/Registry: Modelle, Datasets, Features und Metriken sind verknüpft. Ein Audit kann von einem Modell-Hash zum Rohdatensnapshot nachvollziehen.

  • Trainingsumgebungen: Containerisierte, deterministische Builds; feste Versionspins. Trainingsdaten werden als Snapshots gemountet; Feature-Drift wird gemessen.

  • Governance-Gates: Vor Deployment müssen Validierung, Bias- und Performanzchecks sowie Datenschutz-Checks dokumentiert bestanden sein.

  • Signierte Modelle: Artifacts werden signiert; nur verifizierte Modelle laufen im Serving.

5) Serving und Inferenz: streng segmentiert, protokolliert, zweckgebunden

  • Modell-Serving: getrennte Endpunkte für klassische ML (z. B. Triton) und LLM (inferenzoptimierte Server). GPU-Isolation per Quotas/MIG; JIT-Skalierung innerhalb der Sicherheitszone.

  • RAG/Vector: On-Prem Vektorindizes; Indizes sind pro Zweck/Mandant getrennt. Einbettungen sensibler Texte werden verschlüsselt gespeichert; Embedding-Daten enthalten keine PII, wenn nicht absolut notwendig.

  • Prompt/Response-Kontrollen: Eingaben auf PII prüfen und bei Bedarf redigieren; Ausgaben filtern nach Richtlinien. Prompt-Logs werden gehasht/teilmaskiert, zweckgebunden aufbewahrt und fristgerecht gelöscht.

  • Egress-Kontrolle: Standardmäßig kein externer Traffic. Falls erforderlich, nur über eng gefasste, protokollierte Ausnahmen mit Content-Filter und Data Loss Prevention.

6) Observability und Drift-Überwachung

  • Telemetrie auf Daten-, Feature- und Modellebene: Verteilungen, Qualität, Abweichungen, Latenz, Fehlerraten.

  • Governance-Events: jeder Policy-Treffer, jede Ausnahme, jeder Zugriff wird als Ereignis erfasst.

  • Human-in-the-Loop: Freigabeschleifen für Grenzfälle; Feedback landet wieder im Trainings-Backlog.

DSGVO sauber abbilden: Von der Rechtsgrundlage bis zur Löschung