Was ein Modell aus der Anfrage erfährt

Eine Anfrage an ein Sprachmodell ist Text, und in diesem Text stehen oft Angaben über Menschen. Was der Anbieter mit ihm tut, regeln seine Zusagen und der Vertrag. Wo das Modell rechnet, hängt am gewählten Weg. Was in der Anfrage steht, entscheidet allein der Absender. Dieses Kapitel handelt von diesem Teil.

Wer beim Anbieter hineinsehen darf, steht in Beurteilen und Einordnen, Kapitel 01. Wo der Text dort liegt und wie lange, klärt Beurteilen und Einordnen, Kapitel 08. Über welche Wege dasselbe Modell erreichbar ist, zeigt Kapitel 06. Hier geht es um die Frage davor: Was erfährt das Modell aus dem Text, den es bekommt?

Eine erfundene Beschwerde enthält zehn Angaben über Personen

Das Beispiel dieses Kapitels ist erfunden. Eine Kundin schreibt ihrem Energieversorger, und ein Mitarbeiter soll mit einem Sprachmodell eine Antwort entwerfen. Kundin, Vertrag und Konto sind erfunden. Die IBAN ist die verbreitete Beispiel-IBAN, die Adresse example.org ist für Beispiele reserviert.

Sehr geehrte Damen und Herren,

mein Name ist Jana Petersen. Ich wohne in der Goethestraße 12, 34119 Kassel,
Vertragsnummer 4711-2026-0815. Seit März wird mir der doppelte Abschlag
abgebucht, zuletzt am 03.10.2026 von meinem Konto DE89 3704 0044 0532 0130 00.
Am 12.09. habe ich mit Ihrem Mitarbeiter Herrn Schulte telefoniert, passiert
ist nichts. Als einzige Kinderärztin in unserem Ortsteil kann ich nicht
stundenlang in Ihrer Warteschleife hängen. Sie erreichen mich unter
0561 7654321 oder jana.petersen@example.org.

Mit freundlichen Grüßen
Jana Petersen

Neun Angaben führen unmittelbar zu einer Person: der Name der Kundin, Straße, Postleitzahl, Ort, Vertragsnummer, IBAN, Rufnummer, E-Mail-Adresse und der Name des Mitarbeiters. Die zehnte steht in einem Halbsatz. Eine Kinderärztin, die die einzige in ihrem Ortsteil ist, lässt sich mit einem Blick ins Branchenbuch finden.

Der Text betrifft zwei Personen, die Kundin und den Mitarbeiter. Die Vertragsnummer hat zudem ein Format, das nur der Versorger kennt.

Vier Schritte vom Text zur Antwort

Der übliche Schutz besteht darin, solche Angaben vor dem Versand zu ersetzen. Das geschieht in vier Schritten.

1. Erkennen. Ein Programm sucht im Text nach Namen, Anschriften, Nummern.
2. Ersetzen. Jede Fundstelle wird durch einen Platzhalter wie <PERSON> oder <IBAN_CODE> ersetzt. Welcher Platzhalter für welchen Wortlaut steht, hält eine Zuordnungstabelle fest.
3. Senden. Das Modell bekommt nur den Text mit Platzhaltern.
4. Zurücksetzen. In der Antwort stehen wieder Platzhalter. Das Programm setzt mit der Zuordnungstabelle die echten Angaben ein, bevor der Mitarbeiter die Antwort sieht.

Ein offenes Werkzeug für die ersten beiden Schritte ist Presidio. Ursprünglich stammt es von Microsoft. Seit 2026 führt es eine Gemeinschaft unter dem Namen Data Privacy Stack. Den Abschluss dieses Übergangs meldet das Projekt in seinem Quelltext (externe Seite, raw.githubusercontent.com) seit dem 04.10.2026.

Den ganzen Ablauf zeigt ein Beispiel des Projekts (externe Seite, presidio.dataprivacystack.org) für Anfragen an ein Modell von OpenAI. Aus einem Namen wird dort vor dem Versand ein Platzhalter, und in der Antwort an den Nutzer steht wieder der Name. Die Zuordnung hält das Beispiel je Sitzung fest. Dasselbe bietet das Gateway LiteLLM als Schalter an (Doku zur Maskierung (externe Seite, docs.litellm.ai)). Es sucht in der Antwort des Modells nach den Platzhaltern und setzt dafür die Werte ein, die der Nutzer geschickt hat.

Für das Beispiel heißt das: Der Mitarbeiter bekommt einen Entwurf, in dem der Name der Kundin steht. Das Modell hat diesen Namen nie gesehen.

Das Recht nennt das Pseudonymisierung

Die Datenschutz-Grundverordnung hat für diesen Vorgang einen Begriff. Nach Artikel 4 Nr. 5 der DSGVO (externe Seite, eur-lex.europa.eu) ist Pseudonymisierung eine Verarbeitung, nach der sich die Daten ohne zusätzliche Informationen keiner bestimmten Person mehr zuordnen lassen.

Die Definition hat eine zweite Hälfte. Die zusätzlichen Informationen müssen gesondert aufbewahrt und technisch und organisatorisch geschützt sein. Im Ablauf oben ist das die Zuordnungstabelle. Wer sie hat, kann jeden Platzhalter zurückführen. Für ihn bleiben die Daten deshalb personenbezogen.

