Personenbezogene Daten vor LLM-Prompts schützen: Presidio, Privacy Filter und die Produktionspipeline

Der sicherste Prompt fordert ein LLM nicht dazu auf, personenbezogene Daten zu ignorieren. Er enthält Daten, die das Modell nicht braucht, gar nicht erst. Setze ein deterministisches Privacy-Gateway vor den Modellaufruf, entferne unnötige Felder, ersetze notwendige Identifikatoren durch stabile Platzhalter und behalte die Rückauflösung unter eigener Kontrolle.

Dieser Leitfaden schließt die praktische Lücke zwischen einem Presidio-Demo mit fünf Zeilen und einer allgemeinen DSGVO-Policy. Er zeigt den vollständigen Pfad für Support-Tickets, Dokumente, RAG, Agenten und interne Assistenten. Außerdem vergleicht er das ursprünglich von Microsoft entwickelte Presidio mit OpenAI Privacy Filter und Managed-DLP-Diensten. Die Tool-Angaben wurden am 6. August 2026 geprüft.

Wie sollte eine PII-Redaction-Pipeline vor LLM-Prompts aussehen?

Nutze sieben Grenzen: minimieren, erkennen, klassifizieren, transformieren, aufrufen, prüfen und selektiv zurückauflösen. Die Erkennung läuft in deiner vertrauenswürdigen Umgebung, bevor Prompt, Anhang, gefundene Passage oder Tool-Ergebnis die Grenze zum Modellanbieter überschreitet.

1. An der Quelle minimieren. Wähle nur Felder, die die Aufgabe braucht. Serialisiere keinen vollständigen Kundendatensatz, um ihn später wieder zu schwärzen.
2. Mehrschichtig erkennen. Kombiniere schemaabhängige Feldregeln, Prüfsummen und Secret-Patterns mit einem kontextsensitiven PII-Detector. Eine Methode deckt nicht gleichzeitig IBANs und Namen im Fließtext zuverlässig ab.
3. Policy je Entität und Zweck anwenden. Blockiere verbotene Inhalte, entferne unnötige Inhalte und pseudonymisiere Werte, die die Aufgabe weiter benötigt.
4. Eindeutige typisierte Platzhalter erzeugen. Ersetze Werte durch Tokens wie PERSON_001, EMAIL_001 und CASE_ID_001. Wiederholte Verweise bleiben im erlaubten Scope konsistent.
5. Das Modell mit bereinigtem Kontext aufrufen. Modell, Tracing und Prompt-Cache erhalten Platzhalter, niemals die Zuordnungstabelle.
6. Die Ausgabe prüfen. Erkenne neue sensible Werte, unerwartete Rohdaten und unautorisierte Platzhalter, bevor eine Antwort, ein Log oder ein Tool-Aufruf das Gateway verlässt.
7. Nur an der finalen autorisierten Grenze zurückauflösen. Löse erlaubte Platzhalter für den vorgesehenen Empfänger und Kanal auf. Re-identifiziere nie pauschal in Logs, Agent Memory oder Tool-Argumenten.

vertrauenswürdige Anwendung
  -> Feldminimierung
  -> Regeln + kontextsensitiver Detector
  -> Policy: blockieren | entfernen | tokenisieren
  -> verschlüsselter Token-Vault
  -> bereinigter Prompt -> LLM
  -> Output-Detector + Autorisierung
  -> selektive Rückauflösung -> Nutzer

Dieses Gateway ergänzt die Objekt- und Feldautorisierung aus unserem Leitfaden zu Datenzugriffskontrollen für KI-Agenten. Redaction begrenzt, was eine erlaubte Anfrage offenlegt. Autorisierung entscheidet, ob die Anfrage überhaupt auf den Datensatz zugreifen darf.

Redaction, Masking, Tokenisierung und Anonymisierung sind nicht dasselbe

Das falsche Wort erzeugt eine gefährliche Kontrolllücke. Entscheidend ist, ob der Wert wiederhergestellt werden kann und ob der verbleibende Kontext eine Person weiterhin identifiziert.

