Pseudonymisierung: Definition, Verfahren und ein Beispiel

Die Datenschutz-Grundverordnung definiert den Begriff selbst, und zwar in den Begriffsbestimmungen des Art. 4. Der Wortlaut ist präziser als die meisten Umschreibungen und lohnt das genaue Lesen, weil er die Bedingungen mitliefert, unter denen eine Verarbeitung überhaupt als Pseudonymisierung gilt.

In einem Satz erklärt: Pseudonymisierung ersetzt identifizierende Angaben durch Kennungen und verlagert das Wissen über die Zuordnung an einen anderen, besonders geschützten Ort. Die Definition enthält damit zwei Pflichten, nicht nur eine. Die erste betrifft den Datenbestand: Aus ihm allein darf niemand mehr auf die Person schließen. Die zweite betrifft den Rest: Die zusätzlichen Informationen müssen gesondert aufbewahrt werden und eigenen Schutzmaßnahmen unterliegen. Wer nur Namen ersetzt, die Zuordnungstabelle aber in derselben Datenbank und unter derselben Berechtigung ablegt, erfüllt die Definition nicht.

Der Begriff wird im Alltag oft synonym mit drei anderen Verfahren gebraucht, die etwas anderes tun. Die Unterschiede sind nicht akademisch, sie entscheiden darüber, was Sie mit den Daten hinterher noch anfangen können.

• Löschen entfernt die Angabe ersatzlos. Der Text wird kürzer, Bezüge gehen verloren, und niemand kann den Zustand vorher wiederherstellen. „Der Kunde“ statt eines Namens ist verständlich, aber zwei verschiedene Kunden im selben Dokument werden ununterscheidbar.
• Schwärzen (Redaktion) ersetzt die Angabe durch einen Platzhalter ohne Wiedererkennungswert, klassisch einen schwarzen Balken oder XXXX. Auch hier geht die Unterscheidbarkeit verloren: Fünf geschwärzte Namen sehen alle gleich aus.
• Verschlüsseln macht den gesamten Datenbestand unlesbar, nicht nur die personenbezogenen Stellen. Wer den Schlüssel hat, sieht alles; wer ihn nicht hat, sieht nichts. Eine Auswertung des Inhalts ist im verschlüsselten Zustand nicht möglich.
• Anonymisieren entfernt den Personenbezug endgültig, auch für die verarbeitende Stelle selbst. Es gibt keinen Schlüssel, mit dem sich der Ursprung zurückholen ließe. Die Details dazu behandelt der Beitrag Pseudonymisierung vs. Anonymisierung.

Pseudonymisierung liegt bewusst dazwischen. Sie erhält die Struktur des Textes und die Unterscheidbarkeit der Personen, sie erhält die Verwertbarkeit des Inhalts, und sie erhält die Möglichkeit der Rückführung für den, der dazu berechtigt ist. Das ist der Grund, warum sie in Verarbeitungsketten eingesetzt wird, in denen am Ende wieder ein konkreter Vorgang und eine konkrete Person stehen müssen.

Bei strukturierten Daten ist der erste Schritt trivial: Die Spalte heißt „Nachname“, also ist bekannt, was pseudonymisiert werden muss. Bei Freitext, also in E-Mails, Tickets, Protokollen, Schriftsätzen oder Arztbriefen, steht die identifizierende Angabe irgendwo im Satz, und der Prozess zerfällt in drei Schritte.

Erkennen. Zuerst muss gefunden werden, welche Zeichenfolgen überhaupt personenbezogen sind. Reguläre Ausdrücke reichen dafür nur bei formal festgelegten Mustern wie IBAN oder E-Mail-Adressen. Namen, Anschriften und identifizierende Datumsangaben lassen sich nicht über die Form bestimmen, sondern nur über den Kontext: „Berlin“ ist im Satz „wohnhaft in Berlin“ eine Adressangabe und in „die Berliner Messe“ keine. Persona setzt deshalb ein Sprachmodell ein, das auf dem offen lizenzierten Modell perplexity-ai/pplx-pii-masking (MIT-Lizenz) beruht und den Satzzusammenhang auswertet statt einer Musterliste.

Ersetzen. Jede erkannte Entität wird durch ein sprechendes Token ersetzt, etwa ⟨PERSON_1⟩ oder ⟨EMAIL_1⟩. Entscheidend ist die Konsistenz innerhalb eines Textes: Dieselbe Person behält über das ganze Dokument dasselbe Token. Erst dadurch bleibt ein Text logisch lesbar: Wer wem was geschrieben hat, ergibt weiterhin Sinn, obwohl kein Klarname mehr darin steht. Persona unterscheidet dabei neun Kategorien von private_person bis other_pii und liefert zusätzlich einen Sensitivitätswert zwischen 0.0 und 1.0 für den gesamten Text.