Ob das auch für den Anbieter des Modells gilt, der die Tabelle nie sieht, ist umstritten. Arbeitet er im Auftrag, zählt nach den Leitlinien der Aufsicht die Sicht des Kunden. Den Stand der Debatte, mit dem Urteil des Gerichtshofs vom 04.09.2025, gibt Beurteilen und Einordnen, Kapitel 08 in Ebene 3 wieder. Ebene 3 hier ergänzt, was das Urteil über den Absender und den Empfänger sagt.

Die Erkennung findet viel und übersieht einiges

Für dieses Kapitel lief Presidio 2.2.364 am 21.10.2026 über den Beispieltext, in vier Einstellungen. Die Ergebnisse zeigt Ebene 2 im Einzelnen. Hier die Kurzfassung:

• In der Voreinstellung ersetzte Presidio sieben der neun direkten Angaben. Dazu kamen acht Stellen, die gar keine Angabe sind, etwa „Sehr“ und „mich“. Der Name des Mitarbeiters blieb stehen.
• Mit dem Rezept für Deutsch blieb der Text lesbar. Ersetzt waren sechs Angaben, mit allen deutschen Erkennern sieben. Straße und Vertragsnummer blieben stehen.
• Mit einem Schwellwert von 0,5, dem oberen Ende der Spanne, die das Rezept für den Betrieb nennt, fielen Postleitzahl und Rufnummer wieder heraus, es blieben fünf. Bei 0,4 blieben beide ersetzt.
• Die Kinderärztin im Ortsteil fand keine Einstellung.

Das ist eine Messung an einem einzigen erfundenen Text. Eine Erkennungsquote lässt sich daraus nicht ableiten. Eine solche Quote für Deutsch gibt es beim Projekt bisher ebenfalls nicht, laut dem Rezept für Deutsch (externe Seite, presidio.dataprivacystack.org) fehlt eine Messung an einem deutschen Datensatz.

Die Startseite der Doku (externe Seite, presidio.dataprivacystack.org) sagt es allgemein. Weil die Erkennung automatisch arbeitet, gibt es keine Garantie, dass Presidio alle sensiblen Angaben findet. Daneben empfiehlt sie weitere Schutzmaßnahmen.

Der Zusammenhang verrät die Person

Angenommen, alle neun direkten Angaben wären ersetzt. Dann steht im Text immer noch eine Kinderärztin, die einzige in ihrem Ortsteil. Ein Mensch mit Ortskenntnis erkennt sie. Ein Sprachmodell kann aus solchen Hinweisen ebenfalls auf Ort und Person schließen.

Wie weit das reicht, haben Robin Staab und Mitautoren von der ETH Zürich 2023 gemessen (Arbeit (externe Seite, arxiv.org), vorgestellt auf der ICLR 2024). Ihr Aufbau:

• GPT-4 las echte Profile von Reddit, also viele Kommentare je Person.
• Vorher hatte der Azure Language Service erkannte Angaben ab einer Schwelle von 0,4 entfernt.
• Bewertet wurden fünf Merkmale: Wohnort, Alter, Beruf, Geburtsort und Einkommen.

Beim Wohnort fiel die Trefferquote laut Abschnitt 6 der Arbeit von etwa 86 auf etwa 55 Prozent. Die Autoren folgern, dass das übliche Ersetzen derzeit wenig gegen solche Schlüsse ausrichtet.

Eine einzelne Beschwerde ist weniger Text als ein Profil mit vielen Kommentaren, und das Modell war der Stand von 2023. Die Zahl beschreibt also, was bei viel Text möglich ist. Für den Einzelfall zählt die Frage, ob ein Halbsatz wie der mit der Kinderärztin im Text steht.

Die deutschen Aufsichtsbehörden sehen das ebenso. Die Daten­schutz­kon­fe­renz schreibt in ihrer Ori­en­tie­rungs­hilfe (externe Seite, datenschutzkonferenz-online.de) zu KI und Datenschutz (Randnummer 49), dass es regelmäßig nicht genügt, Namen und Anschriften aus einer Eingabe zu entfernen. Der Personenbezug lasse sich gegebenenfalls aus dem Zusammenhang herstellen.

Ein Gateway bündelt die Schritte und sieht den Klartext

Die vier Schritte lassen sich in jede Anwendung einbauen. Oft übernimmt sie eine eigene Stelle zwischen Anwendung und Modell, ein Gateway. Die Anwendung schickt ihre Anfragen dorthin, und das Gateway reicht sie an das Modell weiter. LiteLLM etwa ist laut Doku (externe Seite, docs.litellm.ai) ein Server, den man selbst betreibt. Ein Gateway kann Angaben ersetzen, die Kosten auf Teams verteilen und Protokoll schreiben. Es sitzt an derselben Stelle im Ablauf wie die Prüfungen am Eingang, die Conversational AI, Kapitel 07 beschreibt.

Damit liegt am Gateway genau der Text, den das Ersetzen vom Modell fernhalten soll. Dazu kommt das Protokoll. Bei Cloudflare AI Gateway ist es je Gateway voreingestellt eingeschaltet, und jeder Eintrag kann Anfrage und Antwort im Wortlaut enthalten (Doku zur Protokollierung (externe Seite, developers.cloudflare.com)). Ob ein Protokoll vor oder nach dem Ersetzen geschrieben wird, entscheidet also darüber, ob es den Namen der Kundin enthält.

