Die beiden Leitlinien-Entwürfe des EDSA vom Juli 2026, zu Anonymisierung und zu Web Scraping für generative KI, ersetzen den Reidentifizierungstest von 2014 durch drei neue Prüfkriterien. Hier steht, was die Texte sagen, Klausel gegen Klausel, und wie ein Produkt-Analytics-Export daran abschneidet.
Die beiden Leitlinien-Entwürfe des EDSA vom Juli 2026, zu Anonymisierung und zu Web Scraping für generative KI, ersetzen den Reidentifizierungstest von 2014 durch drei neue Prüfkriterien. Hier steht, was die Texte sagen, Klausel gegen Klausel, und wie ein Produkt-Analytics-Export daran abschneidet.
Auf keinem Satz in einem Sicherheitsfragebogen liegt mehr Last als auf «Wir haben das anonymisiert» — und der EU-weite Test dahinter wurde zuletzt im April 2014 spezifiziert. Am 07. Juli 2026 hat der Europäische Datenschutzausschuss (EDSA) seine erste Neufassung seit zwölf Jahren angenommen: den Entwurf der Leitlinien 02/2026 zur Anonymisierung und den Entwurf der Leitlinien 03/2026 zu Web Scraping im Kontext generativer KI. Beide sind Version 1.0, angenommen am 07. Juli 2026 zur öffentlichen Konsultation; laut der Mitteilung des EDSA: «Die Leitlinien werden bis zum 30. Oktober 2026 Gegenstand einer öffentlichen Konsultation sein […]». Jedes Zitat aus diesen beiden Dokumenten weiter unten ist Entwurfstext; er kann sich ändern. Ich habe beide gegen die gefestigten Anker gelesen: DSGVO-Erwägungsgrund 26, die Stellungnahme 05/2014 der Artikel-29-Datenschutzgruppe (WP216) und die finale Stellungnahme 28/2024 des EDSA zu KI-Modellen. Der Kernbefund: Entwurf 02/2026 ersetzt den dreiteiligen Test des WP216 durch drei umbenannte und neu zugeschnittene Kriterien, und ein verletztes Kriterium ist nicht mehr das Ende der Analyse.
Zwei Lesehinweise zur deutschen Fassung dieses Beitrags: DSGVO und WP216 zitiere ich nach den amtlichen deutschen Fassungen, mit deren Seitenzahlen. Die beiden Entwürfe, die Stellungnahme 28/2024 und die Pseudonymisierungs-Leitlinien 01/2025 liegen nur auf Englisch vor; ihre Zitate bleiben deshalb im Original, tragende Passagen mit einer Übersetzung («Sinngemäss:»), und Randnummern (Rn.) verweisen auf die englischen Texte. Protokollierte Wortsuchen liefen, wo nicht anders vermerkt, gegen die englischen Textfassungen.
Der Anwendungsbereich beginnt bei Artikel 4(1) DSGVO:
«‹personenbezogene Daten› alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person (im Folgenden ‹betroffene Person›) beziehen; als identifizierbar wird eine natürliche Person angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer Online-Kennung oder zu einem oder mehreren besonderen Merkmalen, die Ausdruck der […] Identität dieser natürlichen Person sind, identifiziert werden kann;»
Ob jemand identifizierbar ist, entscheidet Erwägungsgrund 26 — die Dreh- und Angelklausel für alles Folgende, hier vollständig:
«Die Grundsätze des Datenschutzes sollten für alle Informationen gelten, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. Einer Pseudonymisierung unterzogene personenbezogene Daten, die durch Heranziehung zusätzlicher Informationen einer natürlichen Person zugeordnet werden könnten, sollten als Informationen über eine identifizierbare natürliche Person betrachtet werden. Um festzustellen, ob eine natürliche Person identifizierbar ist, sollten alle Mittel berücksichtigt werden, die von dem Verantwortlichen oder einer anderen Person nach allgemeinem Ermessen wahrscheinlich genutzt werden, um die natürliche Person direkt oder indirekt zu identifizieren, wie beispielsweise das Aussondern. Bei der Feststellung, ob Mittel nach allgemeinem Ermessen wahrscheinlich zur Identifizierung der natürlichen Person genutzt werden, sollten alle objektiven Faktoren, wie die Kosten der Identifizierung und der dafür erforderliche Zeitaufwand, herangezogen werden, wobei die zum Zeitpunkt der Verarbeitung verfügbare Technologie und technologische Entwicklungen zu berücksichtigen sind. Die Grundsätze des Datenschutzes sollten daher nicht für anonyme Informationen gelten, d.h. für Informationen, die sich nicht auf eine identifizierte oder identifizierbare natürliche Person beziehen, oder personenbezogene Daten, die in einer Weise anonymisiert worden sind, dass die betroffene Person nicht oder nicht mehr identifiziert werden kann. Diese Verordnung betrifft somit nicht die Verarbeitung solcher anonymer Daten, auch für statistische oder für Forschungszwecke.»
Drei Details zählen hier. Der Massstab ist objektiv und bepreist: «die Kosten der Identifizierung und der dafür erforderliche Zeitaufwand», gemessen an verfügbarer Technologie und deren Entwicklung. Gezählt werden die Mittel aller: «von dem Verantwortlichen oder einer anderen Person». Und ein Wortlaut-Punkt, der sich im englischen Verordnungstext abspielt: Die Formulierung "singled out" kommt in der englischen Fassung der DSGVO nirgends vor. Erwägungsgrund 26 sagt "such as singling out" — die amtliche deutsche Fassung macht daraus «wie beispielsweise das Aussondern» —, und das ist die einzige Stelle, an der das Konzept auftaucht; Artikel 4(1) enthält keine der beiden Formulierungen. Auch "reasonably likely" — deutsch: «nach allgemeinem Ermessen wahrscheinlich» — existiert im englischen Text ausschliesslich in diesem Erwägungsgrund: zweimal hier, im Rest der Verordnung nie.
Die Stellungnahme 05/2014 zu Anonymisierungstechniken der Artikel-29-Datenschutzgruppe (WP216, angenommen am 10. April 2014, final) hat aus diesem Massstab drei benannte Risiken gemacht. Von S. 13 der deutschen Fassung:
«– Herausgreifen (singling out), d. h. die Möglichkeit, in einem Datenbestand einige oder alle Datensätze zu isolieren, welche die Identifizierung einer Person ermöglichen;– Verknüpfbarkeit, d. h. die Fähigkeit, mindestens zwei Datensätze, welche dieselbe Person oder Personengruppe betreffen, zu verknüpfen (in derselben Datenbank oder in zwei verschiedenen Datenbanken). […]– Inferenz, d. h. die Möglichkeit, den Wert eines Merkmals mit einer signifikanten Wahrscheinlichkeit von den Werten einer Reihe anderer Merkmale abzuleiten.»
Ein Terminologie-Hinweis, einmal für den ganzen Beitrag: Für das englische "singling out" schreibt die deutsche WP216-Fassung «Herausgreifen», die amtliche DSGVO-Fassung in Erwägungsgrund 26 dagegen «Aussondern». Gemeint ist derselbe Angriff; ich führe den englischen Begriff jeweils mit.
Gegen die eigenen Tabellen gelesen: Lässt sich irgendein Datensatz auf eine einzelne Person isolieren; lassen sich Datensätze über dieselbe Person verbinden, innerhalb einer Datenbank oder über zwei hinweg; lässt sich ein Merkmal aus den übrigen ableiten. WP216 bindet das Trio auf derselben Seite direkt an den rechtlichen Massstab zurück: «Eine Lösung, die Schutz vor diesen drei Risiken bietet, wäre somit robust und geeignet, eine Reidentifizierung mit den Mitteln, die vernünftigerweise entweder von dem für die Verarbeitung Verantwortlichen oder von einem Dritten eingesetzt werden könnten, zu verhindern.»
Zwei operative Positionen von 2014 beissen bis heute. Von S. 10: «wenn der für die Verarbeitung Verantwortliche die ursprünglichen Daten (die eine Identifizierung zulassen) auf Ereignisebene nicht löscht und einen Teil dieses Datenbestands (beispielsweise nach der Entfernung oder Maskierung der Daten, die eine Identifizierung zulassen) weitergibt, beinhaltet der entstandene Datenbestand nach wie vor personenbezogene Daten.» Und von S. 29: Der Verantwortliche «darf niemals nach dem Prinzip ‹Freigeben und Vergessen› handeln» — das Restrisiko ist regelmässig neu zu evaluieren, die Kontrollen sind anzupassen, die Risiken zu überwachen.
Der Leitlinien-Entwurf 02/2026 würdigt seinen Vorgänger in Rn. 2 (dieses wie jedes 02/2026-Zitat in diesem Beitrag ist Entwurfstext): Die Stellungnahme 05/2014 "provided three criteria for assessing the anonymity of data" — lieferte drei Kriterien zur Beurteilung der Anonymität von Daten —, aber seit 2014 "there have been major changes in the legal, privacy, engineering and technological landscapes": Die rechtliche, datenschutzrechtliche, technische und technologische Landschaft hat sich erheblich verändert. Fussnote 3 gewährt Bestandsschutz: Ein Verantwortlicher, der einen Datenbestand vor der Veröffentlichung nach Stellungnahme 05/2014 beurteilt hat, "is not expected to conduct a new assessment" — muss nicht neu beurteilen.
Zwei protokollierte Suchen: "WP216" kommt im Entwurf nirgends vor; "linkability" ebenso wenig. Der Entwurf spricht von "Opinion 05/2014" und benennt den gesamten Apparat um. Aus der Executive Summary (S. 2):
"The framework itself presents three criteria which can be used to test if data is anonymous: No Record Isolation, No Linkage and No Inference."
Sinngemäss: Das Framework selbst stellt drei Kriterien bereit, mit denen sich testen lässt, ob Daten anonym sind: No Record Isolation (keine Datensatz-Isolierung), No Linkage (keine Verknüpfung) und No Inference (keine Inferenz).
Nebeneinander, Klausel gegen Klausel:
| WP216 (2014, final), S. 13 der dt. Fassung | Entwurf 02/2026, §3.4 (in Konsultation; Zitate im Original) | Was sich verschoben hat |
|---|---|---|
| «Herausgreifen (singling out), d. h. die Möglichkeit, in einem Datenbestand einige oder alle Datensätze zu isolieren, welche die Identifizierung einer Person ermöglichen» | Rn. 55: "The No Record Isolation criterion is met if the data does not contain a unique combination of attribute values that relate to a single individual." | Aus dem Angriff wird eine strukturelle Einzigartigkeitsprüfung; das Aussondern selbst wandert in eine Folgestufe (Rn. 98–99). |
| «Verknüpfbarkeit, d. h. die Fähigkeit, mindestens zwei Datensätze, welche dieselbe Person oder Personengruppe betreffen, zu verknüpfen (in derselben Datenbank oder in zwei verschiedenen Datenbanken).» | Rn. 60: "The No Linkage criterion is met if the data does not contain an individual's record which could be linked to another record which (a) also relates (with certainty or high likelihood) to that same individual, and (b) comes from a different dataset." | Doppelt verengt: nur noch auf Ebene der Einzelperson, nur noch datensatzübergreifend, mit ausdrücklicher Wahrscheinlichkeitsschwelle. Gruppen- und Aggregatverknüpfung wandern ins dritte Kriterium (Rn. 80: solche Verknüpfung "can also be seen as a form of inference"). |
| «Inferenz, d. h. die Möglichkeit, den Wert eines Merkmals mit einer signifikanten Wahrscheinlichkeit von den Werten einer Reihe anderer Merkmale abzuleiten.» | Rn. 67: "The No Inference criterion is met if no specific and meaningful inference can be drawn from the given data." | Ein Wesentlichkeitsfilter kommt hinzu: Die Inferenz muss sich auf "a single identified or identifiable individual" beziehen, geeignet sein, "an effect on the data subject's rights and interests" zu haben, und darf nicht aus "general knowledge or from data about the population at large" zu gewinnen sein. |
Die Polarität des gesamten Tests hat sich mitgedreht. Rn. 52 (S. 18):
"violating a criterion does not necessarily mean that the information must necessarily be considered as personal data; rather, if one or more of the criteria is violated, it is then necessary to continue the analysis, as set out in sub-section 3.5.3, to assess the impact of that violation and whether the data could still be considered anonymous."
Sinngemäss: Die Verletzung eines Kriteriums bedeutet nicht zwingend, dass die Information als personenbezogen gelten muss; vielmehr ist bei einem oder mehreren verletzten Kriterien die Analyse nach Unterabschnitt 3.5.3 fortzusetzen, um die Auswirkung der Verletzung zu bewerten und zu prüfen, ob die Daten dennoch als anonym gelten können.
Die 2014er-Fassung dieser Regel, die die finale Stellungnahme 28/2024 weiterhin aus WP216 zitiert, lautet in der deutschen Fassung (S. 29): «Erfüllt ein Vorschlag eines der Kriterien nicht, sollte eine gründliche Evaluierung der hinsichtlich einer Identifizierung bestehenden Risiken vorgenommen werden.» Der Entwurf macht aus dieser Fussnote Architektur. Rn. 98 schickt ein gescheitertes No-Record-Isolation-Ergebnis in eine nachgelagerte Aussonderungs-Analyse, und Rn. 99 schreibt ein Ergebnis auf, das 2014 nie formuliert hat: "If this singling out cannot be done – and the other two criteria have been successfully met – then the given data can still be considered anonymous, despite failing the No Record Isolation criterion." Sinngemäss: Ist dieses Aussondern nicht möglich — und sind die beiden anderen Kriterien erfüllt —, können die Daten trotz verletztem No-Record-Isolation-Kriterium weiterhin als anonym gelten. Einzigartige Datensätze können also anonym bleiben, wenn es nichts gibt, wogegen man sie abgleichen könnte.
Was sich nicht geändert hat: Es ist weiterhin ein dreiteiliger Test, und der Entwurf verankert alles im Massstab des Erwägungsgrundes 26 — "reasonably likely", mit 46 Vorkommen in der Textebene des Entwurfs. Die Faktorenliste des Erwägungsgrundes 26 überlebt in der erweiterten Fassung von Rn. 29, mit einem Zusatz: Aus "technological developments" wird "reasonably foreseeable technological developments" — aus technologischen Entwicklungen die vernünftigerweise vorhersehbaren. Der Entwurf schärft auch die Identifizierbarkeit selbst (Executive Summary, S. 2): Eine Person gilt nur dann als identifizierbar, wenn ihre Unterscheidung "in a way that makes it possible to treat them differently" geschieht — so, dass sie sich dadurch unterschiedlich behandeln lässt —, ein zusätzliches Glied gegenüber Erwägungsgrund 26. Und Rn. 31 räumt ein entlastendes Argument ab: "The EDPB cautions against using 'lack of motivation' as a factor in this analysis." Sinngemäss: Fehlende Motivation zählt in dieser Analyse nicht als Faktor.
Eine Gabelung zum Beobachten: Die finale Stellungnahme 28/2024 (Rn. 40) verankert Modell-Anonymität weiterhin am Trio unter seinen 2014er-Namen — "single out, link and infer". Wird Entwurf 02/2026 unverändert finalisiert, benennen die finale Stellungnahme des EDSA und seine neuen Leitlinien den operativen Test unterschiedlich. Das ist ein Konsultationskommentar, der darauf wartet, geschrieben zu werden.
Zuerst das Gefestigte. Die Stellungnahme 28/2024 (final, angenommen am 17. Dezember 2024) hält in Rn. 34 fest, dass KI-Modelle, die mit personenbezogenen Daten trainiert wurden, "cannot, in all cases, be considered anonymous. Instead, the determination of whether an AI model is anonymous should be assessed, based on specific criteria, on a case-by-case basis." Sinngemäss: Sie können nicht in allen Fällen als anonym gelten; ob ein KI-Modell anonym ist, ist anhand spezifischer Kriterien im Einzelfall zu beurteilen. Der Mechanismus steht in Rn. 31: Trainingsdaten "may still remain 'absorbed' in the parameters of the model" — können in den Parametern des Modells «absorbiert» bleiben. Nach Rn. 38 sollte eine Aufsichtsbehörde "sufficient evidence that, with reasonable means: (i) personal data, related to the training data, cannot be extracted out of the model; and (ii) any output produced when querying the model does not relate to the data subjects whose personal data was used to train the model" sehen. Sinngemäss: hinreichende Evidenz, dass sich mit vernünftigen Mitteln (i) keine auf die Trainingsdaten bezogenen personenbezogenen Daten aus dem Modell extrahieren lassen und (ii) keine Ausgabe einer Modellabfrage sich auf die betroffenen Personen bezieht, deren Daten zum Training verwendet wurden.
Nun der Scraping-Entwurf. Die Anwendungsbereichs-Klausel des Leitlinien-Entwurfs 03/2026 (Rn. 12, Entwurfstext) bekräftigt die Anwendbarkeit: "The GDPR will apply to web scraping when it includes processing operations, such as extraction, cleaning, structuring and storing of personal data" — die DSGVO gilt für Web Scraping, sobald es Verarbeitungsvorgänge wie Extraktion, Bereinigung, Strukturierung und Speicherung personenbezogener Daten umfasst —, einschliesslich "data that indirectly identifies an individual (i.e. information that can be linked to an identifiable individual considering all the means reasonably likely to be used)", Daten also, die eine Person indirekt identifizieren. Ein Hinweis: Das «2020603» im PDF-Dateinamen ist der Tippfehler des EDSA selbst; der Link ist zitiert, wie veröffentlicht.
Was der Entwurf nicht tut — festgestellt durch protokollierte Suchen, nicht durch Annahme: Er nennt keine Bedingungen, unter denen gescrapte Daten oder ein daraus entstehendes Modell den Anwendungsbereich der DSGVO verlassen. Er erwähnt Erwägungsgrund 26 nie, zitiert die Stellungnahme 05/2014 nie und zitiert seinen Schwester-Entwurf 02/2026 nie. Anonymisierung erscheint nur als Abhilfemassnahme — Rn. 38 (Entwurfstext): "where feasible, anonymise or alternatively pseudonymise personal data" — wo machbar, anonymisieren oder ersatzweise pseudonymisieren; Rn. 66(g): "Deleting or anonymising the unnecessary personal data as soon as possible" — nicht benötigte personenbezogene Daten so schnell wie möglich löschen oder anonymisieren.
Die News-Seite des EDSA sagt, die Scraping-Leitlinien bauten auf der KI-Modelle-Stellungnahme auf. Gegen das PDF geprüft ist diese Behauptung zutreffend und präzise begrenzt: Alle acht Zitate der Stellungnahme 28/2024 sitzen in den Abschnitten zu Zweckbindung und berechtigtem Interesse. Die drei Dokumente teilen sich also die Arbeit. Entwurf 02/2026 sagt, wann Daten anonym sind. Die finale Stellungnahme 28/2024 sagt, wann ein Modell anonym ist. Entwurf 03/2026 sagt, wie man rechtmässig scrapt, sofern die DSGVO gilt — einschliesslich, nach Rn. 14 (Entwurfstext), dass "compliance with regard to Article 5(2) GDPR must be met by the controller" — die Rechenschaftspflicht nach Artikel 5(2) DSGVO also vom Verantwortlichen zu erfüllen ist —, selbst dort, wo der Entwurf einräumt, Rechenschaft sei "not obvious", nicht offensichtlich. Die Naht, die ich in einer Konsultationsantwort ansprechen würde: 03/2026 empfiehlt, gescrapte personenbezogene Daten zu anonymisieren, ohne den Test zu benennen, den die Anonymisierung bestehen muss, und ohne 02/2026 zu zitieren.
Durchsetzungskontext: Italiens Garante hat grossflächiges Scraping durch Entwickler generativer KI bereits in seiner Verfügung vom 20. Mai 2024 adressiert (registro n. 329, Gazzetta Ufficiale n. 132 vom 7. Juni 2024; nur auf Italienisch), einschliesslich Abwehrmassnahmen, die Website-Betreiber einsetzen können.
Die Position, exakt so weit formuliert, wie die Texte tragen: Ein Export, der (i) auf Datensatzebene liegt, (ii) über eine persistente Kennung verknüpft ist und (iii) hochdimensional ist, sitzt auf der durchfallenden Seite der entwurfseigenen Kriterien. Ob das «die meisten» Analytics-Daten beschreibt, sagt kein Text — und ich auch nicht.
Die Faustregel des Entwurfs (Rn. 86): "As a rule of thumb, (re-) identification techniques are more likely to be effective against record-level data with high dimensionality and high resolution. By contrast, many (re-)identification techniques are less likely to be effective against data which is aggregated through mathematical functions into statistical indicators (e.g. averages)". Sinngemäss: Reidentifizierungstechniken wirken erfahrungsgemäss eher gegen Daten auf Datensatzebene mit hoher Dimensionalität und hoher Auflösung; gegen Daten, die über mathematische Funktionen zu statistischen Kennzahlen aggregiert sind (z. B. Durchschnitte), wirken viele dieser Techniken weniger. Rn. 85 definiert Dimensionalität als "the number of columns in a table for each individual record" — die Zahl der Spalten pro Einzeldatensatz; und "a full date of birth has a higher resolution than the year of birth alone" — ein vollständiges Geburtsdatum hat eine höhere Auflösung als das Geburtsjahr allein. Eine Produkt-Analytics-Eventtabelle punktet bauartbedingt auf beidem hoch.
Zu persistenten Kennungen, Rn. 62 (Entwurfstext): "Linkage may often be possible by reference to a common identifier (e.g., an internal customer number) which is used in both datasets, or by matching records based on certain combinations of attributes." Sinngemäss: Verknüpfung ist oft über eine gemeinsame Kennung möglich (etwa eine interne Kundennummer), die in beiden Datenbeständen verwendet wird, oder über den Abgleich von Datensätzen anhand bestimmter Merkmalskombinationen. Und Beispiel 6 des Entwurfs ist der Web-Analytics-Fall selbst: Mehrere Websites teilen Seitenbesuchsdaten mit einem Dritt-Werbeanbieter, verknüpft über "a pseudonym which is based on fingerprints from the users' devices" — ein Pseudonym auf Basis von Geräte-Fingerprints. Die Schlussfolgerung des Entwurfs: "both the raw fingerprint data (as a combination of attributes) and the pseudonym which is derived from that data (as an identifier) allow for the identification of the individual. This is true for both the websites and the third party." Sinngemäss: Sowohl die rohen Fingerprint-Daten (als Merkmalskombination) als auch das daraus abgeleitete Pseudonym (als Kennung) erlauben die Identifizierung der Person — und das gilt für die Websites wie für den Dritten. Auch Kosten sind kein Refugium; nach Rn. 92 gilt für die meisten dokumentierten Reidentifizierungstechniken, dass sie "require limited resources and can be performed within a reasonable timeframe, even on commodity hardware" — begrenzte Ressourcen verlangen und sich in vertretbarer Zeit durchführen lassen, selbst auf handelsüblicher Hardware —, gerade gegen Daten auf Datensatzebene.
Den Schlüssel zu hashen oder zu rotieren ändert die Einstufung für sich genommen nicht. Entwurf 02/2026 Rn. 50 führt unter den unmittelbar nicht anonymen Fällen einen Datenbestand mit "pseudonyms that can easily be reverse engineered to discover an identifier" — Pseudonymen, die sich leicht zu einer Kennung zurückrechnen lassen. Die Pseudonymisierungs-Leitlinien des EDSA (Leitlinien 01/2025, weiterhin eine Konsultationsfassung, angenommen am 16. Januar 2025, ohne finalen Text zum Zeitpunkt dieses Beitrags; Entwurf 03/2026 zitiert sie selbst mit ausgeschriebenem Status) sagen in Rn. 22, dass selbst nach Löschung aller zusätzlichen Informationen gilt: "the pseudonymised data becomes anonymous only if the conditions for anonymity are met." Sinngemäss: Die pseudonymisierten Daten werden nur dann anonym, wenn die Bedingungen für Anonymität erfüllt sind.
Die Fluchttüren sind real. Rn. 99 (oben zitiert) lässt einzigartige Datensätze anonym bleiben, wenn nichts gegen sie abgeglichen werden kann, und Beispiel 24 zeigt es: eine Kino-Umfrage mit geheimer Abstimmung, in der "there is no way to link the answers to their identity ... nor to treat any respondent differently" — es keinen Weg gibt, die Antworten mit der Identität der Befragten zu verknüpfen oder einzelne Befragte unterschiedlich zu behandeln —, ist trotz verletztem No Record Isolation anonym. Für einen verknüpften Analytics-Export leisten diese Türen wenig: Die persistente Kennung existiert genau dazu, dieselbe Person über Sessions und Tabellen hinweg zu verknüpfen. Sie liefert die Abgleichsfähigkeit, die den Befragten aus Beispiel 24 fehlt.
Die Prüfung selbst, geordnet, wie der Entwurf sie ordnet. Jede Zeile geht auf eine zitierte Klausel zurück:
Reidentifizierungs-Check — <Export-Name>, <Datum>Perspektive: jede Stelle, die auf die Daten zugreifen kann(Entwurf 02/2026 Rn. 30: Verantwortlicher, empfangende Stellen,"Rogue employees", böswillige Akteure; «fehlende Motivation»zählt nicht als Faktor, Rn. 31).[ ] 1. Datensatz-Isolierung (Rn. 55) Bezieht sich irgendeine Kombination von Merkmalswerten auf eine einzelne Person? Eine persistente User-ID oder ein Device-Fingerprint tut das nach der Logik von Beispiel 6; mehr Spalten erhöhen die Einzigartigkeit (Rn. 56).[ ] 2. Nachgelagertes Aussondern (Rn. 98-99) Falls Datensätze isolierbar sind: Lassen sie sich mit Merkmalen einer Person in irgendwelchen Daten abgleichen,
Das erste Prüffeld hat in SQL eine offensichtliche Form (illustrativ; eigene Quasi-Identifikator-Spalten und Tabelle einsetzen):
-- Einzigartige Kombinationen verletzen No Record Isolation (Rn. 55)
SELECT plan, country, signup_week, COUNT(*) AS matches
FROM analytics_export
GROUP BY plan, country, signup_week
HAVING COUNT(*) = 1;Wo jedes Artefakt verankert ist, zählt hier, denn zwei der drei massgeblichen Dokumente können sich noch ändern:
Eine weitere 02/2026-Zeile (Entwurf, Rn. 40) gehört neben jede Fragebogen-Antwort: "controllers should not use descriptions like 'anonymous', 'de-identified' or 'de-personalised' if individuals are actually still identifiable." Sinngemäss: Verantwortliche sollten Beschreibungen wie «anonym», «de-identifiziert» oder «de-personalisiert» nicht verwenden, wenn Einzelpersonen tatsächlich noch identifizierbar sind.
Zusammengesetzt nennt eine Antwort, die die Texte tragen, einen Test, eine Perspektive, ein Datum und einen Ablageort:
F: Sind die Daten, die Sie bereitstellen/vorhalten, anonymisiert?A: Wir stufen <Datenbestand> als <anonymisiert | pseudonymisiert, d. h. weiterhin personenbezogen> ein. Beurteilt gegen die Reidentifizierungs-Kriterien der WP29-Stellungnahme 05/2014 (S. 13 der dt. Fassung) und des EDSA-Leitlinien-Entwurfs 02/2026 Abschnitt 3.4 (No Record Isolation, No Linkage, No Inference — Entwurf, in öffentlicher Konsultation bis 30. Oktober 2026). Perspektive: <Stellen mit Zugriff auf die Daten>. Ergebnis: <pro Kriterium, einschl. der nachgelagerten Aussonderungs-Analyse für jedes verletzte Kriterium>. Zuletzt beurteilt: <Datum>; Wiederholung bei neuen Datenquellen, neuen Techniken, Sicherheitsvorfällen (Entwurf 02/2026 Rn. 42, 84; WP216 S. 29: kein «Freigeben und Vergessen»). Evidenz: Prozessdokumentation der Anonymisierung einschl. Testberichten unter <Ablageort> (Entwurf 02/2026 Rn. 41;
Der Test hinter «wir haben das anonymisiert» existiert wieder schriftlich — als Entwurf. Lassen Sie die drei Kriterien gegen Ihre eigenen Exporte laufen, bevor ein Fragebogen danach fragt. Falls der Entwurfswortlaut Ihre Antwort brechen würde: Die Konsultation zu beiden Leitlinien läuft bis zum 30. Oktober 2026.
Diese Evidenzspur aktuell zu halten (die Prozessdokumentation der Anonymisierung, die Testläufe, die DSFA-Einträge) ist genau die Art Arbeit, die devguard zur Routine machen soll.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.