Prüfer werden Schwärzung als KI-Datenschutznachweis nicht mehr akzeptieren

Prüfer werden aufhören, Datenschwärzung als Nachweis der Compliance mit DSGVO Art. 25 für KI-Systeme zu akzeptieren. Nicht weil Schwärzung nutzlos ist — sie fängt die meisten personenbezogenen Daten die meiste Zeit ab. Weil „die meiste Zeit" nicht das ist, was Art. 25 Abs. 1 mit „geeigneten technischen Maßnahmen, die wirksam umgesetzt werden" meint. Und wenn die Durchsetzung von Art. 10 der KI-Verordnung im August 2026 beginnt, steigt die Messlatte weiter.

Zuletzt aktualisiert: März 2026

Die Prüfungsmathematik, die unser Vertrauen in Schwärzung erschüttert hat

Als wir The Veil entwarfen, begannen wir nicht mit Infrastrukturtrennung. Wir begannen damit, zu berechnen, was es kosten würde, die Sicherheit eines schwärzungsbasierten Systems nachzuweisen.

Um Schwärzung zu verifizieren, muss ein Prüfer bestätigen, dass:

• Jedes Datenfeld mit personenbezogenen Daten identifiziert und katalogisiert ist
• Jeder Codepfad, der Daten verarbeitet, durch die Schwärzungs-Pipeline läuft
• Die Schwärzungslogik jedes Format, jede Sprache und jede Codierung korrekt behandelt
• Kein Logging-, Caching- oder Error-Handling-Pfad Daten vor der Schwärzung erfasst
• Neue, von Entwicklern hinzugefügte Felder automatisch durch die Pipeline geleitet werden
• URL-codierte, Base64-codierte und Unicode-Lookalike-Darstellungen erkannt werden

Das ist ein unbegrenztes Verifikationsproblem. Die Angriffsfläche wächst mit jedem neuen Feature, jeder neuen Datenquelle, jedem Entwickler, der ein Log-Statement schreibt. Ein Prüfer, der heute abzeichnet, kann nicht garantieren, dass das System nach dem nächsten Sprint noch compliant ist.

Dann berechneten wir, was die Verifikation von Infrastrukturtrennung erfordert:

• 16 NetworkPolicy-YAML-Dateien verbieten Cross-Namespace-Traffic
• 4 Docker-Compose-Netzwerkdeklarationen isolieren die Sandboxes
• 1 Protobuf-Schema definiert, was die ID Bridge akzeptiert (nur opake Token)
• 1 Gateway-Middleware-Funktion entfernt personenbezogene Daten vor der Weiterleitung an die KI-Sandbox

Das ist ein begrenztes Verifikationsproblem. Der Umfang wächst nicht mit der Anwendung. Ein neues KI-Feature in Sandbox B kann keine Identitätsdaten leaken, weil das Netzwerk den Transport verweigert — unabhängig davon, was der Anwendungscode anfordert.

An diesem Punkt haben wir uns für Infrastrukturtrennung statt Schwärzung entschieden. Nicht weil Schwärzung nicht funktioniert. Weil wir nicht beweisen konnten, dass sie *weiterhin* funktionieren würde.

Versagt offen vs. versagt geschlossen

Diese Unterscheidung existiert in der aktuellen Literatur zum Thema KI-Datenschutz nicht. Sie sollte es.

Schwärzung versagt offen. Wenn ein Regex-Muster ein PII-Format verfehlt, nimmt die KI vollständig identifizierbare Daten auf und verarbeitet sie normal weiter. Kein Alert feuert. Keine Verbindung wird unterbrochen. Die Datenschutzgrenze wurde lautlos überschritten. Ich habe das aus erster Hand in ServiceNow-Umgebungen gesehen — personenbezogene Daten, die durch Log-Statements, durch benutzerdefinierte Felder, die niemand durch die Schwärzungs-Pipeline geleitet hatte, durch Freitext-Notizen, in denen Kundennamen neben Fallbeschreibungen standen, durchsickerten. Die Filter funktionierten bei den Feldern, die sie kannten. Sie konnten nicht abfangen, was sie nicht kannten.

Infrastrukturisolation versagt geschlossen. Wenn eine Kubernetes-NetworkPolicy fehlkonfiguriert ist, wird die Verbindung verweigert. Der KI-Dienst kann die Identitätsdatenbank nicht erreichen. Das System bricht sichtbar. Sie erhalten einen Fehler, keinen Breach.

Für einen CTO, der heute eine Architekturentscheidung trifft: Soll Ihr Datenschutzsystem versagen, indem es lautlos Daten leakt, oder indem es laut eine Verbindung verweigert?

Was ein Angreifer bekommt: Die Breach-Mathematik

In einem monolithischen KI-System liefert ein Breach alles — Kundennamen, Kontonummern, Transaktionshistorien, KI-Risikoscores, Verhaltensprofile — vollständig verknüpft, vollständig identifizierbar. Jeder Breach ist der schlimmste Fall. Eine Benachrichtigung jedes betroffenen Individuums gemäß DSGVO Art. 34 ist nahezu sicher erforderlich.

In einer Split-Architektur gibt es keinen einzelnen Breach, der ein verknüpftes Profil ergibt:

Sandbox B ist das wahrscheinlichste Ziel — dort befinden sich die KI-Modelle, die Datenpipelines und die externen Integrationen. Ein Angreifer, der sie kompromittiert, erhält Risikoscores, die an opake Token geknüpft sind. Gemäß DSGVO Art. 33–34 ändert sich die Risikobewertung des Breach wesentlich: Pseudonymisierte Daten mit intakten Schutzmaßnahmen erfordern unter Umständen keine individuelle Benachrichtigung (Erwägungsgrund 26).