Vier Fragen an ein Angebot

Wer ein Gateway einkauft oder eine Anwendung mit eingebautem Ersetzen prüft, kann vier Fragen stellen.

1. Welche Angaben erkennt es, in welcher Sprache, und woran ist das gemessen? Eine Zahl von Filtern sagt nichts über die Trefferquote in deutschen Texten.
2. Wo liegt die Zuordnungstabelle, und wer kommt an sie heran? An ihr hängt, ob die Daten pseudonymisiert sind.
3. Wird die Antwort geprüft oder nur zurückübersetzt? Das Modell kann selbst Namen erzeugen, die nie ersetzt wurden.
4. Was steht im Protokoll? Vor dem Ersetzen geschrieben, enthält es alles, was das Ersetzen schützen sollte.

Ebene 1 hat den Ablauf gezeigt: erkennen, ersetzen, senden, zurücksetzen. Diese Ebene sieht sich jeden Schritt am Werkzeug an. Grundlage ist Presidio, das offene Werkzeug, das ursprünglich von Microsoft stammt und auch in Gateways wie LiteLLM eingebaut ist. Die erfundene Beschwerde aus Ebene 1 läuft dabei in vier Einstellungen durch. Am Ende stehen die Bauformen, mit denen Gateways auf einen Fund reagieren.

Zwei Arten von Erkennern

Presidio sucht auf zwei Wegen nach Angaben über Personen.

Muster. Manche Angaben haben eine feste Form. Eine IBAN beginnt mit einem Ländercode, hat eine feste Länge und eine Prüfziffer. Eine E-Mail-Adresse hat ein At-Zeichen und eine Domain. Solche Angaben findet eine Regel, und die Prüfziffer schließt viele Zufallstreffer aus.

Eigen­na­men­er­ken­nung. Namen von Personen, Orten und Organisationen haben keine feste Form. Sie erkennt ein trainiertes Sprachmodell aus dem Satz heraus, bei Presidio in der Voreinstellung eines aus der Bibliothek spaCy. Was ein solches Werkzeug ohne eigenes Training erkennt, steht in KI jenseits der Sprachmodelle, Kapitel 06, Ebene 3. Dialogsysteme nutzen denselben Baustein, um Merkmale aus einer Nachricht zu ziehen, beschrieben in Conversational AI, Kapitel 01.

Beides hat eine Lücke für Angaben, die kein Werkzeug kennen kann. Die Vertragsnummer im Beispiel hat ein Format, das nur der Versorger festgelegt hat. Für sie bräuchte es einen eigenen Erkenner.

Deutsch ist eine Einstellung

Presidio bringt in der Voreinstellung Erkenner und Modelle nur für Englisch mit (Doku zu den Sprachen (externe Seite, presidio.dataprivacystack.org)). Jede weitere Sprache wird eigens eingerichtet. Dasselbe gilt eine Ebene höher. Die Anbindung von Presidio in LiteLLM nimmt Englisch, wenn keine Sprache angegeben ist (Doku zur Maskierung (externe Seite, docs.litellm.ai)).

Für Deutsch hat das Projekt ein Rezept (externe Seite, presidio.dataprivacystack.org) vom 19.03.2026. Es richtet ein deutsches spaCy-Modell neben dem englischen ein und nennt deutsche Erkenner, etwa für Steuer-ID, Ren­ten­ver­si­che­rungs­nummer, Kran­ken­ver­si­cher­ten­nummer und Kfz-Kennzeichen. Im Paket selbst stehen diese 13 Erkenner bereit, sind in Version 2.2.364 aber abgeschaltet. Precision, Recall und F2 führt das Rezept als offen, eine Messung an einem deutschen Datensatz gibt es dort noch keine.

Was das bedeutet, zeigt eine Messung an der Beschwerde aus Ebene 1. Sie lief am 21.10.2026 mit Presidio 2.2.364 und spaCy 3.8.16, jeweils mit dem Operator in der Voreinstellung. Vier Einstellungen:

• A: Presidio ohne jede Einrichtung, Sprache Englisch.
• B: das Rezept für Deutsch, wie beschrieben.
• C: wie B, dazu die 13 deutschen Erkenner von Hand eingeschaltet.
• C5: wie C, mit dem Schwellwert 0,5. Das Rezept nennt für den Betrieb eine Spanne von 0,4 bis 0,5, und 0,5 für Erkenner ohne Prüfziffer, wenn kein Kontext dabeisteht.

Gezählt sind die neun direkten Angaben aus Ebene 1, von Hand. Das ist eine Einzelmessung an einem erfundenen Text. Eine Erkennungsquote ergibt sie nicht.

In der Voreinstellung behandelt Presidio den deutschen Text wie einen englischen. Das Ergebnis sieht zunächst gut aus, sieben von neun Angaben sind ersetzt. Gelesen wird der Text dabei allerdings unbrauchbar. Aus „Sehr“ wird ein Ort, aus „Ich wohne“ eine Person, und Kassel gilt ebenfalls als Person. Die Rufnummer ist ersetzt, allerdings als Datum. Die Vertragsnummer fällt nur zufällig mit, als Teil einer vermeintlichen Person samt dem Wort davor.

