PII-Redaction und DLP für Finanz-KI

PII-Redaction und DLP für ein Finanz-KI-System ist die Schicht, die sensible Kundendaten entfernt oder tokenisiert, bevor sie ein Modell, einen Anbieter oder ein Log erreichen, und die anschließend jede Grenze prüft, die diese Daten überschreiten. Sie behandeln die Erkennung als Machine-Learning-Problem, redigieren die Felder, die die Aufgabe nicht braucht, tokenisieren die, die sie braucht, und protokollieren jede Grenzüberschreitung, damit der Audit-Trail eine Tatsache ist und keine Rekonstruktion.

Kundendaten erreichen Ihr Modell – ob Sie einen Pfad dafür entworfen haben oder nicht. Ein Support-Mitarbeiter fügt einen kompletten Kontoauszug in einen Prompt ein, eine Retrieval-Pipeline indexiert einen KYC-Ordner, ein Anreicherungsjob joint Kontonummern auf eine Feature-Tabelle. Wenn Sie keine Redaction- und DLP-Schicht gebaut haben, lautet die Standardantwort auf „Wohin ist diese Sozialversicherungsnummer gegangen?” ein Schulterzucken und ein Grep durch Anbieter-Logs, die Sie nicht einsehen können. Was folgt, ist der Weg zu einer echten Antwort stattdessen.

Das Versagen, das sich die Leute vorstellen, ist ein Trainingslauf, der einen Kundendatensatz auswendig lernt und ihn später wieder ausspuckt. Das passiert, aber es ist nicht der Regelfall. Der Regelfall ist unspektakulärer und häufiger: Ein Identifikator landet an einer Stelle, für die er nie vorgesehen war – ein Prompt-Log bei einem Drittanbieter, ein Vector Store ohne feldgenaue Zugriffskontrolle, ein Debug-Trace, den jemand auf INFO stehen gelassen hat. Sobald er dort ist, haben Sie eine Meldepflicht und keine saubere Möglichkeit, den Blast Radius zu belegen. Der Sinn einer Data-Loss-Schicht ist es, sicherzustellen, dass der Rohwert diese Stellen gar nicht erst erreicht.

Erst erkennen – und Erkennung als ML-Problem behandeln

Sie können nicht schützen, was Sie nicht finden, und PII in Freitext zu finden ist schwerer, als die Regex-Demos vermuten lassen. Kontonummern gibt es in einem Dutzend Formaten. Namen kollidieren mit gewöhnlichen Wörtern. Eine IBAN, die ein PDF-Extraktor über zwei Zeilen verteilt hat, ist für ein Muster, das eine Zeile erwartet, unsichtbar. Der Detektor ist also ein Modell, oder ein Stack davon, und er verdient dieselbe Disziplin, die Sie einem Kreditmodell geben würden: ein gelabeltes Eval-Set aus Ihren eigenen Dokumenten, Precision und Recall pro Entity-Typ gemessen, und ein False-Negative-Budget, das feststeht, bevor irgendjemand über Bequemlichkeit diskutiert.

Die Budget-Perspektive ist wichtig, weil die beiden Fehler nicht symmetrisch sind. Ein False Positive redigiert ein Wort, das harmlos war, und verärgert einen Leser leicht. Ein False Negative schickt einen aktiven Identifikator zu einem Anbieter. Wir drehen den Recall bei den Entitäten mit regulatorischem Gewicht hoch – amtliche Ausweisnummern, Kartennummern, Konto- und Bankleitzahlen – und akzeptieren dort eine höhere False-Positive-Rate, als wir sie etwa beim Vornamen einer Person tolerieren würden. Kontextuelle Detektoren helfen: Eine neunstellige Zahl neben „SSN” oder „Steuer-ID” ist nicht dasselbe wie eine neunstellige Rechnungsreferenz, und ein Modell, das die umgebenden Tokens liest, erkennt den Unterschied, den ein isoliertes Muster übersieht.

Erkennung driftet außerdem. Neue Dokumentvorlagen, das Exportformat eines neuen Partners, ein Produkt, das plötzlich ein Feld erhebt, das Sie noch nie gesehen haben. Das Eval-Set bleibt deshalb lebendig. Führen Sie es erneut aus, wann immer sich die Eingabeverteilung ändert, und beobachten Sie den Recall pro Entität so, wie Sie die Modellperformance in Produktion beobachten – denn ein stiller Einbruch beim SSN-Recall ist ein Datenleck, das nur noch auf sein Datum wartet.

Tokenisieren, wenn Sie den Wert zurückbrauchen; redigieren, wenn nicht

Sobald Sie die sensiblen Spans gefunden haben, haben Sie zwei Optionen, und die Wahl zwischen ihnen pro Feld ist der Großteil des Designs.

