DSGVO Art. 25 in der Praxis: Wie wir Datenschutz in die KI-Infrastruktur eingebaut haben
Art. 25 verlangt Datenschutz durch Technikgestaltung — nicht als Nachgedanken. So haben wir jede Anforderung auf konkrete Infrastrukturentscheidungen abgebildet: NetworkPolicies, Spaltenverschlüsselung, Row-Level Security und pseudonyme Token-Bridges.
Was Art. 25 tatsächlich verlangt
DSGVO Art. 25 Abs. 1 verlangt vom Verantwortlichen, „geeignete technische und organisatorische Maßnahmen — wie etwa Pseudonymisierung — zu treffen, die dafür ausgelegt sind, die Datenschutzgrundsätze [...] wirksam umzusetzen und die erforderlichen Garantien in die Verarbeitung aufzunehmen." Diese Maßnahmen müssen unter Berücksichtigung „des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung" bestimmt werden.
Art. 25 Abs. 2 ergänzt eine Datenminimierungsregel: Der Verantwortliche muss sicherstellen, dass „durch Voreinstellungen nur personenbezogene Daten, deren Verarbeitung für den jeweiligen bestimmten Verarbeitungszweck erforderlich ist, verarbeitet werden." Dies gilt für den Umfang der erhobenen Daten, das Ausmaß der Verarbeitung, die Speicherfrist und die Zugänglichkeit.
Erwägungsgrund 78 konkretisiert die Intention: Verantwortliche sollen „interne Strategien festlegen und Maßnahmen ergreifen, die insbesondere den Grundsätzen des Datenschutzes durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen Genüge tun," darunter „die Minimierung der Verarbeitung personenbezogener Daten, die schnellstmögliche Pseudonymisierung personenbezogener Daten, Transparenz in Bezug auf die Funktionen und die Verarbeitung personenbezogener Daten."
Die meisten Organisationen behandeln diese als Richtlinienanforderungen. Wir haben sie als Architekturanforderungen behandelt.
Der Split-Knowledge-Ansatz
The Veil erzwingt eine strukturelle Invariante: Sandbox A kennt das WER (Identität, personenbezogene Daten). Sandbox B kennt das WAS (KI-Inferenzen, Verhaltensdaten). Sie können nicht direkt kommunizieren. Die einzige Verbindung zwischen ihnen ist die ID Bridge, die opake, nicht umkehrbare pseudonyme Token ausstellt.
Dies ist keine Schwärzung auf Anwendungsebene. Ein Schwärzungsfehler legt personenbezogene Daten offen. Unsere Trennung wird auf der Kubernetes-Netzwerkebene durchgesetzt — die KI-Verarbeitungsumgebung hat keine Netzwerkroute zum Identity Vault. Der Durchsetzungsmechanismus ist Infrastruktur, nicht Code.
Abbildung von Art. 25 auf Infrastruktur
| Anforderung nach Art. 25 | Umsetzung in The Veil | Konkrete Technologie |
|---|---|---|
| Pseudonymisierung „so früh wie möglich" (Erwägungsgrund 78) | Gateway entfernt Identitätsdaten vor Weiterleitung an die KI-Sandbox; nur opake Token erreichen Sandbox B | ContextValidator im Gateway mit Regex-basierter PII-Erkennung für E-Mail, SSN, IBAN, Kreditkarte, Telefonnummern |
| Datenminimierung durch Voreinstellungen (Art. 25 Abs. 2) | Sandbox B erhält nur freigegebene Kontextschlüssel pro Branche und Anwendungsfall; alle anderen Felder werden abgelehnt | Branchenspezifische ContextConfig mit allowed_context_keys-Map und max_context_value_length-Limits |
| Technische Maßnahmen zum Zeitpunkt der Verarbeitung (Art. 25 Abs. 1) | Identitäts- und KI-Sandboxes laufen in getrennten Kubernetes-Namespaces mit Deny-All-Default-NetworkPolicies | default-deny-all-NetworkPolicy in jedem Namespace; explizite Egress-Regeln pro Dienst |
| Integration von Garantien in die Verarbeitung (Art. 25 Abs. 1) | Spaltenverschlüsselung für hochsensible Felder; Row-Level Security isoliert Mandantendaten | AES-256-GCM mit versioniertem Schlüsselpräfix in crypto.go; PostgreSQL-RLS-Policy vertical_isolation auf der Tabelle identities |
| Einschränkung der Zugänglichkeit durch Voreinstellungen (Art. 25 Abs. 2) | Sandbox-B-Egress auf den Audit-Dienst beschränkt; kein Pfad zu Identitätsdaten | ai-egress-NetworkPolicy erlaubt nur dsa-audit:50051 und Intra-Namespace-Verkehr |
| Maßnahmen nach dem Stand der Technik (Art. 25 Abs. 1) | Durchsetzung auf Infrastrukturebene statt anwendungsseitiger Kontrollen | Kubernetes NetworkPolicy mit namespaceSelector und Port-Beschränkungen über 7 Namespaces |
Wie das Gateway personenbezogene Daten entfernt
Der Gateway-Dienst (dsa-edge) ist die einzige Komponente, die sowohl die Identität des Benutzers als auch das Inferenz-Token sieht. Er leitet niemals beides an denselben nachgelagerten Dienst weiter. Bevor eine Anfrage Sandbox B erreicht, durchläuft sie zwei PII-Filterschichten:
- Kontextschlüssel-Whitelisting. Der
ContextValidatorführt eine Map vonBranche -> Anwendungsfall -> erlaubte Schlüssel. Wenn ein Client eine Inferenzanfrage sendet, wird jeder Kontextschlüssel, der nicht auf der Whitelist steht, sofort abgelehnt. Existiert keine Whitelist für ein Branche/Anwendungsfall-Paar, arbeitet der Validator im Fail-Closed-Modus — jeder nicht-leere Kontext wird verweigert.
- PII-Mustererkennung. Jeder Kontextwert wird gegen kompilierte Regex-Muster für E-Mail-Adressen, Telefonnummern, Sozialversicherungsnummern, Kreditkartennummern und IBANs geprüft. Der Scanner normalisiert Werte zudem durch URL-Dekodierung und Base64-Dekodierung, um Encoding-basierte Umgehungsversuche zu erkennen. Nicht-ASCII-Zeichen lösen eine sofortige Ablehnung aus, da Unicode-Lookalikes ASCII-Regex-Muster umgehen können.
Auf dem Rückweg prüft ein separater DLP-Scanner (dlp.Scanner) KI-generierte Antworten, bevor sie den Client erreichen. Wenn das LLM personenbezogene Daten aus den Trainingsdaten halluziniert, ersetzt der Scanner Treffer durch getaggte Platzhalter wie [REDACTED-EMAIL] oder [REDACTED-IBAN], setzt dlp_redacted: true in der Antwort und erzeugt ein Audit-Event mit Muster-Trefferzahlen.
Spaltenverschlüsselung im Identity Vault
Beim Design des Identity Vault (Sandbox A) haben wir AES-256-GCM für die Spaltenverschlüsselung sensibler Felder gewählt. Die Spalte sensitive_fields in der Tabelle identities speichert verschlüsselte Bytes im Format [version:1byte][nonce:12bytes][ciphertext+tag]. Das Versionspräfix ermöglicht Schlüsselrotation, ohne alle Zeilen auf einmal neu verschlüsseln zu müssen — neue Schreibvorgänge verwenden die aktuelle Schlüsselversion, und Lesevorgänge prüfen das Versionsbyte zur Auswahl des richtigen Entschlüsselungsschlüssels.
Für die Durchsuchbarkeit verschlüsselter Felder berechnet das System HMAC-SHA256-Blind-Indizes. Die Spalten email_hash und sensitive_hash speichern diese Werte und ermöglichen Exact-Match-Abfragen, ohne jede Zeile entschlüsseln zu müssen. Dies erfüllt das Datenminimierungsprinzip nach Art. 25: Die Datenbank kann einen Datensatz über seinen Blind-Index finden, ohne den Klartext der Abfrage-Engine offenzulegen.
Row-Level Security für Mandantentrennung
PostgreSQL Row-Level Security erzwingt die vertikale (mandantenspezifische) Isolation direkt auf Datenbankebene:
`sql
ALTER TABLE identities ENABLE ROW LEVEL SECURITY;
CREATE POLICY vertical_isolation ON identities
USING (vertical = current_setting('app.current_vertical', true));
ALTER TABLE identities FORCE ROW LEVEL SECURITY;
`
Die Direktive FORCE ROW LEVEL SECURITY gilt selbst für den Tabelleneigentümer und bietet Defence-in-Depth. Wenn app.current_vertical in der Sitzung nicht gesetzt ist, sind keine Zeilen sichtbar — ein sicherer Standard, der versehentliche mandantenübergreifende Datenoffenlegung verhindert. Dies bildet direkt Art. 25 Abs. 2 ab: Die Datenzugänglichkeit ist durch Voreinstellungen beschränkt, nicht durch Richtlinien.
Netzwerkisolation: Die zentrale Invariante
Das Helm-Deployment umfasst 16 NetworkPolicy-Ressourcen über 7 Namespaces (dsa-edge, dsa-identity, dsa-bridge, dsa-ai, dsa-audit, dsa-observability, dsa-ingest). Jeder Namespace beginnt mit einer default-deny-all-Policy, die sämtlichen Ingress und Egress blockiert. Dienste erhalten dann explizite, minimale Egress-Regeln.
Die kritischen Policies:
- `dsa-identity` (Sandbox A) kann
dsa-bridge:50052unddsa-audit:50051erreichen. Es gibt keine Egress-Regel zudsa-ai. Das ist die zentrale Invariante: Der Identity Vault kann keine Daten an die KI-Sandbox senden. - `dsa-ai` (Sandbox B) kann
dsa-audit:50051und Intra-Namespace-Pods (Redis, Ollama) erreichen. Es gibt keine Egress-Regel zudsa-identity. Die KI-Sandbox kann keine Identitätsdaten abfragen. - `dsa-bridge` kann
dsa-ainur auf Port50055erreichen — einem dedizierten gRPC-Endpunkt für Token-Rotation. Port50054(Inferenz-Endpunkt) ist nicht erreichbar, was Least-Privilege selbst innerhalb des Bridge-zu-KI-Pfads durchsetzt. - `dsa-ai` externer Egress für Cloud-LLM-Anbieter wird über
global.llmEgressEnabledgesteuert und ist auf Port 443 beschränkt, wobei RFC-1918- und Link-Local-Adressen ausgeschlossen werden, um den Zugriff auf Cloud-Metadaten-Endpunkte unter169.254.0.0/16zu blockieren.
Der Markt bewegt sich Richtung Infrastruktur-Durchsetzung
Der Markt validiert diese Richtung. Gartner prognostiziert KI-Governance-Plattformen auf 492 Mio. USD in 2026 und über 1 Mrd. USD bis 2030. Confidential Computing — Datenverarbeitung in hardwareverschlüsselten Enklaven — wird auf 59,4 Mrd. USD bis 2028 prognostiziert. Ein führender Anbieter in diesem Bereich sicherte sich 90 Mio. USD von Goldman Sachs bei über 150 Unternehmenskunden und belegt damit, dass Unternehmen Infrastrukturgarantien gegenüber vertraglichen Zusicherungen bevorzugen.
Die DSGVO-Durchsetzung beschleunigt parallel: allein 2,3 Mrd. EUR an Bußgeldern im Jahr 2025, ein Anstieg von 38 % gegenüber dem Vorjahr. Metas Bußgeld von 240 Mio. EUR wegen Verstößen gegen Art. 25 — Designphase-Versäumnisse *vor* einem Breach — setzte den Präzedenzfall, dass Architekturentscheidungen selbst durchsetzbar sind. Frankreichs CNIL entwickelt Werkzeuge (Projekt PANAME), um personenbezogene Daten in trainierten Modellen zu erkennen, und bewegt sich damit in Richtung Infrastrukturvalidierung statt der Akzeptanz von Softwarezusicherungen.
Die Frage ist nicht mehr, ob Durchsetzung auf Infrastrukturebene erwartet wird. Die Frage ist, ob Ihre Architektur bereit sein wird, wenn Prüfer danach fragen.
Was das für Prüfer bedeutet
Wenn ein Prüfer fragt „Wie setzen Sie Datenschutz durch Technikgestaltung um?", ist die Antwort kein Richtliniendokument. Es ist ein Satz von Kubernetes-Manifesten, Go-Quelldateien und SQL-Migrationen, die strukturell verhindern, dass das KI-System auf Identitätsdaten zugreift. Der Prüfungsumfang schrumpft: Statt jeden Anwendungs-Codepfad auf PII-Leaks zu auditieren, prüft der Auditor, dass NetworkPolicies deployed sind und dass die Verschlüsselungs- und RLS-Migrationen des Identity Vault gelaufen sind.
Art. 25 sagt „geeignete technische und organisatorische Maßnahmen." Wir haben uns entschieden, die technischen Maßnahmen architektonisch zu gestalten — durchgesetzt durch Infrastruktur, die nicht davon abhängt, dass Entwickler die richtige Funktion aufrufen.