Mit dem Rezept für Deutsch verschwinden die Fehlalarme. Ersetzt sind sechs Angaben. Die Straße bleibt stehen, die Vertragsnummer auch. Unter den 13 deutschen Erkennern ist einer für die Postleitzahl. Für Straße und Hausnummer gibt es keinen. Mit allen 13 eingeschaltet kommt die Postleitzahl dazu, das sind sieben.

Der Schwellwert 0,5 kostet zwei Angaben. Rufnummer und Postleitzahl hatten in C jeweils einen Wert von 0,40. Mit dem Schwellwert gehen beide wieder unverändert an das Modell. Am unteren Ende der Spanne, bei 0,4, blieben sie ersetzt, und das Ergebnis gleicht C.

Die zehnte Angabe, die einzige Kinderärztin im Ortsteil, ersetzt keine der vier Einstellungen. Dafür gibt es keinen Erkenner. Ein Beruf wird erst mit dem Ortsteil zusammen zur Kennung.

Fehler in beide Richtungen

Jede Erkennung macht zwei Arten von Fehlern. Sie ersetzt Wörter, die keine Angabe sind, oder sie lässt Angaben stehen. Die FAQ (externe Seite, presidio.dataprivacystack.org) des Projekts nennt das eine Abwägung zwischen Fehlalarmen und übersehenen Angaben.

Die beiden Fehler haben Namen. Recall misst, welcher Anteil der Angaben gefunden wurde. Precision misst, welcher Anteil der Funde wirklich eine Angabe war. In der Messung erreicht Einstellung A denselben Recall wie C, bei acht Fehlalarmen. C5 hat keinen Fehlalarm und den niedrigsten Recall.

Welcher Fehler schwerer wiegt, beantwortet die Seite zur Bewertung (externe Seite, presidio.dataprivacystack.org): Beim Erkennen personenbezogener Daten zählt oft der Recall mehr. Eine übersehene Angabe geht an das Modell, ein Fehlalarm macht nur den Text schlechter. Dieselbe Seite hält fest, dass kein Verfahren zur Entfernung von Kennungen fehlerfrei ist.

Für eine Antwort auf eine Beschwerde wiegt der Fehlalarm allerdings mit. Ein Modell, das „<LOCATION> geehrte Damen und Herren“ liest, entwirft schlechtere Antworten. Der Schwellwert verschiebt zwischen beiden Fehlern, und welcher Wert passt, zeigt nur eine Messung an eigenen Texten.

Acht Operatoren, einer lässt sich umkehren

Was mit einer Fundstelle geschieht, bestimmt der Operator. Die Doku zum Anonymizer (externe Seite, presidio.dataprivacystack.org) führt acht eingebaute:

• Ersetzen durch den Namen des Typs, also <PERSON>. Das ist die Voreinstellung.
• Schwärzen, die Stelle verschwindet ganz.
• Hashen, aus dem Wert wird ein Hashwert. Ohne vorgegebenen Salt erzeugt Presidio ihn je Fundstelle neu, derselbe Name ergibt dann verschiedene Werte.
• Maskieren, einzelne Zeichen werden durch ein Zeichen wie * ersetzt.
• Verschlüsseln mit einem Schlüssel.
• dazu eine eigene Funktion, Ersatzwerte über einen Dienst von Azure und Beibehalten.

Unter den eingebauten Operatoren lässt sich nur das Verschlüsseln umkehren. Dafür gibt es einen eigenen Baustein, den Deanonymizer. Für Platzhalter muss jemand die Zuordnung deshalb selbst halten.

Das Werkzeug nennt umkehrbares Ersetzen durch Ersatzwerte Pseudonymisierung (FAQ (externe Seite, presidio.dataprivacystack.org)). Der Rechtsbegriff verlangt mehr, nämlich eine getrennt und geschützt aufbewahrte Zuordnung. Das ist Thema von Ebene 3.

Gleiche Platzhalter machen die Rückübersetzung mehrdeutig

In Einstellung B stehen nach dem Ersetzen zwei Personen im Text, beide als <PERSON>. Die eine ist die Kundin, die andere der Mitarbeiter. Aus „Ihrem Mitarbeiter Herrn Schulte“ wird „Ihrem Mitarbeiter <PERSON>“, die Anrede „Herrn“ geht im Platzhalter mit auf.

Schreibt das Modell nun „Sehr geehrte Frau <PERSON>“, ist offen, welcher Name dorthin gehört. Das Modell weiß auch nicht mehr, ob hinter einem Platzhalter ein Herr oder eine Frau steht, und rät beim Entwurf.

Abhilfe sind nummerierte Platzhalter wie <PERSON_1> und <PERSON_2>, die je Anfrage eindeutig sind. Die Zuordnung muss dann für die Dauer eines Gesprächs bestehen bleiben. Das Beispiel des Projekts (externe Seite, presidio.dataprivacystack.org) hält sie dafür je Sitzung fest, Redis gehört zu seinen Bauteilen. Dieselbe Seite verspricht, das Modell sehe so nie echte personenbezogene Daten. Der Hinweis auf der Startseite der Doku (externe Seite, presidio.dataprivacystack.org) schränkt das ein: Eine automatische Erkennung findet nicht garantiert alles.