• Redaction entfernt den Wert und ersetzt ihn durch einen Typmarker, sodass aus John Okafor [NAME] wird. Nutzen Sie das, wenn die nachgelagerte Aufgabe den Identifikator gar nicht braucht: das Zusammenfassen eines Anrufs, das Verfassen einer Beschwerdedarstellung, das Klassifizieren eines Tickets. Der Rohwert gelangt nie in den Prompt, also kann er aus dem Prompt auch nicht durchsickern.
• Tokenisierung tauscht den Wert gegen ein Surrogat, das über einen Vault, den Sie kontrollieren, zurückgeführt werden kann. Nutzen Sie das, wenn die Pipeline die Identität wirklich braucht – für Joins, Deduplizierung, Entity Resolution oder Straight-Through Processing, das eine Entscheidung zurück auf das echte Konto schreiben muss.

Die Falle bei der Tokenisierung ist Inkonsistenz. Wenn dieselbe Kontonummer in zwei Tabellen einen anderen Token bekommt, bricht jeder Join, und Ihre Entity Resolution zerlegt einen Kunden klammheimlich in drei. Die Token sind deshalb deterministisch und, wo das Schema es verlangt, format-erhaltend: Dieselbe Eingabe ergibt immer denselben Token, und ein kartenförmiges Feld bleibt kartenförmig, damit die nachgelagerte Validierung es nicht ablehnt. Das gibt Ihnen referenzielle Integrität auf dem Surrogat. Analysten und Modelle arbeiten auf Token; nur ein kleiner, auditierter Service hält den Schlüssel, um sie umzukehren, und jede Detokenisierung ist ein protokolliertes Ereignis mit Aufrufer, Zweck und Zeitstempel.

Format-erhaltende Token haben einen zweiten Vorteil, den man benennen sollte. Weil das Surrogat die Form und die Prüfziffer-Gültigkeit des echten Werts behält, können Sie Abstimmungen und Lineage-Prüfungen auf tokenisierten Daten durchführen, ohne je den Vault zu berühren. Der Audit-Trail folgt dem Token von der Erfassung bis zur Entscheidung, und wenn ein Prüfer fragt, wohin die Daten eines bestimmten Kunden gegangen sind, antworten Sie mit Lineage statt mit einem Schulterzucken.

Setzen Sie die Kontrollen an die Grenze und protokollieren Sie, was sie überschreitet

Redaction und Tokenisierung sind sinnlos, wenn es einen Bypass gibt – und in den meisten Architekturen gibt es mehrere. Man schließt sie, indem man die Modellgrenze als Checkpoint behandelt, den aller Verkehr passiert, nicht als Empfehlung, für die sich jeder Service einzeln entscheidet.

• Egress-Inspektion. Ein DLP-Proxy sitzt zwischen Ihren Systemen und jedem externen Modell oder Anbieter. Er inspiziert ausgehende Prompts, wendet die Redaction- und Tokenisierungs-Policy an und blockiert oder isoliert alles, was einen ungelösten High-Severity-Identifikator trägt. Nichts erreicht einen Dritten unkontrolliert.
• Response-Scanning. Die Modellausgabe läuft auf dem Rückweg durch denselben Detektor, denn ein Modell kann einen Identifikator rekonstruieren oder umschreiben, der nicht wörtlich im Prompt stand. Das ist das zweite Netz, dimensioniert für die Restfälle, nicht die primäre Kontrolle.
• Log-Hygiene. Das leiseste Leck ist der Observability-Stack. Prompt-Logs, Traces, Error-Payloads und Eval-Captures durchlaufen alle denselben Redaction-Schritt wie der Produktionsverkehr – denn ein vollständiger Datensatz, der neunzig Tage auf INFO liegt, ist genau die Exposition, die die ganze Schicht verhindern soll.
• Feldgenauer Zugriff auf Stores. Vector Stores und Feature-Tabellen tragen Spalten- und Namespace-Kontrollen, sodass eine Retrieval-Query kein Feld ziehen kann, das der Aufrufer nicht sehen darf. Tokenisiert-at-Rest bedeutet, dass ein kompromittierter Index Surrogate liefert, keine Kunden.

Nichts davon ist exotisch. Es ist Boundary Engineering: wissen, wo sensible Daten an einen Ort übertreten können, den Sie nicht kontrollieren, dort einen Policy-durchsetzenden Checkpoint platzieren und jede Grenzüberschreitung protokollieren. Die Teams, die gehackt werden, sind selten die, die das falsche Tokenisierungsschema gewählt haben. Es sind die, die einen Pfad ohne Checkpoint offen ließen – und es von einem Kunden erfuhren.