Zuordnen. Aus dem Ersetzungsvorgang entsteht die Zuordnungstabelle: Token auf der einen, Originalwert auf der anderen Seite. Sie ist die „zusätzliche Information“ aus Art. 4 Nr. 5 DSGVO, und sie ist der Grund, warum Pseudonymisierung überhaupt umkehrbar ist.

Die Zuordnungstabelle ist der empfindlichste Teil des Verfahrens. Wer sie besitzt, hebt die Pseudonymisierung mit einem Suchen-und-Ersetzen wieder auf. Die DSGVO schreibt keinen konkreten Speicherort vor, macht aber zwei Vorgaben, die sich schlecht umgehen lassen: gesonderte Aufbewahrung und eigene technische sowie organisatorische Maßnahmen.

Für die Praxis folgt daraus ein kleiner Satz von Regeln:

• Getrennt speichern. Nicht in derselben Tabelle, möglichst nicht im selben System und nicht unter derselben Berechtigung wie der pseudonymisierte Bestand.
• Zugriff eng fassen. Nur die Rollen, die den Personenbezug fachlich benötigen, dürfen die Tabelle einsehen. Analyse, Auswertung und Modellbetrieb gehören regelmäßig nicht dazu.
• Verschlüsselt ablegen. Die Tabelle im Ruhezustand zu verschlüsseln ist der Regelfall, nicht die Kür.
• Eigene Löschfrist führen. Wird die Zuordnung gelöscht, verliert der pseudonymisierte Bestand für die verantwortliche Stelle seinen Rückweg. Das ist ein wirksamer und dokumentierbarer Schritt. Ob er in Ihrem Fall bereits Anonymisierung bedeutet, ist eine Frage des Einzelfalls und der verbleibenden Zusatzinformationen.
• Protokollieren. Jede Re-Identifikation sollte nachvollziehbar sein: wer, wann, zu welchem Zweck.

Persona arbeitet an dieser Stelle zustandslos. Das Mapping entsteht während der Anfrage, wird in der Antwort zurückgegeben und danach nicht gespeichert. Anfragetexte werden weder inhaltlich protokolliert noch für Training verwendet. Wo die Zuordnung anschließend liegt und wer sie sehen darf, entscheiden Sie in Ihrem eigenen System.

„Pseudonymisierung“ beschreibt ein Ziel, kein einzelnes Verfahren. Vier Techniken sind gebräuchlich, und sie unterscheiden sich vor allem darin, wodurch sich die Ersetzung rückgängig machen lässt und wie groß das verbleibende Re-Identifikationsrisiko ist.

Für Freitext hat die Ersetzung durch sprechende Tokens einen praktischen Vorteil, den die anderen Verfahren nicht bieten: Ein nachgelagertes System, ob Auswertungsschritt, Sprachmodell oder Sachbearbeitung, kann mit ⟨PERSON_1⟩ im Satz weiterarbeiten, mit einem 64-stelligen Hash dagegen nicht.

In der Aufzählung geeigneter Maßnahmen in Art. 32 Abs. 1 DSGVO steht an erster Stelle wörtlich „die Pseudonymisierung und Verschlüsselung personenbezogener Daten“. Beide werden also in einem Atemzug genannt, und das ist kein Zufall, sondern eine Arbeitsteilung.

Verschlüsselung schützt gegen Dritte, die keinen Zugriff haben sollen: gegen den Verlust eines Datenträgers, gegen das Mitlesen auf dem Transportweg, gegen den unbefugten Zugriff auf die Ablage. Sie wirkt binär. Solange der Schlüssel fehlt, ist nichts lesbar; sobald er vorliegt, ist alles lesbar, auch die personenbezogenen Teile.

Pseudonymisierung schützt in der anderen Richtung: gegen das Risiko, das entsteht, während jemand mit den Daten arbeiten darf. Analyst, Auswertungssystem und Auftragsverarbeiter bekommen die Daten notwendigerweise im Klartext zu sehen. Pseudonymisierung sorgt dafür, dass dieser Klartext keine identifizierenden Angaben mehr enthält, obwohl er inhaltlich vollständig auswertbar bleibt.

Zusammen ergibt das die übliche Konstruktion: Der pseudonymisierte Bestand wandert durch die Verarbeitungskette, die Zuordnungstabelle liegt verschlüsselt an einem separaten Ort mit engem Zugriff. Fällt eine der beiden Maßnahmen aus, trägt die andere weiter. Das ist der Sinn der Kombination.