Zurücksetzen und Prüfen sind zwei Schalter

Das Zurücksetzen tauscht nur Platzhalter gegen Werte. LiteLLM sagt das über seinen Schalter ausdrücklich (Doku zur Maskierung (externe Seite, docs.litellm.ai)). Er setzt nach dem Aufruf die Platzhalter zurück. Presidio prüft die Antwort dabei nicht.

Das Modell kann aber selbst Namen schreiben. Es kann einen Namen aus dem Kontext erraten, einen aus früheren Nachrichten derselben Sitzung übernehmen oder einen erfinden. Wer das abfangen will, braucht eine zweite Prüfung am Ausgang. Bei LiteLLM legt die Einstellung presidio_filter_scope fest, ob Presidio die Eingabe, die Antwort oder beides prüft. Voreingestellt ist beides. Das Zurücksetzen ist davon getrennt und muss eigens eingeschaltet werden.

Eine Prüfung am Ausgang hat beim Streamen ein Zeitproblem, das Conversational AI, Kapitel 07 beschreibt. Cloudflare löst es bei seiner Data Loss Prevention, wenn die Prüfung der Antwort eingeschaltet ist: Dann puffert es eine gestreamte Antwort ganz und prüft sie erst danach (Doku (externe Seite, developers.cloudflare.com)). Der Nutzer sieht den Text erst, wenn er vollständig ist.

Ersetzen, melden oder sperren

Ein Gateway kann mit einem Fund drei Dinge tun. Das entspricht den drei Verben, die Conversational AI, Kapitel 07 für jede Prüfung nennt: sperren, ändern, prüfen.

• Ersetzen. LiteLLM maskiert je Typ und gibt die Anfrage weiter.
• Melden. Cloudflare hält einen Fund für die spätere Prüfung fest und lässt die Anfrage durch (Einrichtung (externe Seite, developers.cloudflare.com)).
• Sperren. Cloudflare kann Anfrage oder Antwort anhalten, LiteLLM eine Anfrage je Typ abweisen.

Ein Ersetzen bietet Cloudflare bei dieser Funktion nicht an. Die Übersicht zu den AI-Gateway-Funktionen (externe Seite, learn.microsoft.com) von Azure API Management nennt Token-Grenzen, Zwischenspeicher, eine Inhaltsprüfung und das Protokollieren von Anfragen und Antworten. Ein Ersetzen personenbezogener Daten führt sie nicht auf.

Wer sperrt, schützt am stärksten. Die Beschwerde der Kundin käme dann gar nicht beim Modell an, und der Mitarbeiter schriebe die Antwort selbst. Wer meldet, weiß hinterher, was hinausging. Wer ersetzt, bekommt einen Entwurf und nimmt das Risiko der übersehenen Angaben in Kauf.

Das Protokoll ist ein eigener Fall

LiteLLM führt das Maskieren für das Protokoll als eigenen Zeitpunkt. In diesem Modus wird nur vor dem Schreiben des Protokolls maskiert, die Anfrage an das Modell bleibt unverändert (Doku zur Maskierung (externe Seite, docs.litellm.ai)). Ein Gateway hat also mindestens zwei Ausgänge für denselben Text, das Modell und das Protokoll. Beide brauchen eine eigene Entscheidung. Zu den Aufgaben eines Gateways zählt die Doku von LiteLLM (externe Seite, docs.litellm.ai) Filter und Maskierung für Anfragen und Antworten.

Fragen für die Prüfung eines Angebots

1. Für welche Sprache ist die Erkennung eingerichtet? Steht dort Englisch als Voreinstellung, behandelt sie deutsche Texte wie englische.
2. Welche eigenen Kennungen kennt sie? Kundennummern und Vertragsnummern brauchen eigene Erkenner.
3. Welcher Schwellwert gilt, und woran wurde er gewählt? Er entscheidet, ob eine Rufnummer hinausgeht.
4. Sind die Platzhalter nummeriert, und wie lange lebt die Zuordnung?
5. Wird die Antwort auf neue Namen geprüft? Das Zurücksetzen allein tut es nicht.
6. Was geschieht mit dem Protokoll? Maskieren für das Modell und Maskieren für das Protokoll sind zwei Einstellungen.

Vorweg: Diese Ebene ordnet die Rechtslage allgemein ein. Wer eine verbindliche Auskunft für den eigenen Fall braucht, holt sie sich bei jemandem, der dafür haftet.

Die beiden ersten Ebenen zeigen, wie Angaben vor dem Versand ersetzt werden und wo das versagt. Diese Ebene fragt, was das Ersetzen rechtlich ändert. Wann eine Eingabe überhaupt personenbezogen ist und wie der Gerichtshof und der Daten­schutz­aus­schuss die Sicht des Empfängers bewerten, steht in Beurteilen und Einordnen, Kapitel 08, Ebene 3. Hier stehen die Teile, die dort fehlen:

• die zweite Hälfte der Definition und ihr Zweck in der Verordnung;
• was das Urteil EDSB/SRB über Absender und Empfänger sagt;
• die Kriterien für Anonymität;
• was die KI-Verordnung dazu enthält;
• die Rolle des Gateways.

Die Definition hat eine zweite Hälfte

