Vor dem KI-Modell: Anonymisierung als Governance-Kontrolle
Von Jhonathan Campos, Gründer
EDPB-Leitlinien 02/2026 in der Praxis: die Bewertung, die entscheidet, was in die KI-Pipeline gelangt
Abschnitte: Rechtlicher Test · Isolierung, Verknüpfung und Inferenz · Web Scraping · Entscheidungsnachweis · Konsultation und nächste Schritte
Anonymisierung ist seit jeher eine technische Aufgabe, wenn reale Datensätze für Analysen und maschinelles Lernen vorbereitet werden. Namen und Kontonummern zu löschen ist der einfache Teil. Entscheidend sind Quasi-Identifikatoren, Verknüpfungsrisiken und die Wahrscheinlichkeit, dass eine Person aus den verbleibenden Informationen weiterhin herausgegriffen werden kann. Kompetente Privacy Engineers arbeiten seit Jahren nach diesem Verständnis. Neu ist die rechtliche Sichtbarkeit dieser Praxis. Am 7. Juli 2026 verabschiedete der Europäische Datenschutzausschuss die Leitlinien 02/2026 zur Anonymisierung sowie begleitende Leitlinien zum Web Scraping im Zusammenhang mit generativer KI. Beide Entwürfe stehen bis zum 30. Oktober 2026 zur öffentlichen Konsultation.
Die Leitlinien sind die erste umfassende Stellungnahme des Ausschusses seit der Stellungnahme 05/2014 der Artikel-29-Datenschutzgruppe. Sie beziehen das Urteil des Gerichtshofs vom 4. September 2025 in der Rechtssache C-413/23 P, EDPS gegen SRB, in eine breitere, entitätsbezogene Analyse ein. Danach kann derselbe Datensatz aus Sicht verschiedener Beteiligter einen unterschiedlichen Grad an Anonymität haben. Der operative Kern ist ein dreiteiliger Rahmen. Daten können sicher als anonym gelten, wenn kein Datensatz isoliert, keine Verknüpfung mit anderen Daten derselben Person hergestellt und keine konkrete Schlussfolgerung über eine identifizierte oder identifizierbare Person gezogen werden kann. Scheitert eines dieser Kriterien, verlangen die Leitlinien eine weitergehende Prüfung der Umstände.
Für Teams, die KI-Systeme entwickeln, betrifft das vor allem die Datenvorbereitung. Anonymisierung ist eine Bewertung mit festgelegten Kriterien, dokumentierter Methode, Prüfpflichten und erneuter Überprüfung. Diese Schritte müssen vor dem ersten Trainingslauf abgeschlossen sein. Ein Modell, das durch identifizierbare Beispiele geprägt wurde, lässt sich später nicht durch Dokumentation anonym machen.
Ein Beispiel begleitet die Analyse: Ein mittelgroßer Versicherer möchte ein Sprachmodell zur Triage von Schadenmeldungen feinabstimmen. Die Tickets verbinden strukturierte Metadaten wie Postleitzahl, Schadenart und Zeitstempel mit frei formulierten Kundentexten. Ein externer Anbieter soll das Fine-Tuning durchführen. Der Versicherer muss entscheiden, ob der vorbereitete Datensatz den Anwendungsbereich der DSGVO verlässt, bevor er das Unternehmen verlässt.
Der rechtliche Test und die entitätsbezogene Perspektive
Ausgangspunkt sind Artikel 4 Absatz 1 DSGVO und Erwägungsgrund 26. Informationen sind personenbezogen, wenn sie sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. Dabei sind alle Mittel zu berücksichtigen, die vernünftigerweise zur Identifizierung eingesetzt werden können. Die Leitlinien folgen C-434/16 Nowak für den Personenbezug und C-582/14 Breyer für Mittel, die über rechtmäßige Kanäle verfügbar sind. Das Urteil SRB wird in die entitätsbezogene Betrachtung eingeordnet. Derselbe Datensatz kann bei einer Stelle personenbezogen und bei einer anderen anonym sein. Die Bewertung muss deshalb ausdrücklich festhalten, aus wessen Perspektive sie erfolgt.
Der Ausschuss beschreibt zwei Wege. Beim vereinfachten Ansatz behandelt der Verantwortliche die Daten überall dort als personenbezogen, wo erhebliche Unsicherheit bleibt. Das kann über den rechtlichen Mindeststandard hinausgehen und verschafft Sicherheit auf Kosten eines größeren DSGVO-Scopes. Beim kontextbezogenen Ansatz wird die Identifizierbarkeit für einen bestimmten Empfänger in einer bestimmten Umgebung bewertet. Dafür braucht es Evidenz zu Zugriffsrechten, Zusatzdaten und realistischen Fähigkeiten. In der Praxis dürfte der vereinfachte Ansatz dominieren, weil Verantwortliche die nötigen Empfängerdaten häufig nicht belastbar belegen können. Der Ausschuss warnt zudem davor, auf eine vermeintlich fehlende Motivation zur Re-Identifizierung zu vertrauen.
Im Versicherungsbeispiel sieht der Fine-Tuning-Anbieter das Vertragsverwaltungssystem nicht. Der Versicherer besitzt es jedoch weiterhin, einschließlich der Zuordnung zwischen Ticket-IDs und Versicherungsnehmern. Weil der Anbieter im Auftrag des Versicherers verarbeitet, muss die Bewertung durch die Perspektive des Versicherers laufen. Solange dieser die Verknüpfungsschlüssel behält, bleiben die Tickets in der Pipeline personenbezogen. Anders könnte die Antwort ausfallen, wenn ein transformierter Auszug an einen unabhängigen Forschungspartner übermittelt wird. Dann müsste die Akte die tatsächliche Umgebung des Partners belegen und die Transformation alle drei folgenden Kriterien bestehen.
Isolierung, Verknüpfung und Inferenz im Ticketdatensatz
Isolierung von Datensätzen. Strukturierte Metadaten sind klassische Privacy-Engineering-Arbeit. Postleitzahl, Schadenart und Zeitstempel wirken einzeln harmlos, können zusammen aber eine Person in einer ländlichen Region isolieren. Verfahren wie k-Anonymität helfen, weil sie das Team zwingen zu prüfen, ob jede Kombination von Quasi-Identifikatoren genügend Personen umfasst. Sie sind jedoch nur ein Einstieg. Der EDPB-Test umfasst zusätzlich Verknüpfung und Inferenz. Deshalb benötigen Fließtext, Embeddings, synthetische Ausgaben und trainierte Modelle andere Prüfungen. Fünf Datensätze mit dem gemeinsamen Merkmal „laufende Brandstiftungsermittlung“ können k=5 erfüllen und trotzdem sensible Informationen über jedes Gruppenmitglied offenlegen. Im Freitext identifiziert die Beschreibung eines Hausbrands in einem genannten Dorf und einer bestimmten Woche die Person oft zuverlässiger als die gelöschte Kundennummer. Automatische Schwärzung findet Namen und Kontonummern. Chronologie und Kontext bleiben häufig bestehen. Hier ist eine dokumentierte menschliche Stichprobenprüfung erforderlich.
Verknüpfung. KI-Datensätze werden aus mehreren Quellen zusammengesetzt. Genau dort konzentriert sich das Verknüpfungsrisiko. Der Ticketexport wirkt eigenständig, bis ihn jemand mit einem sechs Monate zuvor erstellten CRM-Export für ein Churn-Modell verbindet. Embeddings verdienen besondere Aufmerksamkeit. Ein Vektorindex über die Tickets bewahrt semantische Nähe zum Quelltext. Eine Ähnlichkeitssuche kann Fragmente wieder zusammenführen, die durch Schwärzung getrennt wurden. Der Embedding-Speicher sollte deshalb Teil des bewerteten Datensatzes sein und denselben Zugriffskontrollen und Prüfplan erhalten.
Inferenz. Dieses Kriterium trägt das größte KI-Gewicht. Der Ausschuss hatte bereits in Stellungnahme 28/2024 zu KI-Modellen klargestellt, dass ein mit personenbezogenen Daten trainiertes Modell nicht automatisch anonym ist. Die Leitlinien 02/2026 verallgemeinern den Punkt. Unzulässige Rückschlüsse können aus Einzeldaten, Aggregaten, trainierten Modellen und synthetischen Ausgaben entstehen, auch durch Prompting. Beim Versicherer lautet die operative Frage, ob das feinabgestimmte Modell seltene Tickets auswendig gelernt hat. Die Leitlinien benennen die Angriffsflächen, schreiben aber kein bestimmtes Prüfprotokoll vor. Die Wahl des Protokolls ist daher selbst eine zu begründende Entscheidung.
Ein belastbares Protokoll kann Canary-Datensätze im Training platzieren und ihre Extraktion per Prompt versuchen, Membership-Inference-Tests gegen eine zurückgehaltene Stichprobe realer Tickets ausführen und nach nahezu identischen Passagen zwischen generierten Ausgaben und Trainingskorpus suchen. Die Sampling-Einstellungen müssen denen des späteren Produkts entsprechen. Jedes Element liefert ein messbares Ergebnis für die Bewertungsakte.
Synthetische Daten passieren dasselbe Tor. Erzeugt der Versicherer künstliche Tickets aus dem realen Korpus, wurde der Generator weiterhin mit dem seltenen Brandschaden trainiert. Generatoren können Ausreißer reproduzieren. Der synthetische Datensatz erlangt anonymen Status erst, wenn er dieselben drei Kriterien besteht.
Hier zeigt sich die professionelle Schnittstelle. Ein Jurist, der einen Membership-Inference-Bericht nicht lesen kann, kann die Bewertung nicht abschließen. Ein Engineer ohne Verständnis von Erwägungsgrund 26 kann nicht bestimmen, was der Bericht belegen muss. Die Schlussfolgerung benötigt beides. Genau diese Verbindung aus Softwareentwicklung und Compliance-Recht bildet den Kern meiner Arbeit.
Web Scraping auf der Eingangsseite der Pipeline
Die begleitenden Leitlinien werden relevant, sobald der Versicherer seine eigenen Tickets durch Beschwerden aus Verbraucherforen ergänzen möchte. Web Scraping ist DSGVO-relevante Verarbeitung, wenn es Vorgänge mit personenbezogenen Daten wie Erhebung, Speicherung oder Abruf umfasst. Öffentliche Verfügbarkeit ändert an dieser Schwelle nichts. Die Leitlinien betonen Zweckbindung und Transparenz und werden bei der Richtigkeit besonders operativ: verlässliche Quellen, dokumentierte Zeitstempel und Validierung vor dem Training.
Viele private Verantwortliche werden Artikel 6 Absatz 1 Buchstabe f als Rechtsgrundlage prüfen. Hier wirkt Anonymisierung doppelt. Filterung und Transformation am Eingang reduzieren den Umfang der Daten, der in der Interessenabwägung gerechtfertigt werden muss. Ein dokumentierter und geprüfter Anonymisierungsschritt kann außerdem als Schutzmaßnahme berücksichtigt werden. Die Reihenfolge entscheidet. Der Filter muss wirken, bevor gescrapte Inhalte den Trainingskorpus erreichen. Ein Design, das zuerst alles übernimmt und später bereinigt, wird genau in dieser Form bewertet.
Der Entscheidungsnachweis und die Verbindung zum AI Act
Die Leitlinien verlangen die Dokumentation des Anonymisierungsprozesses einschließlich der Prüfungen der angeblich anonymen Ausgaben. Die Dokumentation muss nach Abschluss des Vorgangs aufbewahrt werden. Ein Sicherheitsvorfall kann eine erneute Bewertung auslösen. Wenn die Zuordnungstabellen des Versicherers abfließen, kann der an den Forschungspartner übermittelte Auszug über Nacht seinen rechtlichen Status ändern. Die Akte muss zeigen, wer dann neu bewertet und wann.
In meiner Praxis ist das Ergebnis ein einziger, vor Trainingsbeginn unterzeichneter Entscheidungsnachweis. Er nennt Quelldaten und Zweck, beschreibt Methode und Prüfergebnisse und hält Restrisiko, Eigentümer sowie Auslöser für eine erneute Bewertung fest. Ein kurzer Nachweis mit dahinterliegender Testevidenz wiegt stärker als eine lange Richtlinie. Die Richtlinie beschreibt eine Absicht. Der Nachweis zeigt, was tatsächlich geschehen ist.
Der gleiche Nachweis unterstützt die AI-Act-Akte. Artikel 10 verlangt für Hochrisiko-Systeme dokumentierte Daten-Governance. Der Anonymisierungsnachweis trägt Herkunft, Vorbereitung und verbleibendes Datenschutzrisiko zu dieser Bewertung bei. Er ersetzt die breitere Prüfung nach Artikel 10 nicht, zu der auch Repräsentativität, mögliche Verzerrungen und Eignung für den Zweck gehören. Zum richtigen Zeitpunkt erstellt, dient eine Evidenz beiden Regelwerken. Spät erstellt, muss sie unter Zeitdruck aus der Repository-Historie rekonstruiert werden.
Was die Konsultation ändern sollte und was jetzt zu tun ist
Der Entwurf steht bis zum 30. Oktober 2026 zur Konsultation. Besonders beim Inferenzkriterium für generative Modelle kann sich der endgültige Text noch verändern. Eine strenge Lesart ordnet fast jedes große Modell, das mit menschlichen Texten trainiert wurde, der Seite personenbezogener Daten zu. Entwickler, die dieses Ergebnis für falsch halten, sollten technische Evidenz in die Konsultation einbringen. Der Ausschuss hat gezeigt, dass ausgearbeitete Beispiele mehr bewirken als reine Positionspapiere.
Die nützliche Zwischenempfehlung lautet nicht, abzuwarten. Wählen Sie eine aktive Pipeline, führen Sie die Drei-Kriterien-Bewertung jetzt durch und schreiben Sie den Entscheidungsnachweis so, als wäre der Entwurf endgültig. Die entdeckten Lücken bilden zugleich Ihren Compliance-Backlog und einen möglichen Konsultationsbeitrag. Wenn Ihr Modell vor dem 30. Oktober trainieren soll, muss die Bewertung vorher stattfinden.