Ein deutscher Satz, wie er in einem Ticket oder einer Mail stehen könnte, vor der Verarbeitung:

Bitte prüfen Sie den Vorgang von Jonas Bergmann, geboren am 14.03.1987,
wohnhaft Lindenstraße 12, 10969 Berlin. Rückfragen an
j.bergmann@example.de oder 0176 22558899.

Und danach:

Bitte prüfen Sie den Vorgang von ⟨PERSON_1⟩, geboren am ⟨DATE_1⟩,
wohnhaft ⟨ADDRESS_1⟩. Rückfragen an ⟨EMAIL_1⟩ oder ⟨PHONE_1⟩.

Der Satz bleibt vollständig verständlich. Ein nachgelagertes System erkennt weiterhin, dass es um einen Vorgang, eine Person mit Geburtsdatum, eine Anschrift und zwei Kontaktwege geht. Es erfährt nur nicht mehr, um wen es sich handelt.

Über die API sieht derselbe Vorgang so aus. Die Anfrage enthält nichts außer dem Text und dem Bearer-Token:

POST /v1/pseudonymize HTTP/1.1
Host: persona-api.mind-verse.de
Authorization: Bearer ps_live_…
Content-Type: application/json

{
  "text": "Bitte prüfen Sie den Vorgang von Jonas Bergmann, geboren am 14.03.1987, wohnhaft Lindenstraße 12, 10969 Berlin. Rückfragen an j.bergmann@example.de oder 0176 22558899."
}

Die Antwort liefert vier Dinge: den maskierten Text, die erkannten Entitäten mit zeichengenauen Positionen, die Zuordnungstabelle und einen Sensitivitätswert für den gesamten Text. Die Struktur ist fest, die konkreten Werte hängen vom Eingabetext ab:

{
  "masked": "Bitte prüfen Sie den Vorgang von ⟨PERSON_1⟩, geboren am ⟨DATE_1⟩, wohnhaft ⟨ADDRESS_1⟩. Rückfragen an ⟨EMAIL_1⟩ oder ⟨PHONE_1⟩.",
  "spans": [
    {"label": "private_person",  "token": "⟨PERSON_1⟩",  "start":  33, "end":  47, "text": "Jonas Bergmann"},
    {"label": "private_date",    "token": "⟨DATE_1⟩",    "start":  60, "end":  70, "text": "14.03.1987"},
    {"label": "private_address", "token": "⟨ADDRESS_1⟩", "start":  81, "end": 110, "text": "Lindenstraße 12, 10969 Berlin"},
    {"label": "private_email",   "token": "⟨EMAIL_1⟩",   "start": 126, "end": 147, "text": "j.bergmann@example.de"},
    {"label": "private_phone",   "token": "⟨PHONE_1⟩",   "start": 153, "end": 166, "text": "0176 22558899"}
  ],
  "mapping": {
    "⟨PERSON_1⟩": "Jonas Bergmann",
    "⟨DATE_1⟩": "14.03.1987",
    "⟨ADDRESS_1⟩": "Lindenstraße 12, 10969 Berlin",
    "⟨EMAIL_1⟩": "j.bergmann@example.de",
    "⟨PHONE_1⟩": "0176 22558899"
  },
  "sensitivity": 0.86
}

Die Angaben in start und end sind Zeichenpositionen im Originaltext, Ende exklusiv: "Jonas Bergmann" beginnt an Position 33 und endet vor Position 47. Damit lässt sich die Ersetzung in einer eigenen Oberfläche exakt nachvollziehen, hervorheben oder selektiv rückgängig machen. Die vollständige Feldreferenz und Codebeispiele stehen in der API-Dokumentation; wer den Effekt zuerst an eigenem Text sehen möchte, kann das im Browser mit dem Tool Text anonymisieren tun.

Diese Frage entscheidet darüber, ob die DSGVO auf den pseudonymisierten Bestand weiterhin anwendbar ist. Die Antwort steht in Erwägungsgrund 26 und ist eindeutig.

Pseudonymisierte Daten sind also personenbezogene Daten. Rechtsgrundlage, Zweckbindung, Informationspflichten, Betroffenenrechte, Löschkonzept und Verarbeitungsverzeichnis gelten unverändert weiter. Das ist kein Randdetail, sondern der häufigste Irrtum zum Thema: Die Pseudonymisierung nimmt eine Verarbeitung nicht aus dem Anwendungsbereich der Verordnung heraus, sie senkt das Risiko innerhalb des Anwendungsbereichs.

