Presidio am Gateway: Personendaten maskieren, bevor das Modell sie sieht

Presidio am LLM-Gateway: Personendaten erkennen, maskieren oder blocken, bevor die Anfrage zum Modell geht. Mit Konfiguration, Messphase und den Grenzen der Erkennung.

22 Sep.. 2026 | AI

Inhaltsverzeichnis

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:

  • mode legt fest, wann geprüft wird. pre_call läuft vor dem Modellaufruf, post_call prüft die Antwort, logging_only schreibt nur mit, ohne etwas zu verändern. Für den Start ist logging_only die ehrlichste Wahl, dazu unten mehr.
  • pii_entities_config bestimmt je Datenart die Reaktion. MASK ersetzt den Fund durch einen Platzhalter wie , BLOCK lehnt die ganze Anfrage ab.
  • output_parse_pii sorgt 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:

  1. Zwei Wochen mitschreiben. Mit logging_only läuft alles wie bisher, aber Sie sehen, was die Erkennung findet. Danach wissen Sie, welche Datenarten überhaupt vorkommen, und wie oft.
  2. 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.

Das läuft jetzt im POC. Was für den Produktivbetrieb fehlt: Regeln je Team statt einer Regel für alle, eine Liste eigener Erkennungen für Aktenzeichen, Kunden- und Personalnummern, ein Protokoll, das dem Datenschutz genügt, ohne die gefundenen Werte selbst zu speichern, eine Meldung an die Nutzerin, die erklärt statt nur abzulehnen, und eine Messung der Fehlalarme. Das richten wir bei den Gateway-Guardrails mit ein.

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.

Guardrails am Gateway
Maskieren ist schnell eingebaut. Die Regeln sind die Arbeit.
Wir setzen die Schutzschicht vor Ihre Modelle: Presidio für Personendaten, Regeln je Team und Datenklasse, Protokoll für den Datenschutz und Messung der Fehlerrate.

Verwandte Themen

Quellen: Microsoft-Presidio-Dokumentation (Analyzer, Anonymizer), LiteLLM-Dokumentation zu Guardrails und zur Presidio-Maskierung (Konfiguration, Modi, output_parse_pii). Stand 22.09.2026.


Microsoft Fabric. Bilder Blogtemplate Whitepaper

Claude Code im Unternehmen

  • Praxis-Guide für IT-Leiter – mit konkreten Einblicken zu Kosten, Sicherheit und Rollout von Claude Code im Unternehmen.

Beratungsgespräch

Sichern Sie sich Ihre kostenfreie Erstberatung

Analyse Ihres individuellen Cloud- oder KI-Bedarfs
Erste Empfehlungen zu Umsetzungsstrategien
Transparente Einblicke in unsere Methoden, Technologien & Referenzen