Artikel 4 Nr. 5 der DSGVO (externe Seite, eur-lex.europa.eu) beschreibt die Pseudonymisierung in zwei Teilen. Der erste sagt, was mit den Daten geschieht: Sie lassen sich ohne zusätzliche Informationen keiner Person mehr zuordnen. Der zweite sagt, was mit diesen zusätzlichen Informationen geschieht. Sie werden gesondert aufbewahrt und durch technische und organisatorische Maßnahmen geschützt, damit niemand die Daten einer Person zuweist.

Bei einer Anfrage an ein Sprachmodell ist die zusätzliche Information die Zuordnungstabelle zwischen Platzhalter und Wortlaut. Die zweite Hälfte der Definition verlangt also, dass diese Tabelle getrennt vom ersetzten Text liegt und geschützt ist. Ein Protokoll, das Anfrage und Zuordnung nebeneinander speichert, erfüllt das nicht.

Das Werkzeug Presidio fasst das Wort weiter. Seine FAQ (externe Seite, presidio.dataprivacystack.org) nennt jedes umkehrbare Ersetzen durch Ersatzwerte Pseudonymisierung, ohne Bedingung an die Aufbewahrung. Wer ein Angebot liest, das „Pseudonymisierung“ verspricht, fragt deshalb nach dem Ort der Tabelle.

Die Verordnung nennt Pseudonymisierung als eine Maßnahme unter mehreren

Die DSGVO kommt an mehreren Stellen auf die Pseudonymisierung zurück, jedes Mal als Mittel zu einem Zweck.

• Datenminimierung. Nach Artikel 5 Abs. 1 lit. c müssen Daten dem Zweck angemessen und auf das notwendige Maß beschränkt sein. Artikel 25 Abs. 1 nennt die Pseudonymisierung als Beispiel einer Maßnahme, mit der der Verantwortliche diesen Grundsatz schon bei der Gestaltung umsetzt.
• Sicherheit. Artikel 32 Abs. 1 lit. a führt die Pseudonymisierung und Verschlüsselung unter den Maßnahmen auf, die der Verantwortliche gegebenenfalls ergreift.
• Risiko. Nach Erwägungsgrund 28 im Amtsblatt (externe Seite, eur-lex.europa.eu) kann die Pseudonymisierung die Risiken für die Betroffenen senken und Verantwortlichen wie Auf­trags­ver­ar­bei­tern bei ihren Pflichten helfen. Der Satz danach stellt klar, dass die Verordnung andere Schutzmaßnahmen damit nicht ausschließen will.

Alle drei Stellen beschreiben eine Maßnahme, die der Verantwortliche nach dem Risiko wählt. Eine Pflicht, jede einzelne Anfrage vor dem Versand zu pseudonymisieren, formuliert keine von ihnen.

Beim Absender bleiben die Daten personenbezogen

Das Urteil EDSB/SRB (externe Seite, eur-lex.europa.eu) vom 04.09.2025 ist bekannt für seine Aussage über den Empfänger. Zum Absender sagt es zwei Dinge, die seltener zitiert werden.

Erstens: Für den Absender, der die Zuordnung hat, bleiben die Daten personenbezogen. Das Ersetzen senkt das Risiko, an der Einordnung ändert es nichts. Im Fall waren die Stellungnahmen für die Behörde, die sie pseudonymisiert weitergab, nach Randnummer 76 trotz der Pseudonymisierung personenbezogen.

Zweitens geht es um die Pflicht, Betroffene über die Empfänger ihrer Daten zu informieren. Sie beurteilt der Gerichtshof nach Randnummer 111 aus der Sicht des Verantwortlichen und zum Zeitpunkt der Erhebung. Wer pseudonymisierte Anfragen an einen Modellanbieter schickt, müsste diesen Anbieter danach als Empfänger nennen, auch wenn der die Personen nicht kennt.

Dabei ist eine Einschränkung wichtig. Das Urteil ergeht zur Verordnung 2018/1725 für die Organe der Union. Dass Artikel 13 der DSGVO ebenso zu lesen ist, bleibt eine Lesart. Sie liegt nahe, weil die Begriffe beider Verordnungen einander nachgebildet sind.

Beim Empfänger zählen zwei Bedingungen

Für einen Empfänger ohne Zuordnung können pseudonymisierte Daten anonym sein. Randnummer 77 desselben Urteils nennt dafür zwei Bedingungen. Der Empfänger darf erstens nicht in der Lage sein, die Maßnahmen unter seiner Kontrolle aufzuheben. Zweitens darf er die Person auch mit anderen Mitteln nicht identifizieren können, etwa durch einen Abgleich mit anderen Elementen.

Die erste Bedingung erfüllt ein Modellanbieter, solange die Zuordnungstabelle beim Absender oder am Gateway bleibt. Die zweite ist bei Sprachmodellen die offene Stelle. Erwägungsgrund 26 im Amtsblatt (externe Seite, eur-lex.europa.eu) verlangt, bei den Mitteln zur Identifizierung die verfügbare Technologie und ihre Entwicklung zu berücksichtigen.

Die folgende Verbindung ist eine eigene Ableitung aus beiden Stellen. Ein Sprachmodell, das aus einem Text auf Wohnort und Beruf schließt, gehört zu der Technologie, die verfügbar ist. Ein Anbieter, der den ersetzten Text mit einem solchen Modell verarbeitet, hat damit ein Mittel des Abgleichs in der Hand.