Das ist eine andere Unterhaltung mit Ihrem Vorstand als „der Angreifer hat alles."

Der Markt hat sich bereits bewegt

Während der regulatorische Stichtag näher rückt, wartet der Markt nicht. Gartner prognostiziert den Markt für KI-Governance-Plattformen auf 492 Mio. USD in 2026 und über 1 Mrd. USD bis 2030. In einer Umfrage unter 360 Organisationen im Jahr 2025 nannten 52 % die Offenlegung sensibler Daten als ihr größtes KI-Risiko und 50 % regulatorische Compliance als zweitgrößtes Risiko.

Die Infrastrukturschicht bewegt sich noch schneller. Confidential Computing — hardwaregestützter Datenschutz während der Verarbeitung — wird auf 59,4 Mrd. USD bis 2028 prognostiziert. Ein Marktführer in diesem Bereich sicherte sich eine 90-Mio.-USD-Serie-C unter Führung von Goldman Sachs bei über 150 Unternehmenskunden aus Banken, Behörden und großen Technologieunternehmen. Deren Wachstum validiert eine Kernthese: Unternehmen bewegen sich über vertragliche Zusicherungen hinaus hin zu Infrastrukturgarantien.

Der Forschungskonsens aus Cloud-Security-Teams, Branchenanalysten und akademischer Literatur ist eindeutig: Schwärzung und Infrastrukturisolation sind komplementäre, nicht alternative Ansätze. Die empfohlene Praxis ist eine mehrschichtige Verteidigung — Isolation für die Verarbeitung, Schwärzung für die Ausgabe, Tokenisierung für die Speicherung. Nur auf eine Schicht zu setzen, ist eine Wette darauf, dass die anderen nie gebraucht werden.

Warum der August 2026 die Gleichung verändert

Drei regulatorische Entwicklungen konvergieren:

Durchsetzung von Art. 10 der KI-Verordnung (2. August 2026). Hochrisiko-KI-Systeme müssen Data Governance „über den gesamten Datenlebenszyklus" nachweisen. Sanktionen: bis zu 35 Mio. EUR oder 7 % des weltweiten Jahresumsatzes — 75 % höher als die 4-%-Obergrenze der DSGVO. Art. 10 sagt nicht „schwärzen Sie personenbezogene Daten." Er verlangt, dass Trainings- und Inferenzdaten „relevant, repräsentativ, fehlerfrei und vollständig" sind, mit „angemessener Data Governance." Wenn ein Prüfer fragt, wie Sie Trainingsdaten verwaltet haben, ist „wir haben sie durch einen Regex-Filter laufen lassen" eine schwächere Antwort als „das KI-System hat keinen Netzwerkpfad zu Identitätsdaten."

Metas 240-Mio.-EUR-Bußgeld wegen Art. 25 (Dezember 2024). Der Europäische Datenschutzausschuss bestrafte Meta für Versäumnisse in der Designphase — nicht für einen Breach, sondern dafür, Datenschutz nicht von Anfang an eingebaut zu haben. Das ist Art. 25 präventiv angewendet, bevor ein Schaden eintritt. Der Präzedenzfall: Man kann für die Architekturentscheidung selbst bestraft werden.

CNILs Projekt PANAME. Die französische Aufsichtsbehörde entwickelt technische Werkzeuge, um zu erkennen, ob trainierte KI-Modelle personenbezogene Daten enthalten. Die Details sind noch nicht öffentlich, aber die Richtung ist klar: Regulierungsbehörden bewegen sich in Richtung Infrastrukturvalidierung, statt sich auf Ihr Wort zu verlassen, dass die Schwärzungs-Pipeline alles abgefangen hat.

Keine Aufsichtsbehörde hat explizit gesagt: „Schwärzungsbasierte KI-Systeme erfüllen Art. 25 nicht." Aber die EDPB-Leitlinien 4/2019 zu Datenschutz durch Technikgestaltung listen Pseudonymisierung, Differential Privacy, Federated Learning und homomorphe Verschlüsselung als datenschutzfördernde Technologien auf — Schwärzung wird nicht erwähnt. Wenn die Durchsetzung beschleunigt, werden Systeme, die architektonische Trennung nachweisen können, eine wesentlich andere Compliance-Position haben als solche, die sich auf Software-Filter verlassen.

Die Entscheidung des CTO

Wenn Ihr KI-System die Identitätsdatenbank über das Netzwerk erreichen kann, ist Schwärzung das Einzige, was eine Datenschutzverletzung verhindert. Das bedeutet, Ihre Compliance-Position hängt von der Korrektheit jeder einzelnen Zeile Schwärzungscode ab, über jeden Dienst, über jedes Deployment, nach jedem Sprint, für immer.

Trennung auf Infrastrukturebene — durchgesetzt durch Kubernetes NetworkPolicies und Docker-Netzwerksegmentierung — reduziert die Vertrauensgrenze auf eine kleine, statische, auditierbare Menge von Infrastrukturkonfigurationen. Die Mauer liegt im Netzwerk-Fabric, nicht im Anwendungscode. Die Verifikation ist begrenzt, nicht unendlich.

Der August 2026 ist 5 Monate entfernt. Die Architekturentscheidung, die Sie jetzt treffen, ist diejenige, die Prüfer dann bewerten werden.