Exercise 6 — PII Protection - Pseudonymization Round-Trip with an LLM

i

Was du lernst

Personenbezogene Daten (PII) mit Presidio erkennen und in reversible Platzhalter verwandeln.
Ein LLM ausschließlich mit pseudonymisierten Daten arbeiten lassen.
Den kompletten Roundtrip verfolgen: roh → pseudonymisiert → LLM-Antwort → re-identifiziert.
Die DSGVO-Unterschiede zwischen Pseudonymisierung und Anonymisierung einordnen.

0

Setup

Diese Aufgabe ist eigenständig und nutzt ein fertiges, funktionierendes Demo-Skript aus dem Repo bpm-pizza-pII. Du erklärst, führst und erweiterst dieses Skript — das Repo selbst wird nicht angefasst.

Repo bpm-pizza-pII klonen, dann Abhängigkeiten installieren:

cd bpm-pizza-pII
pip install -r requirements.txt

Zugangsdaten stehen NICHT im Projektverzeichnis, sondern in ~/.env (Home-Verzeichnis):

# ~/.env
PRESIDIO_API_KEY=...
PRESIDIO_API_USER=...
PRESIDIO_ANALYZER_URL=...
PRESIDIO_ANONYMIZER_URL=...
PRESIDIO_AIMAGE_REDACTOR_URL=...
LITELLM_PIZZA_URL=...
LITELLM_PIZZA_KEY=...
LITELLM_PIZZA_MODEL_1=...

Skript starten:

python3 pii_roundtrip.py --count 3

1

Schritt 1 — RAW DATA

Das Skript erzeugt zufällige (nicht pseudonymisierte) Kundendatensätze: Vorname, Nachname, E-Mail-Adresse auf aipizzasim.com, Geburtsdatum, Bestelldatum, bestellter Artikel und ein Vorfall. Genau diese Daten dürfen das Modell niemals erreichen.

In einem echten Setup käme dieser Datensatz aus einer internen Kundendatenbank oder einer vergleichbaren Quelle.

=== RAW record #1 ===
first_name: Sofia
last_name: Bergmann
email: [email protected]
date_of_birth: 1987-03-14
order_date: 2026-07-22
item: Pizza Quattro Stagioni
incident: pizza arrived cold, box crushed

2

Schritt 2 — PSEUDONYMIZED

Der Datensatz geht an den Presidio-Analyzer; die erkannten Entitäten werden vom Presidio-Anonymizer in reversible Platzhalter verwandelt, zum Beispiel <PERSON_1>, <EMAIL_ADDRESS_1>, <DATE_TIME_1> und <DATE_TIME_2>. Die hier ausgegebene Zuordnung ist der Pseudonymisierungsschlüssel.

=== PSEUDONYMIZED record #1 ===
Dear <PERSON_1>, your order of Pizza Quattro Stagioni on <DATE_TIME_1>
arrived cold and the box was crushed. Please contact us at <EMAIL_ADDRESS_1>.
Your date of birth on file: <DATE_TIME_2>.

--- pseudonymization key ---
<PERSON_1>          -> Sofia Bergmann
<EMAIL_ADDRESS_1>   -> [email protected]
<DATE_TIME_1>       -> 2026-07-22
<DATE_TIME_2>       -> 1987-03-14

Nur Platzhalter reisen weiter: Ab hier sieht kein nachgelagerter Schritt mehr einen echten Namen, eine echte E-Mail-Adresse oder ein echtes Datum — nur noch Tokens wie <PERSON_1>.

3

Schritt 3 — LLM ANSWER

Der pseudonymisierte Datensatz geht zusammen mit dem Prompt an das LLM. Business Case: Die Bestellung wurde beim Transport beschädigt, das Modell schreibt eine Entschuldigungs-E-Mail, gewährt einen Kulanzgutschein über 140 EUR und legt weitere 10 EUR drauf, falls der Kunde vor seinem nächsten Geburtstag erneut bestellt. Die Antwort enthält weiterhin ausschließlich Platzhalter.

=== LLM ANSWER record #1 ===
Dear <PERSON_1>,

We are very sorry that your order arrived cold and the box was crushed
on <DATE_TIME_1>. As an apology, we are issuing a EUR 140.00 goodwill
voucher to <EMAIL_ADDRESS_1>. Order again before your birthday
(<DATE_TIME_2>) and we will add another EUR 10.00.

Best regards,
Roberto's Pizzeria

4

Schritt 4 — RE-IDENTIFIED

Die Platzhalter werden anhand des Pseudonymisierungsschlüssels wieder durch die Originalwerte ersetzt — das ist die E-Mail, die der Kunde tatsächlich erhält.

=== RE-IDENTIFIED record #1 (sent to the customer) ===
Dear Sofia Bergmann,

We are very sorry that your order arrived cold and the box was crushed
on 2026-07-22. As an apology, we are issuing a EUR 140.00 goodwill
voucher to [email protected]. Order again before your
birthday (1987-03-14) and we will add another EUR 10.00.

Best regards,
Roberto's Pizzeria

Nur der letzte Schritt sieht Klartext: Re-Identifizierung passiert lokal, mit dem Schlüssel aus Schritt 2 — das LLM selbst hat den echten Namen, die echte E-Mail-Adresse und das echte Datum nie gesehen.

5

Aufgaben zum Ausprobieren

Führe das Skript aus und verfolge die Daten durch alle vier Schritte.
Erkläre, welche Entitätstypen Presidio erkannt hat und welche nicht.
Ergänze eine Telefonnummer und eine Straßenadresse in den erzeugten Datensätzen und prüfe, was Presidio damit macht.
Entferne die Anweisung „copy every placeholder character by character“ aus dem System-Prompt, führe erneut aus und beobachte, was in Schritt 4 kaputtgeht.
Führe das Skript mit --count 5 --seed 42 aus und erkläre, warum die Platzhalter-Nummerierung pro Datensatz neu beginnt.
Bonus: nutze PRESIDIO_AIMAGE_REDACTOR_URL, um PII aus einem Bild zu schwärzen.

6

Diskussion & Präsentation

Pseudonymisierung vs. Anonymisierung — was ist der rechtliche Unterschied?
Wo muss die Zuordnung (der Schlüssel) gespeichert werden, und wer darf darauf zugreifen?
Sind pseudonymisierte Daten nach DSGVO noch „personenbezogene Daten“?
Was sind die Restrisiken — Re-Identifizierung durch Kontext, Quasi-Identifikatoren?
Nur Reflexion, keine Umsetzung: Woher könnten die Eingabedaten realistisch stammen — eine interne Kundendatenbank, ein CRM-Export, oder der Retrieval-Schritt eines RAG-Systems? Was würde sich ändern, wenn die Datensätze aus einer RAG-Pipeline kämen?
Relevante DSGVO-Artikel: Art. 4(5), Art. 5, Art. 25, Art. 32, Erwägungsgrund 26.

Erfolgskriterien:

Das Skript läuft Ende-zu-Ende gegen Presidio und das LLM-Gateway.
Die Ausgabe aller vier Schritte kann erklärt werden.
Kein echter Name, keine echte E-Mail-Adresse und kein echtes Datum erreicht das Modell.
Alle Platzhalter werden in Schritt 4 korrekt wiederhergestellt.
Die DSGVO-Implikationen können erklärt werden.

PII-Schutz - Pseudonymisierungs-Roundtrip mit einem LLM