Wie gut es wirkt, zeigt die Arbeit von Staab und Mitautoren (externe Seite, arxiv.org). Ihre Bedingungen stehen in Ebene 1: Profile von Reddit, Ersetzung mit Azure Language Service bei einer Schwelle von 0,4, GPT-4 im Stand von 2023, fünf Merkmale. Den Wohnort traf das Modell laut Abschnitt 6 nach der Ersetzung noch in etwa 55 Prozent der Fälle. Eine einzelne Anfrage enthält meist weniger Text als ein solches Profil. Ob die zweite Bedingung erfüllt ist, hängt also am Inhalt der einzelnen Anfrage.

Beim Auftragsverarbeiter zählt die Sicht des Kunden

Der häufigste Weg zu einem Modell ist ein Anbieter, der im Auftrag verarbeitet. Für ihn zählt nach Randnummer 15 der Leitlinien 02/2026 die Sicht des Kunden, wie Beurteilen und Einordnen, Kapitel 08 ausführt. Kann der Kunde zurückführen, sind die Daten auch beim Anbieter personenbezogen.

Die Leitlinien 01/2025 zur Pseudonymisierung (externe Seite, edpb.europa.eu) ergänzen zwei Punkte. Sie liegen am 21.10.2026 weiter nur als Fassung zur Konsultation vom 16.01.2025 vor, eine Endfassung führt der Ausschuss nicht.

• Schutzniveau. Nach Randnummer 43 kann eine Pseudonymisierung vor der Übermittlung an einen Auf­trags­ver­ar­beiter das Schutzniveau senken, das dort nötig ist. Nach Randnummer 44 wirkt sie oft am besten zusammen mit weiteren Maßnahmen.
• Drittland. Nach Randnummer 63 und 64 kann die Pseudonymisierung eine ergänzende Maßnahme für eine Übermittlung in ein Drittland sein. Das gilt für Übermittlungen ohne Ange­mes­sen­heits­be­schluss, etwa auf Stan­dard­ver­trags­klau­seln. Bedingung ist unter anderem, dass die Zuordnung allein beim Exporteur in einem Mitgliedstaat oder bei einer ver­trau­ens­wür­digen Stelle getrennt liegt.

Für ein Gateway in Europa vor einem Modell in den USA heißt das: Die Zuordnungstabelle gehört auf die europäische Seite. Wie die Übermittlung in die USA sonst geregelt ist, steht in Beurteilen und Einordnen, Kapitel 08, Ebene 3.

Drei Kriterien, und das dritte ist die Inferenz

Wann Daten anonym sind, hat die Daten­schutz­auf­sicht zweimal beschrieben. Die Artikel-29-Datenschutzgruppe stellte 2014, noch zur Richtlinie 95/46/EG, in ihrer Stellungnahme 5/2014 (externe Seite, ec.europa.eu) drei Prüffragen. Die dritte lautet, ob sich Informationen über eine Person durch Inferenz herleiten lassen. Dieselbe Stellungnahme ordnet die Pseudonymisierung als Sicher­heits­maß­nahme ein, die die Verknüpfbarkeit mit der Identität verringert.

Die Leitlinien 02/2026 (externe Seite, edpb.europa.eu) des Europäischen Daten­schutz­aus­schusses aktualisieren diese Stellungnahme (Randnummer 2). Sie stehen bis zum 30.10.2026 zur Konsultation. Randnummer 3 nennt drei Kriterien: kein Herauslösen einzelner Datensätze, keine Verknüpfung, keine Inferenz. Randnummer 82 bezieht die Inferenz ausdrücklich auf KI-Modelle. Ein Weg zu neuen Informationen über eine Person ist danach, ein Modell mit zusätzlichem Wissen abzufragen.

Auf das Beispiel aus Ebene 1 angewandt, und das ist eine eigene Anwendung der Kriterien: Solange die einzige Kinderärztin im Ortsteil darin steht, lässt sich die Kundin durch Verknüpfung mit einem Branchenbuch finden, und ein Modell kann auf sie schließen. Anonym ist die Beschwerde damit auch dann nicht, wenn alle neun direkten Angaben ersetzt sind. Die Daten­schutz­kon­fe­renz sagt dasselbe aus deutscher Sicht, Ebene 1 gibt ihre Randnummer 49 wieder. Ob der Digital-Omnibus an Artikel 4 etwas ändert, ist offen; das Verfahren (externe Seite, oeil.secure.europarl.europa.eu) liegt beim Ausschuss des Parlaments.

In der KI-Verordnung steht die Pseudonymisierung an einer Stelle

Die KI-Verordnung ordnet sich dem Datenschutzrecht nach. Laut Artikel 2 Abs. 7 der konsolidierten Fassung (externe Seite, eur-lex.europa.eu) berührt sie die DSGVO nicht. Ausgenommen davon sind ausdrücklich die Artikel 4a und 59. Was das für beide Prüfungen bedeutet, steht in KI jenseits der Sprachmodelle, Kapitel 12.