Nach Art. 4 Z 5 DSGVO muss die Zusatzinformation bei einer Pseudonymisierung getrennt aufbewahrt und geschützt werden. Die Leitlinien des Europäischen Datenschutzausschusses von 2025 stellen klar: Pseudonymisierte Daten bleiben personenbezogene Daten, wenn sie wieder einer Person zugeordnet werden können. Der Ersatz eines Namens durch PERSON_001 senkt die Exposition. Er nimmt den Workflow nicht aus der DSGVO.

Selbst das irreversible Entfernen eines Strings anonymisiert einen Prompt nicht automatisch. Eine seltene Berufsbezeichnung, ein genaues Ereignisdatum und ein kleiner Ort können gemeinsam eine Person identifizieren. Bewerte immer den gesamten Kontext inklusive Metadaten, Anhängen und Modellausgabe.

Welches Tool zur PII-Redaction passt 2026?

Beginne mit Feldminimierung in der Anwendung und deterministischen Regeln. Ergänze Presidio für ein prüfbares, erweiterbares Framework. Nutze ein lokales Kontextmodell, wenn Namen und Freitext dominieren. Verwende Managed DLP nur, wenn die Übertragung der Rohdaten an diese Cloud bereits freigegeben ist.

Ist Presidio noch ein Microsoft-Tool?

Presidio wurde bei Microsoft entwickelt und ältere Suchergebnisse nennen es weiterhin Microsoft Presidio. 2026 wechselt das Projekt zur unabhängigen Organisation Data Privacy Stack. Laut Projekt bleibt es MIT-lizenziert, die APIs bestehen weiter und neue Container-Images ziehen von der Microsoft Registry zu ghcr.io/data-privacy-stack. „Ursprünglich von Microsoft entwickelt“ ist korrekt. Die heutige Community-Governance als Microsoft-Supportvertrag zu behandeln, wäre falsch.

Das Framework bleibt ein starker Ausgangspunkt. Analyzer und Anonymizer verbinden Regex, Deny Lists, Prüfsummen, Regeln, Named Entity Recognition und Kontextsignale mit Replace-, Redact-, Hash- und Encrypt-Operatoren. Eigene Recognizer können österreichische Sozialversicherungsnummern, deutsche Steuer-IDs, spanische DNI- oder NIE-Formate, chinesische Identitätsnummern und interne Kunden-IDs abdecken. Die Presidio-Dokumentation warnt zugleich, dass automatische Erkennung nicht alle sensiblen Werte findet. Diese Warnung gehört in die Architektur und nicht nur ins Kleingedruckte.

Wann passt OpenAI Privacy Filter besser?

OpenAI Privacy Filter wurde im April 2026 unter Apache 2.0 veröffentlicht. Das lokale bidirektionale Token-Classification-Modell besitzt laut Veröffentlichung 1,5 Milliarden Parameter insgesamt, 50 Millionen aktive Parameter und ein Kontextfenster von 128.000 Tokens. Es erkennt acht Kategorien für private Personen, Adressen, E-Mails, Telefonnummern, URLs, Daten, Kontonummern und Secrets.

Dieses Sprachverständnis hilft, wenn Regex nicht zwischen einer Privatperson und einer öffentlichen Organisation unterscheiden kann. Es ist keine universelle Policy Engine. Laut Model Card ist die Basistaxonomie fest, die Leistung kann bei nicht englischen oder unbekannten Daten sinken und Policy-Anpassungen können Fine-Tuning brauchen. Das Modell ist ein Detector in der Pipeline, nicht Vault, Autorisierung oder Compliance-Entscheidung.

Wann ist Managed DLP die bessere Kaufentscheidung?

