Textdaten und strukturierte Daten unterscheiden sich fundamental wenn es um Anonymisierung und Pseudonymisierung geht – technisch und datenschutzrechtlich.
Bei Textdaten wie E-Mails, Schriftsätzen oder Freitextfeldern liegt die Hauptschwierigkeit darin, überhaupt zuverlässig zu erkennen, was pseudonymisiert werden muss: Namen, Orte, Organisationen, aber auch Telefonnummern, IBANs, Termine, seltene Ereignisse und indirekte Hinweise. Das geschieht typischerweise über Named Entity Recognition, manchmal ergänzt um Kontextbetrachtungen für indirekte Identifikatoren. Die häufig unterschätzte Herausforderung ist hier Vollständigkeit und Konsistenz.
Bei strukturierten Daten wie Tabellen oder Datenbanken ist das anders. Hier sind Positionen und Typen klar, das Schema beschreibt was wo steht. Direkte Identifikatoren zu pseudonymisieren ist daher relativ einfach, aber oft nicht ausreichend. Denn auch scheinbar harmlose Spalten können in Kombination Personen eindeutig machen.
Ein Beispiel:
Eine Tabelle enthält Autokäufe, die Personen wurden durch IDs pseudonymisiert. Automodell und Kaufdatum wirken harmlos. Aber wenn ich von jemanden weiß, der am 22.04.2022 einen Audi A3 gekauft hat und diese Kombination nur einmal vorkommt, reicht dieses Wissen aus, um die entsprechende Zeile zu finden und alle weiteren Informationen dieser Zeile sowie alle weiteren Zeilen mit dieser Personen ID zuzuordnen.
Hier setzt k-Anonymität an. Sie verallgemeinert Daten, etwa „04/2022“ statt eines exakten Datums oder „Kleinwagen“ statt eines konkreten Modells, so dass keine Zeile mehr eindeutig heraussticht. In der Praxis ist k-Anonymität dabei oft nur ein Baustein, je nach Kontext sind weitere Maßnahmen nötig. One-fits-all Lösungen gibt es nicht.
Was häufig übersehen wird: Auch Sammlungen gleichartiger Texte müssen ähnlich gedacht werden.
Liegen viele gleichartige Dokumente vor, etwa Arztbriefe oder Gutachten, kann man sie konzeptionell wie eine Tabelle betrachten – ein Dokument entspricht einer Zeile. Selbst wenn jedes einzelne Dokument sauber pseudonymisiert ist, kann die Gesamtheit über seltene Kombinationen von Inhalten re-identifizierend wirken. Entitäten zu ersetzen reicht dann nicht, man muss auch die Verteilung über alle Dokumente hinweg bewerten.
Viele dieser Verfahren werden umgangssprachlich als „Anonymisierung“ bezeichnet. Rechtlich bleiben die Daten jedoch häufig pseudonymisiert oder de-identifiziert und damit weiter im Anwendungsbereich der DSGVO.
Und genau deshalb ist
„Liebe IT, fügt mal schnell eine Anonymisierung ein. Da gibt es doch Open Source oder ist im Tool XYZ schon drin!“
selten eine gute Idee. Ohne sauberes Datenmodell, Angreifermodell und Nutzungskonzept endet das oft in unpassenden Ergebnissen, Frust, langen Diskussionen und einem Mammut-Projekt, das am Ende niemand verantworten oder pflegen will.
Wir bei Glanos helfen.
ENGLISH
Text data and structured data differ fundamentally when it comes to anonymization and pseudonymization—both technically and from a data protection perspective.
With text data such as emails, legal documents, or free-text fields, the main difficulty lies in reliably identifying what needs to be pseudonymized: names, locations, organizations, but also telephone numbers, IBANs, appointments, rare events, and indirect clues. This is typically done using Named Entity Recognition, sometimes supplemented by contextual considerations for indirect identifiers. The often underestimated challenge here is completeness and consistency.
With structured data such as tables or databases, the situation is different. Here, positions and types are clear; the schema describes what is located where. Pseudonymizing direct identifiers is therefore relatively easy, but often insufficient. Even seemingly harmless columns can, in combination, uniquely identify individuals.
For example:
A table contains car purchases; the individuals have been pseudonymized using IDs. The car model and purchase date appear harmless. But if I know of someone who bought an Audi A3 on April 22, 2022, and this combination occurs only once, this knowledge is sufficient to find the corresponding row and assign all further information to that row, as well as all other rows with that person’s ID.
This is where k-anonymity comes in. It generalizes data, for example, “04/2022” instead of an exact date or “small car” instead of a specific model, so that no row stands out uniquely. In practice, k-anonymity is often just one component; depending on the context, further measures are necessary. There are no one-size-fits-all solutions.
What is often overlooked: Collections of similar texts must also be considered similarly.
If there are many similar documents, such as medical letters or expert opinions, they can be conceptually viewed like a table—one document corresponds to one row. Even if each individual document is cleanly pseudonymized, the entire collection can still be used to re-identify individuals through rare combinations of content. Simply replacing entities isn’t enough; you also need to evaluate the distribution across all documents.
Many of these methods are colloquially referred to as “anonymization.” However, legally, the data often remains pseudonymized or de-identified and thus still falls under the scope of the GDPR.
And that’s precisely why
“Dear IT, quickly add anonymization. There’s open source for that, or it’s already included in tool XYZ!”
is rarely a good idea. Without a sound data model, attacker model, and usage concept, this often leads to unsuitable results, frustration, lengthy discussions, and a mammoth project that ultimately no one wants to take responsibility for or maintain.
We at Glanos can help.