Der Unterschied zur Anonymisierung liegt genau hier. Sind Daten wirksam anonymisiert, ist die DSGVO auf sie nicht mehr anwendbar, weil kein Personenbezug mehr herstellbar ist. Wie hoch die Hürde dafür tatsächlich liegt und warum viele als „anonymisiert“ bezeichnete Datenbestände die Bedingung nicht erfüllen, behandelt der direkte Vergleich beider Verfahren.

Art. 32 Abs. 1 DSGVO verlangt technische und organisatorische Maßnahmen, die dem Risiko der Verarbeitung angemessen sind, und nennt die Pseudonymisierung ausdrücklich als Beispiel. Art. 25 Abs. 1 führt sie ein zweites Mal an, dort als Beispiel für Datenschutz durch Technikgestaltung. Sie ist damit eine der wenigen Maßnahmen, die die Verordnung beim Namen nennt.

Für die Dokumentation heißt das: Pseudonymisierung gehört in die Beschreibung der technischen und organisatorischen Maßnahmen im Verarbeitungsverzeichnis, und zwar konkret. Nützlich ist eine Beschreibung, die vier Fragen beantwortet: welche Kategorien personenbezogener Daten ersetzt werden, an welcher Stelle der Verarbeitungskette das geschieht, wo die Zuordnungstabelle liegt und wer sie einsehen darf. Eine Zeile „wir pseudonymisieren“ trägt in einer Prüfung wenig.

Wirksam ist die Maßnahme nur, wenn die Trennung real ist. Liegen pseudonymisierter Bestand und Zuordnungstabelle im selben System unter derselben Berechtigung, ist der Risikounterschied gering, auch wenn technisch ersetzt wurde. Und wo ein externer Dienstleister eingebunden ist, ersetzt die Pseudonymisierung keinen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO. Sie verringert nur, was dieser Dienstleister überhaupt zu sehen bekommt.

Hinweis: Diese Seite ist eine technische Orientierung, keine Rechtsberatung. Ob eine bestimmte Maßnahme in Ihrer Verarbeitung angemessen ist, beurteilen Ihr Datenschutzbeauftragter oder Ihre Rechtsberatung anhand des konkreten Falls.

In klassischen Anwendungsfällen wie Forschung, Statistik oder Auswertung ist die Umkehrbarkeit eine Option, die man selten braucht. In Verarbeitungsketten mit Sprachmodellen ist sie der Kern der Sache, denn die Antwort des Modells muss am Ende wieder auf den echten Vorgang passen. Ein Antwortentwurf, der an ⟨PERSON_1⟩ adressiert ist, hilft niemandem; er muss den Namen tragen, den die Sachbearbeitung gleich verschickt.

Daraus ergibt sich ein Ablauf mit drei Stationen:

• Der Prompt wird pseudonymisiert, bevor er das eigene System verlässt: POST /v1/pseudonymize liefert masked und mapping.
• Nur der maskierte Text geht an das Sprachmodell. Das Modell arbeitet mit den Tokens und gibt sie in seiner Antwort unverändert zurück, weil es sie als Namen behandelt.
• Die Antwort wird lokal wieder aufgelöst: POST /v1/reidentify setzt anhand des Mappings die Originalwerte ein.

Das Mapping verlässt dabei nie Ihre Kontrolle: Es entsteht in der Antwort des ersten Aufrufs und wird von Persona nicht gespeichert. Die Analyse selbst läuft auf dedizierten Servern bei Hetzner in Falkenstein in nach ISO 27001 zertifizierten Rechenzentren; ein externer KI-Dienst wird dafür nicht aufgerufen. Für Konstellationen, in denen auch das nicht genügt, sieht der Enterprise-Tarif den Betrieb als Container in der eigenen Umgebung vor.

Zu beachten bleibt zweierlei. Erstens ist auch der pseudonymisierte Prompt weiterhin ein personenbezogenes Datum, wenn Sie das Mapping haben; Erwägungsgrund 26 gilt hier wie überall. Zweitens ersetzt die Maßnahme keine der übrigen Prüfungen, die beim Einsatz externer Modelle anstehen; welche das sind, fasst der Beitrag KI DSGVO-konform einsetzen zusammen. Was Pseudonymisierung leistet, ist präzise beschreibbar und deshalb wertvoll: Sie verkleinert die Menge personenbezogener Daten, die den kontrollierten Bereich überhaupt verlässt, und zwar unabhängig davon, welches Modell am anderen Ende steht.