Managed DLP ist attraktiv, wenn die Organisation die Cloud-Grenze bereits freigegeben hat, breite Detector-Kataloge braucht und keine NLP-Modelle betreiben will. Azure AI Language PII deckt Texte, Gespräche und native Dokumente ab. Google Sensitive Data Protection bietet kryptografische Einweg- und reversible Tokens mit referenzieller Integrität. Amazon Comprehend PII liefert Entitätspositionen und asynchrone Redaction.

Der architektonische Haken ist einfach: Ein Cloud-Detector muss den Rohwert sehen, um ihn zu entfernen. Er kann das nachgelagerte LLM schützen und wird dabei selbst zum Empfänger der Originaldaten. Prüfe Region, Retention, Subprozessoren, AVV und Transferbedingungen im Rahmen deiner Entscheidung zur EU-Datenresidenz für KI.

Warum typisierte Platzhalter besser sind als eine Wand aus ENTFERNT-Tokens

Ein Modell kann viele Aufgaben weiterhin lösen, wenn es erkennt, dass sich zwei Stellen auf denselben Kunden, dieselbe Ärztin oder denselben Vertrag beziehen. Wer jede Entität durch [ENTFERNT] ersetzt, zerstört diese Beziehung. Eindeutige typisierte Platzhalter erhalten sie, ohne den Wert offenzulegen.

Rohtext: Maria schrieb Dr. Chen zweimal wegen Konto AT00...
Prompt:  PERSON_001 schrieb PERSON_002 zweimal wegen ACCOUNT_001.

Begrenze die Konsistenz der Tokens eng. Derselbe Wert darf innerhalb einer Anfrage oder einer freigegebenen Unterhaltung denselben Platzhalter erhalten, aber nicht über alle Kunden und Jahre hinweg. Globale deterministische Tokens werden selbst zu Tracking-IDs. Speichere Zuordnungen mit Mandant, Zweck, Ablaufzeit und berechtigtem Empfänger. Verschlüssele sie getrennt von Prompt-Logs und lösche sie, sobald keine Rückauflösung mehr nötig ist.

Vom Modell erfundene Platzhalter dürfen sich nie automatisch auflösen. Der Restore-Schritt akzeptiert nur Tokens, die das Gateway für diese Anfrage erzeugt hat, und prüft Empfänger sowie Ausgabekanal. Ein Token in einem Tool-Argument, Memory Store oder Analytics Event bleibt pseudonymisiert, solange keine eigene Policy dort die Rückauflösung erlaubt.

Wo sitzt das Gateway bei Chat, RAG und Agenten?

Bei RAG ersetzt Redaction keine Berechtigungen pro Nutzer. Auch eine bereinigte Passage kann vertrauliche Strategien offenlegen, und ein pseudonymisiertes Embedding kann personenbezogen bleiben. Nutze unsere RAG-Berechtigungsarchitektur für den Zugriff und diese Pipeline für Datenminimierung.

Wie testest du ein PII-Gateway vor Produktion?

Gib es nicht aufgrund eines Vendor-Benchmarks oder zehn handgeschriebener Prompts frei. Baue ein autorisiertes Eval-Set, das deine Sprachen, Formate, Fehlermuster und Geschäftsidentifikatoren abbildet. Nutze synthetische Beispiele für Breite und sauber geregelte gelabelte Samples für Realismus.

• Entity Recall je Risikostufe: Miss, wie oft verbotene Identifikatoren durchsickern. Ein übersehener Gesundheitsbezug darf nicht durch viele einfache E-Mail-Treffer verschwinden.
• Precision und Nutzwert: Miss entfernten Nutztext, Task Success vor und nach Bereinigung und den Erhalt von Entitätsbeziehungen.
• End-to-End-Leakage: Teste jeden Input-, Retrieval-, Tool-, Output- und Logging-Pfad, nicht nur die Detector-Funktion.
• Sprache und Locale: Berücksichtige deutsche Komposita, spanische Namen, chinesische Schrift, Transliteration, gemischte Prompts und lokale Identifikatoren.
• Adversariale Formatierung: Teste Leerzeichen, OCR-Fehler, Unicode-Lookalikes, über Felder geteilte Identifikatoren und Secrets in Code.
• Sichere Rückauflösung: Probiere fremde Mandanten-Tokens, abgelaufene Tokens, erfundene Platzhalter und verbotene Zielkanäle.
• Betrieb: Erfasse p50- und p95-Latenz, Timeouts, Versionsdrift, Vault-Ausfälle und Fail-Closed-Verhalten.

Setze Grenzwerte pro Workflow. Ein öffentlicher Marketing-Summarizer und ein klinischer Fallassistent haben nicht dieselbe akzeptable False-Negative-Rate. In Hochrisikopfaden führen unsichere Treffer zu Block oder Review. Bei geringerem Risiko kann ein False Positive zur Korrektur angezeigt werden. Ein langsamer oder ausgefallener Detector darf nie stillschweigend Fail Open auslösen.

"Ein PII-Detector ist ein Sensor, keine Sicherheitsgrenze. Die Grenze ist das Gateway, das Daten minimiert, Policy erzwingt, Rückauflösung kontrolliert und bei Unsicherheit sicher fehlschlägt."

Selbst bauen, kaufen oder kombinieren?

Für die meisten Produktionssysteme ist der Hybrid die ehrliche Antwort: deterministische Extraktion für bekannte Felder, Presidio für konfigurierbare Entitätslogik, ein Kontextmodell für mehrdeutigen Freitext und ein anwendungseigener Token-Vault. Widersprechen sich zwei Detectors, ist das ein Policy-Signal und kein Grund, einfach das billigere Ergebnis zu wählen.

Wenn du eine KI-Plattform einkaufst, ergänze die Gateway-Nachweise im Security-Fragebogen für KI-Anbieter in der EU. Wenn du selbst baust, kann Wavects AI-Enablement-Service den Datenfluss abbilden, einen begrenzten Workflow implementieren und deinem Team Tests sowie Betriebsdokumentation übergeben. Twinsoft AI zeigt die breitere Produktionsdisziplin rund um ein KI-System. Der Vergleich AI Enablement versus allgemeine KI-Beratung hilft bei der Entscheidung zwischen Umsetzung und Beratung.

Checkliste für die Umsetzung

1. Inventarisiere Roh-Prompts, Uploads, Retrieval-Quellen, Tool-Ergebnisse, Outputs, Caches und Logs.
2. Definiere je Zweck, welche Datenklassen blockiert, entfernt, pseudonymisiert oder erlaubt werden.
3. Entferne unnötige strukturierte Felder vor dem Zusammenbau des Texts.
4. Betreibe deterministische und kontextsensitive Detectors innerhalb einer freigegebenen Grenze.
5. Erzeuge eindeutige typisierte Tokens und einen mandantenbezogenen verschlüsselten Mapping Store.
6. Halte Rohwerte und Zuordnung aus Modellkontext, Traces und Analytics fern.
7. Prüfe die Modellausgabe und autorisiere jede Rückauflösung nach Token, Empfänger, Zweck und Kanal.
8. Teste mehrsprachige False Negatives, Nutzwert, adversariale Formate, Latenz und Ausfälle.
9. Dokumentiere Detector-Versionen, Policy-Entscheidungen und aggregierte Entitätszahlen ohne Rohinhalt.
10. Prüfe Rechtsgrundlage, AVV, Retention, Betroffenenrechte und DPIA-Bedarf mit Datenschutzexpertise.

Primärquellen

• Presidio-Dokumentation und Warnung zur automatischen Erkennung
• Übergang von Presidio zu Data Privacy Stack
• Beispiel für Prompt-Masking mit Presidio und LiteLLM
• Repository und Einschränkungen von OpenAI Privacy Filter
• Überblick zu Azure AI Language PII
• Pseudonymisierung mit Google Sensitive Data Protection
• PII-Erkennung und Redaction mit Amazon Comprehend
• EDSA-Leitlinien 01/2025 zur Pseudonymisierung
• OWASP LLM02:2025 Sensitive Information Disclosure