Reproduzierbare Privatsphäre: Warum ML-Teams Konfigurationsvorgaben und nicht nur Dokumentation benötigen
Der DSB genehmigte das Dokument zum Anonymisierungsverfahren. Es legt fest: Namen, E-Mails, Telefonnummern und Geburtsdaten aus Trainingsdatensätzen mit der Ersetzungs-Methode entfernen. Das Dokument umfasst 4 Seiten und befindet sich im Compliance-Wiki.
Zwölf Datenwissenschaftler konsultieren es beim Projektstart. Sie konfigurieren ihre eigenen Versionen des Anonymisierungstools. Einige fügen nationale IDs hinzu. Einige schließen IP-Adressen ein. Einige verwenden Redact anstelle von Replace. Drei Monate später sind die Trainingsdatensätze inkonsistent.
Die CNIL (französische DSB) untersuchte mehrere KI-Unternehmen im Jahr 2024 wegen unsachgemäßer Verwendung personenbezogener Daten in Trainingsdatensätzen. Die Untersuchungen prüften nicht nur, ob eine Anonymisierung stattgefunden hat, sondern auch, wie konsistent sie angewendet wurde.
Dokumentation ist notwendig. Sie ist nicht ausreichend. Die technische Lösung ist die Vorgabe.
Warum ML-Trainingsdaten spezifische Konfigurationen erfordern
Die Anonymisierung von ML-Trainingsdaten hat Anforderungen, die die allgemeine Dokumentenanonymisierung nicht hat:
Ersetzen, nicht Redigieren: Neuronale Sprachmodelle, die auf Text trainiert werden, in dem Namen durch [REDACTED]-Tokens ersetzt werden, lernen, dass [REDACTED] ein spezieller Identifikator ist, der an Namenspositionen erscheint. Dies führt zu unerwünschtem Modellverhalten. Die Ersetzungs-Methode (Ersetzen von "John Smith" durch "David Chen") bewahrt die statistische Verteilung von Namen im Text, während die identifizierenden Informationen entfernt werden. Das Modell lernt aus realistischen Namenspositionsverteilungen, nicht von einem Maskentoken.
Konsistenz über den Datensatz hinweg: Ein Trainingsdatensatz, in dem 70% der Namen ersetzt und 30% [REDACTED] sind, erzeugt ein inkonsistentes Trainingssignal. Alle Datensätze sollten identisch verarbeitet werden.
Konsistente Entitätsauswahl: Wenn der Trainingsdatensatz Gesundheitsdaten enthält, führt das Entfernen von Namen, aber nicht von Geburtsdaten in einigen Datensätzen zu Inkonsistenzen. Alle 12 Datenwissenschaftler müssen dasselbe Set von Entitätstypen entfernen.
Keine Überanonymisierung: Übermäßige Anwendung der Ersetzungs-Methode — das Entfernen von Daten, die lediglich Zeitstempel sind, nicht Geburtsdaten — verringert den Nutzen des Datensatzes, ohne die Compliance zu verbessern. Die genehmigte Vorgabe definiert genau, welche Datumsentitäten entfernt werden sollen (Geburtsdatum, nicht allgemeine Zeitstempel).
Reproduzierbarkeit über Durchläufe hinweg: Wenn derselbe Datensatz erneut verarbeitet werden muss (z. B. nach der Entdeckung eines übersehenen Entitätstyps), produziert die erneute Verarbeitung mit derselben Vorgabe konsistente Ausgaben. Ad-hoc-Konfigurationen sind nicht reproduzierbar.
Das Problem der 12 Datenwissenschaftler
Ein europäisches Fintech-Unternehmen verwendet ein Trainingsdatensatz, das aus Kundeninteraktionsprotokollen abgeleitet ist. Der DSB genehmigte den Verarbeitungszweck (Modelltraining zur Betrugserkennung) unter Bedingungen: Alle Kundennamen, E-Mails, Telefonnummern und Zahlungsidentifikatoren müssen vor dem Modelltraining mit der Ersetzungs-Methode ersetzt werden.
Ohne Vorgaben:
- Datenwissenschaftler 1 entfernt Namen, E-Mails, Telefonnummern (schließt keine Zahlungsidentifikatoren ein)
- Datenwissenschaftler 2 schließt Zahlungsidentifikatoren ein, verwendet aber Redact statt Replace
- Datenwissenschaftler 3 folgt genau dem Verfahrensdokument
- Datenwissenschaftler 4-12 variieren
Ergebnis: 12 unterschiedlich verarbeitete Versionen der Trainingsdaten. Der zusammengeführte Datensatz ist teilweise nicht konform, teilweise überanonymisiert und statistisch inkonsistent.
Mit genehmigter Vorgabe:
- DSB erstellt die Vorgabe "ML Training — Betrugserkennung" mit genauen Entitätstypen und Ersetzungs-Methode
- Vorgabe wird mit allen 12 Datenwissenschaftlern geteilt mit Anweisungen: "Verwenden Sie diese Vorgabe für alle Vorbereitungen der Trainingsdaten"
- Vorgabe kann ohne Überprüfung durch den DSB nicht geändert werden (Zugriffssteuerung auf Konfiguration)
Ergebnis: Alle 12 Datenwissenschaftler produzieren identische Anonymisierungsausgaben. Der zusammengeführte Datensatz ist konsistent. Der jährliche KI-Compliance-Audit besteht ohne Feststellungen.
Im Vorjahr: 3 Feststellungen im Zusammenhang mit inkonsistenter Anonymisierung von ML-Trainingsdaten. Nach der Vorgabe: 0 Feststellungen.
Schnittstelle zwischen GDPR und AI Act
Der EU AI Act (in Kraft seit August 2024) fügt Compliance-Anforderungen für KI-Systeme hinzu, die personenbezogene Daten für das Training verwenden. Hochrisiko-KI-Systeme müssen ihre Trainingsdaten dokumentieren, einschließlich der angewendeten Anonymisierungsmaßnahmen.
Das Prinzip der Zweckbindung der GDPR (Artikel 5(1)(b)) beschränkt die Verwendung personenbezogener Daten für das ML-Training ohne spezifische rechtliche Grundlage. Die Durchsetzungsmaßnahmen der CNIL gegen KI-Unternehmen im Jahr 2024 konzentrierten sich auf diese Schnittstelle: Personenbezogene Daten, die zur Erbringung von Dienstleistungen gesammelt wurden, werden ohne angemessene rechtliche Grundlage oder Anonymisierung für das Training verwendet.
Die Dokumentationsanforderungen sowohl der GDPR als auch des AI Act sind leichter zu erfüllen, wenn der Anonymisierungsprozess für Trainingsdaten technisch durch Vorgaben durchgesetzt wird:
- Vorgabenname und Konfiguration: die dokumentierte Anonymisierungsmethodik
- Verarbeitungsprotokolle: Nachweis, dass die Methodik auf spezifische Datensätze angewendet wurde
- Genehmigung durch den DSB: aufgezeichnete Entscheidung zur Genehmigung der Vorgabenkonfiguration
Dies schafft die Prüfspur, die beide Vorschriften verlangen.
Vorgabenkonfiguration für ML-Trainingsdaten
Entitätstypen für die meisten NLP-Trainingsdaten:
- PERSON (Namen — Ersetzen durch ähnliche Namen)
- EMAIL_ADDRESS (Ersetzen durch synthetische E-Mails)
- PHONE_NUMBER (Ersetzen durch synthetische Telefonnummern)
- CREDIT_CARD / IBAN (Ersetzen oder Redigieren — Zahlungsdaten)
- LOCATION (Ersetzen durch ähnliche Standorte, wenn Geodaten für das Modell benötigt werden; Redigieren, wenn nicht)
- DATE_OF_BIRTH (Redigieren — Altersgeneralisierung oft erforderlich)
Entitätstypen, die typischerweise NICHT für NLP-Trainingsdaten enthalten sind:
- Allgemeine Daten (nicht Geburtsdatum) — Zeitstempel und Daten im Text sind oft für zeitliche Modellierung erforderlich
- Organisationsnamen — oft für das Training zur Entitätserkennung erforderlich
- URLs — oft für Verlinkung und Referenzextraktion erforderlich
Der ML-Leiter und der DSB definieren diese Unterscheidungen in der genehmigten Vorgabe. Einzelne Datenwissenschaftler treffen diese Entscheidungen nicht — sie wenden die Vorgabe an.
Institutionelles Wissen und Vorgabenversionierung
Vorgaben dienen einer Funktion des institutionellen Gedächtnisses:
Vor Vorgaben: Die korrekte Entitätskonfiguration für ML-Trainingsdaten lebte im Kopf der drei Datenwissenschaftler, die den Compliance-Überprüfungsprozess durchlaufen hatten. Als zwei von ihnen im Q3 gingen, ging das institutionelle Wissen verloren.
Nach Vorgaben: Die Konfiguration ist in "ML Training — Kundendaten v2.1" kodiert. Die Versionshistorie zeigt, wann sie erstellt wurde, wer sie genehmigte und was sich zwischen v2.0 und v2.1 geändert hat. Neue Datenwissenschaftler verwenden die Vorgabe und übernehmen das institutionelle Wissen, das darin eingebettet ist.
Version 2.1 fügte die IBAN-Erkennung hinzu, nachdem eine Compliance-Überprüfung ergeben hatte, dass sie fehlte. Die Aufzeichnungen der Version 2.0 zeigen, dass sie im Februar 2025 genehmigt wurde. Die Prüfspur ist vollständig.
Fazit
Dokumentation sagt den Teammitgliedern, was zu tun ist. Vorgaben machen es technisch einfach — und technisch durchsetzbar —, dies konsistent zu tun.
Für ML-Trainingsdaten ist Konsistenz sowohl eine Compliance-Anforderung (GDPR, AI Act) als auch eine technische Anforderung (Modelltraining erfordert konsistente Vorverarbeitung). Die Vorgabe erfüllt beide gleichzeitig.
CNIL und andere DSBs, die die Praktiken bei KI-Trainingsdaten untersuchen, werden nach Beweisen für systematische, konsistente Anonymisierung suchen. Eine Vorgabe, die einheitlich auf alle Vorbereitungen der Trainingsdaten angewendet wird, ist der stärkste Nachweis, der verfügbar ist.
Quellen: