Kapitel 8 — Datenanonymisierung in der RAG-Pipeline

Achter Beitrag der kapitelweisen Tour durch LLM Primer III: Enhancing Enterprise AI with RAG. Sollen die Daten anonymisiert werden, bevor das Modell sie sieht, oder bevor der Nutzer den Output sieht? Die Antwort ändert alles an der Pipeline, und das regulatorische Regime wählt die Antwort meist für dich.

Warum dieses Kapitel existiert

Kapitel 7 hat wer kann was sehen beantwortet. Es nahm an, dass es etwas zu sperren gibt. Aber Kapitel 6 hat auch gezeigt, dass das Embedding keine Einwegfunktion ist — der Vektor-Store ist eine unscharfe Kopie der Quelle, und Zugriffskontrolle ist nur die äußere Schicht. Wenn der Korpus Sozialversicherungsnummern, medizinische Akteneinträge, Kundennamen oder proprietäre Code-Pfade enthält, ist die Frage nicht mehr nur, wer sie abrufen darf. Sie ist, ob sie in dieser Form überhaupt eingebettet hätten werden sollen.

Das ist die Frage der Anonymisierung, und sie ist die ingenieurslastigste Sicherheitsentscheidung in einem RAG-Deployment. Die Wahl ist positionell, bevor sie algorithmisch ist: An welcher Stufe wird sensibler Inhalt transformiert?

8.1 Pre-Generation gegen Post-Generation

Pre-Generation-Anonymisierung transformiert die Daten, bevor sie eingebettet und gespeichert werden. Der Vektor-Store enthält die ursprünglichen sensiblen Werte nie; auch eine vollständige Kompromittierung auf Modell-Ebene kann nicht extrahieren, was nie da war. Das ist die Architektur, die für viele HIPAA-pflichtige medizinische RAG-Systeme und mehrere GDPR-gebundene juristische Anwendungen vorgeschrieben ist. Der Preis ist Retrieval-Qualität: Die Query sagt "Acme Corp", der Korpus sagte vor dem Einbetten "[ORG_47]", und die Dense-Ähnlichkeit fällt auf dem informativsten Token.

Post-Generation-Anonymisierung läuft auf dem Modell-Output. Die Retrieval-Qualität bleibt erhalten; die Privatsphäre-Garantie ist schwächer, weil die sensiblen Daten im Index stehen. Sie ist angemessen, wenn das Bedrohungsmodell ein nutzerseitiges Leck statt eines infrastrukturseitigen ist. Die meisten Produktionssysteme landen am Ende bei einem Hybrid — direkte Identifikatoren und stark regulatorisch gewichtete Kategorien werden pre-generation behandelt, schwächer gewichtete operative Sensibilitäten beim Output maskiert, gestützt auf das Autorisierungsprofil des Nutzers. Zwei Umsetzungsdisziplinen zählen: Anonymisierung vor dem Chunking laufen lassen (sonst zerstört der Chunker den Kontext, den der Detektor braucht), und ein De-Tokenisierungs-Vault als separate, zugriffsgeschützte Mapping-Tabelle führen, damit eine Ärztin mit passender Rolle die Patienten-ID weiterhin sehen kann, die der Index maskiert hat.

8.2 Masking, synthetischer Ersatz, differenzielle Privatsphäre

Die Techniken teilen sich in drei Familien auf einer einzigen Skala. PII-Masking erkennt Entitäten (Microsoft Presidio ist die am weitesten verbreitete offene Implementierung) und ersetzt sie durch Platzhalter. Die schweren Probleme sind Recall — ein Detektor, der zehn Prozent der Namen verfehlt, produziert redigierte Dokumente, die ein Angreifer per Embedding-Ähnlichkeit lokalisieren kann — und Over-Masking, das den Wortschatz kollabieren lässt und das Retrieval beschädigt. Die Disziplin ist doppelte Messung: Recall auf einem gelabelten Set und ein Offline-Retrieval-Qualitäts-Benchmark.

Synthetischer Ersatz setzt einen plausiblen Fake-Wert anstelle eines Platzhalters ein, sodass "Hans Schmidt" zu "Alex Romano" wird statt zu [NAME]. Das Embedding bleibt gut verteilt und liest sich für das Modell natürlich. Das Mapping ist deterministisch — ein gekeyter Hash von echter Entität zu Fake —, sodass dieselbe echte Entität über den Korpus hinweg denselben Fake bekommt, und der Schlüssel lebt im Vault. Synthetischer Ersatz leckt weiterhin gegen einen Angreifer mit Hilfsinformationen, ist aber eine sinnvolle Verbesserung gegenüber Masking, wenn Retrieval-Qualität zählt.

Differenzielle Privatsphäre ist die Familie, die tatsächlich eine mathematische Garantie bietet — ein Mechanismus ist ε-DP, wenn sich die Output-Verteilung um höchstens exp(ε) ändert, sobald irgendein einzelner Datensatz hinzugefügt oder entfernt wird. DP-Prompt perturbiert die für den Prompt ausgewählten Chunks; DP-MLM perturbiert den Masked-Language-Model-Embedding-Pass; 1-Diffractor kombiniert DP mit bedeutungswahrendem Rewriting. DP ist ein Budget, kein Schalter — jede Query verbraucht etwas, und die operative Disziplin ist vor allem Budget-Buchhaltung. Die drei Familien komponieren, und das richtige Deployment schichtet sie meist.

8.3 Der Utility-Privacy-Tradeoff

Die Tokens, deren Anonymisierung am meisten lohnt, sind die Tokens, deren Anonymisierung das Retrieval am stärksten beschädigt. Die Asymmetrie ist unangenehm, aber nicht verhandelbar. Linderungen sind partiell: Synthetischer Ersatz erhält mehr Signal als Platzhalter; typgetaggte Platzhalter ([PERSON namens Alex] statt [PERSON]) erhalten noch mehr, zu Lasten schwächerer Maskierung. Anonymisierte Korpora wollen oft etwas größere Chunks als nicht-anonymisierte, weil der Redigierungsverlust über mehr überlebenden Inhalt amortisiert wird.

Die ehrliche Rahmung: Der Tradeoff ist keine eindimensionale Skala, sondern eine zweidimensionale Fläche — der regulatorische Boden, unter dem das System illegal ist, der Utility-Boden, unter dem Nutzer es aufgeben, und die Betriebszone dazwischen. Manchmal ist die Lücke breit und viele Designs funktionieren. Manchmal ist die Lücke leer: Der regulatorische Boden sitzt über dem Utility-Boden, und das Wertvollste, was die Designphase tun kann, ist das zu erkennen, bevor Aufwand in ein System fließt, das nicht gebaut werden kann.

8.4 Unternehmensintegration und Designwahl

Zilliz Cloud exponiert Anonymisierung als Pipeline-Transformation zwischen Parser und Embedder, mit Hooks an vier Checkpoints (Ingestion, Retrieval, De-Tokenisierung, Output). PII Masker nimmt die entgegengesetzte Form an — ein fokussierter Baustein, den Teams in ihre eigenen Pipelines komponieren. Gereifte Deployments bauen oft einen zentralen Anonymisierungs-Service mit vier Operationen: ein geparstes Dokument anonymisieren, De-Tokenisierung unter einem Autorisierungskontext nachschlagen, einen Output-String auf Restsensibilitäten scannen und das verbrauchte Privatsphäre-Budget melden.

Die Designentscheidung beginnt bei der Regulierung, nicht beim Algorithmus. HIPAA Safe Harbor mappt sauber auf PII-Masking mit einer festen Achtzehn-Kategorien-Liste. PCI DSS wird durch Tokenisierung erfüllt — synthetischer Ersatz plus Vault. Das Datensparsamkeitsprinzip der DSGVO drückt für die sensibelsten Kategorien zur Pre-Generation. Differenzielle Privatsphäre ist von keiner großen Regulierung vorgeschrieben, ist aber die richtige Antwort, wenn das Bedrohungsmodell einen ausgeklügelten Angreifer mit Hilfsdaten umfasst und der Korpus Datensätze enthält, die bei einer Re-Identifizierung meldepflichtig wären.

Was Kapitel 8 vorbereitet

Die Kapitel 7 und 8 vervollständigen zusammen Teil IV. Zugriffskontrolle beantwortet, wer was sehen darf; Anonymisierung beantwortet, was überhaupt zu sehen ist. Beides sind Infrastruktur-Entscheidungen, die der Rest der Pipeline respektieren muss, und beide hängen von Entscheidungen ab, die zur Parsing- und Chunking-Zeit getroffen wurden und sich nicht billig zurücknehmen lassen. Mit dem System entworfen und gesichert ist die nächste Frage, ob es funktioniert — und das verlangt eine Methode, es zu messen.

Als Nächstes — Kapitel 9: Die RAG-Evaluations-Triade. Context Relevance, Groundedness und Answer Relevance — drei unabhängige Signale, die zusammen dem Betreiber sagen, ob das System beim Retrieval, beim Generieren oder bei der Verbindung dazwischen versagt.