Robin, Consultant für GenAI bei Pexon Consulting | 11 Min. Lesezeit | 22.09.2026
TL;DR: Presidio am Gateway in fünf Sätzen
Presidio ist Microsofts offene Bibliothek zum Erkennen und Ersetzen von Personendaten. Am Gateway läuft sie vor dem Modellaufruf und ersetzt Namen, Adressen oder Kartennummern durch Platzhalter. LiteLLM bringt sie als Guardrail mit, je Datenart maskieren oder blocken. Die Antwort kann die echten Werte zurückbekommen. Die Erkennung ist gut, aber nicht perfekt.
| Ohne Schutzschicht | Mit Presidio am Gateway | |
|---|---|---|
| Wer entscheidet, was ins Modell geht | jeder Nutzer im Chatfenster | eine Regel je Datenart |
| Personendaten in der Anfrage | gehen mit | werden ersetzt oder die Anfrage wird abgelehnt |
| Nachweis für den Datenschutz | Screenshots und Zusagen | Protokoll je Aufruf |
| Modellwechsel | Regeln neu bauen | Regeln bleiben, das Modell ist austauschbar |
Das Problem: Die Regel steht im Intranet, nicht im Werkzeug
Fast jedes Unternehmen hat eine KI-Richtlinie. Darin steht, dass keine Personaldaten, keine Mandantendaten und keine Vertragsinhalte in ein Modell gehören. Diese Richtlinie steht im Intranet, und sie hat einen Konstruktionsfehler: Sie wird von Menschen durchgesetzt, die gerade unter Zeitdruck stehen.
Der Vorgang ist immer derselbe. Eine Sachbearbeiterin hat eine Kündigung zu prüfen, kopiert den Vorgang in den Chat und will eine Einschätzung. Sie handelt nicht böswillig, sie will ihre Arbeit erledigen. Die Richtlinie war in diesem Moment ein Dokument, das sie vor zehn Monaten unterschrieben hat.
Wer das Problem technisch löst, verschiebt es an genau eine Stelle, an der alle Anfragen vorbeikommen: das Gateway. Wie diese Schicht insgesamt aufgebaut ist, beschreibt unser Beitrag zum LLM-Gateway.
Was Presidio ist
Presidio ist eine offene Bibliothek von Microsoft für zwei Aufgaben: Personendaten in Text finden und sie ersetzen. Das sind zwei getrennte Dienste, und das ist im Betrieb wichtig:
| Dienst | Aufgabe | Typischer Port |
|---|---|---|
| Analyzer | findet Stellen und benennt die Art, etwa PERSON oder IBAN_CODE |
5002 |
| Anonymizer | ersetzt die gefundenen Stellen nach Ihrer Regel | 5001 |
Beide laufen als eigene Container in Ihrem Netz. Nichts davon ruft einen externen Dienst auf. Die Erkennung arbeitet mit Mustern, Prüfsummen und einem Sprachmodell für Namen und Orte, nicht mit einem Cloud-Dienst.
Schritt 1: Die beiden Dienste starten
Für einen ersten Aufbau genügt ein Compose-Verbund mit den beiden offiziellen Abbildern. Wichtig ist nur, dass das Gateway beide erreicht und sonst niemand. Diese Dienste sehen naturgemäß jeden Text im Klartext, sie gehören also in dasselbe geschützte Netz wie das Gateway und nicht in die Nähe des Internets.
Schritt 2: Das Gateway anweisen
LiteLLM kennt Presidio als Guardrail. Die Konfiguration liegt in der config.yaml des Proxys:
guardrails:
- guardrail_name: "presidio-pii"
litellm_params:
guardrail: presidio
mode: "pre_call"
pii_entities_config:
PERSON: "MASK"
EMAIL_ADDRESS: "MASK"
IBAN_CODE: "BLOCK"
CREDIT_CARD: "BLOCK"
output_parse_pii: true
default_on: true
Drei Stellschrauben entscheiden über das Verhalten:
modelegt fest, wann geprüft wird.pre_callläuft vor dem Modellaufruf,post_callprüft die Antwort,logging_onlyschreibt nur mit, ohne etwas zu verändern. Für den Start istlogging_onlydie ehrlichste Wahl, dazu unten mehr.pii_entities_configbestimmt je Datenart die Reaktion.MASKersetzt den Fund durch einen Platzhalter wie,BLOCKlehnt die ganze Anfrage ab.output_parse_piisorgt dafür, dass in der Antwort aus dem Platzhalter wieder der ursprüngliche Wert wird. Das Modell rechnet mit, die Nutzerin liest den Namen.
Damit ist die entscheidende Eigenschaft beschrieben: Die Regel hängt am Gateway, nicht am Modell. Wechseln Sie von Claude über Bedrock zu einem lokalen Modell, bleibt die Schutzschicht unverändert.
Schritt 3: Maskieren oder blocken, je Datenart
Die Frage, die in Projekten am längsten dauert, ist nicht technisch. Sie lautet: Was soll passieren, wenn eine IBAN auftaucht?
| Datenart | Empfehlung | Begründung |
|---|---|---|
| Name, E-Mail, Telefonnummer | maskieren | die Aufgabe bleibt lösbar, das Modell braucht den Namen nicht |
| Anschrift, Geburtsdatum | maskieren | gleiches Muster, nur sensibler |
| IBAN, Kreditkarte, Ausweisnummer | blocken | wenn so etwas im Chat landet, ist der Vorgang selbst falsch |
| Gesundheitsangaben, Sozialdaten | blocken, mit klarer Meldung an die Nutzerin | hier hilft keine Maskierung, sondern ein anderer Prozess |
Blocken ist die unbequemere Wahl, weil es Arbeit unterbricht. Genau das ist der Zweck. Eine Meldung mit dem Satz „Diese Anfrage enthält eine Kontonummer, bitte nutzen Sie dafür das Fachverfahren“ erzieht wirksamer als jede Richtlinie.
Schritt 4: Erst messen, dann scharf schalten
Der Fehler, den wir am häufigsten sehen: Die Schutzschicht wird an einem Freitag scharf geschaltet, am Montag stehen falsch erkannte Fälle im Weg, und drei Wochen später ist sie wieder aus.
Der bessere Weg ist zweistufig:
- Zwei Wochen mitschreiben. Mit
logging_onlyläuft alles wie bisher, aber Sie sehen, was die Erkennung findet. Danach wissen Sie, welche Datenarten überhaupt vorkommen, und wie oft. - Dann scharf schalten, zuerst für die eindeutigen Arten wie Kartennummer und IBAN, danach für Namen.
Für die Auswertung reichen zwei Zahlen: Wie viele Anfragen wurden verändert, und wie viele Nutzer haben sich beschwert. Das zweite ist die Fehlalarmquote in ihrer ehrlichsten Form.
Was Presidio nicht kann
Eine Schutzschicht, die als perfekt verkauft wird, fliegt beim ersten Prüftermin auf. Drei Grenzen gehören ins Konzept:
- Die Erkennung ist statistisch. Ein Name in einer ungewöhnlichen Schreibweise, ein Aktenzeichen ohne festes Muster oder eine Adresse mitten im Fließtext werden nicht immer gefunden. Presidio liefert je Fund einen Vertrauenswert, und Sie legen die Schwelle fest. Niedrig heißt mehr Fehlalarme, hoch heißt mehr Durchrutscher.
- Zusammenhang schützt nicht. „Der Werksleiter unseres Standorts in Aichach“ enthält keinen Namen und ist trotzdem eine Person. Maskierung löst das nicht.
- Eigene Kennungen muss man beibringen. Personalnummern, Vertragsnummern, Aktenzeichen: Dafür schreiben Sie eigene Erkennungen, meist als Muster. Das ist die Arbeit, die in keinem Schnellstart steht.
Deshalb ist Maskierung eine von mehreren Schichten. Für Inhalte, die gar nicht erst ins Modell dürfen, braucht es eine Klassifizierung der Daten vor der Frage, und für schädliche Eingaben eine zweite Prüfung. Welche Prüfungen sich wie ergänzen, ordnet unser Beitrag zur Guardrails-Checkliste ein.
Was das für die Aufsicht bedeutet
Zwei Punkte, die in Prüfgesprächen regelmäßig kommen:
Verarbeitung findet trotzdem statt. Maskierung macht aus einer Verarbeitung personenbezogener Daten keine Verarbeitung ohne Personenbezug. Der Text lag vor der Maskierung im Gateway, und mit output_parse_pii liegen die Zuordnungen für die Dauer der Anfrage vor. Das gehört ins Verarbeitungsverzeichnis, nicht in die Fußnote.
Das Protokoll ist selbst heikel. Ein Protokoll, das festhält, welche Personendaten gefunden wurden, ist eine zweite Datensammlung. Halten Sie fest, dass etwas gefunden wurde, welche Art es war und in welchem Umfang. Nicht den Wert.
Häufig gestellte Fragen
Was ist Microsoft Presidio?
Presidio ist eine offene Bibliothek von Microsoft, die Personendaten in Texten erkennt und ersetzt. Sie besteht aus einem Analyzer, der Fundstellen samt Art meldet, und einem Anonymizer, der sie nach Regeln maskiert. Beide laufen als eigene Dienste im eigenen Netz.
Wie binde ich Presidio an LiteLLM an?
Über den Guardrail-Abschnitt der Proxy-Konfiguration mit guardrail: presidio, einem Modus wie pre_call und einer Regel je Datenart. Die beiden Presidio-Dienste werden über ihre Adressen bekannt gemacht. Mit output_parse_pii bekommt die Antwort die echten Werte zurück.
Maskieren oder blocken, was ist richtig?
Maskieren, wenn die Aufgabe ohne die Daten lösbar bleibt, etwa bei Namen und Kontaktdaten. Blocken, wenn das Auftauchen selbst schon ein Fehler im Prozess ist, etwa bei Kontonummern, Ausweisdaten oder Gesundheitsangaben.
Wie zuverlässig erkennt Presidio Personendaten?
Gut, aber nicht vollständig. Die Erkennung arbeitet mit Mustern und einem Sprachmodell und liefert je Fund einen Vertrauenswert. Eigene Kennungen wie Personal- oder Aktenzeichen müssen Sie als eigene Erkennung ergänzen. Planen Sie eine Messphase ein, bevor Sie scharf schalten.
Reicht Maskierung für die DSGVO?
Nein, sie ist eine technische Maßnahme unter mehreren. Die Verarbeitung findet weiterhin statt, sie wird nur risikoärmer. Rechtsgrundlage, Verzeichnis, Löschkonzept und die Auswahl des Modellanbieters bleiben davon unberührt.
Nächster Schritt
Wenn Ihre Richtlinie technisch durchgesetzt werden soll statt nur zu existieren, ist das Gateway der Ort dafür. Wir bauen die Schutzschicht, legen die Regeln je Team fest und messen, wie oft sie greift.
Verwandte Themen
→Gateway-Guardrails für die offene KI-Plattform
→LLM-Gateway: was es ist und wann Unternehmen eins brauchen
→LLM-Guardrails-Checkliste
→Welche Daten dürfen zu Copilot
Quellen: Microsoft-Presidio-Dokumentation (Analyzer, Anonymizer), LiteLLM-Dokumentation zu Guardrails und zur Presidio-Maskierung (Konfiguration, Modi, output_parse_pii). Stand 22.09.2026.