Eine Suche in den Artikeln der geltenden Fassung vom 27.07.2026 findet die Pseudonymisierung einmal. Die Erwägungsgründe stehen nur in den Amtsblättern und sind darin nicht enthalten. Artikel 4a, eingefügt mit der Änderung von 2026, erlaubt Anbietern von Hochrisiko-Systemen, besondere Kategorien von Daten zu verarbeiten, um Verzerrungen zu korrigieren. Absatz 2 öffnet das unter denselben Vorkehrungen auch für Anbieter und Betreiber anderer KI-Systeme und KI-Modelle. Als Vorkehrung nennt er die modernsten Sicherheits- und Daten­schutz­maß­nahmen, darunter die Pseudonymisierung. Anonymisierte Daten kommen daneben in Artikel 4a und in Artikel 59 zu den Reallaboren vor.

Eine Pflicht zum Protokoll gibt es nur bei Hochrisiko-Systemen. Nach Artikel 19 bewahren die Anbieter solcher Systeme die automatisch erzeugten Protokolle auf, nach Artikel 26 Abs. 6 die Betreiber, jeweils soweit diese ihrer Kontrolle unterliegen. Wer einen Entwurf für eine Antwort auf eine Beschwerde schreiben lässt, betreibt in aller Regel kein Hochrisiko-System. Ein Gateway, das jede Anfrage im Wortlaut protokolliert, braucht dann einen eigenen Zweck. Die KI-Verordnung liefert ihn nicht.

Wer das Gateway betreibt, sieht den Klartext

Ein Gateway erhält jede Anfrage, bevor es sie ersetzt. Es hält die Zuordnungstabelle und oft ein Protokoll. Betreibt das Unternehmen das Gateway selbst, bleibt der Klartext im eigenen Haus. Läuft es als Dienst eines Dritten, kommt ein Empfänger hinzu, der mehr sieht als der Modellanbieter.

Zu dieser Bauform hat sich, soweit ersichtlich, keine Aufsichtsbehörde geäußert. Was folgt, ist deshalb eine eigene Ableitung aus Artikel 4 Nr. 8 und Artikel 28 der DSGVO (externe Seite, eur-lex.europa.eu). Auf­trags­ver­ar­beiter ist danach, wer für einen Verantwortlichen und nach dessen Weisung mit personenbezogenen Daten arbeitet. Grundlage ist ein Vertrag.

Drei Behördentexte stützen die Ableitung, ohne ein Gateway zu nennen.

• Die Daten­schutz­kon­fe­renz sieht beim externen Anbieter einer KI-Anwendung häufig eine Auf­trags­ver­ar­bei­tung, wenn eine Stelle sie für eigene Zwecke einsetzt (Ori­en­tie­rungs­hilfe (externe Seite, datenschutzkonferenz-online.de), Randnummer 32).
• Nach den Leitlinien 01/2025 (externe Seite, edpb.europa.eu) kann ein Dienstleister, der für Verantwortliche pseudonymisiert, Auf­trags­ver­ar­beiter sein. Entscheidet er selbst darüber, ob er pseudonymisiert oder die Pseudonymisierung aufhebt, kann er auch Verantwortlicher sein (Randnummer 126).
• Die Leitlinien 07/2020 (externe Seite, edpb.europa.eu) trennen den reinen Übermittler vom Dienstleister mit Zugriff. Wer nur die Übertragung von Nachrichten ermöglicht, ist für deren Inhalt in der Regel kein Verantwortlicher (Beispiel nach Randnummer 27). Ein IT-Dienstleister, der zwangsläufig auf personenbezogene Daten zugreift, ist Auf­trags­ver­ar­beiter (Beispiel nach Randnummer 83).

Naheliegend ist danach: Ein Gateway, das Anfragen liest, ersetzt und protokolliert, tut mehr als übertragen. Sein Betreiber ist dann Auf­trags­ver­ar­beiter, mit Vertrag nach Artikel 28 und eigener Liste von Unter­auf­trags­ver­ar­bei­tern. Entscheidet er selbst, wann er die Zuordnung anwendet oder wofür er die Protokolle nutzt, wird er Verantwortlicher.

Anthropic als Hersteller von Claude prüft solche Gateways nicht. Es schreibt in seiner Anleitung für Claude Code (externe Seite, code.claude.com), dass es Gateway-Produkte Dritter weder empfiehlt noch pflegt noch prüft. Dieselbe Seite zählt ein Protokoll jeder Anfrage zu den Aufgaben eines Gateways. Die Prüfung des Gateways liegt damit beim Unternehmen, das es einsetzt.

Prüffragen für die rechtliche Seite

1. Wo liegt die Zuordnungstabelle, getrennt vom Text und geschützt? Davon hängt ab, ob die zweite Hälfte von Artikel 4 Nr. 5 erfüllt ist.
2. Nennt die Information an die Betroffenen den Modellanbieter als Empfänger? Aus Sicht des Absenders bleiben die Daten personenbezogen.
3. Was steht nach dem Ersetzen noch im Text? Beruf, Ort und Umstände entscheiden über das Kriterium der Inferenz.
4. Liegt die Zuordnung bei einer Übermittlung in ein Drittland ohne Ange­mes­sen­heits­be­schluss allein in Europa?
5. Welche Rolle hat der Betreiber des Gateways, und gibt es einen Vertrag nach Artikel 28?
6. Wozu wird protokolliert? Die KI-Verordnung verlangt ein Protokoll nur bei Hochrisiko-Systemen.