PII redaction and DLP for finance AI

PII redaction and DLP for a finance AI system is the layer that strips or tokenises sensitive customer data before it reaches a model, a vendor, or a log, then inspects every boundary that data crosses. You treat detection as a machine-learning problem, redact the fields the task does not need, tokenise the ones it does, and record each crossing so the audit trail is a fact rather than a reconstruction.

Customer data reaches your model whether you designed a path for it or not. A support agent pastes a full bank statement into a prompt, a retrieval pipeline indexes a KYC folder, an enrichment job joins account numbers onto a feature table. If you have not built a redaction and DLP layer, the default answer to “where did that SSN go” is a shrug and a grep through vendor logs you cannot see. The work below is how you get a real answer instead.

The failure people picture is a training run that memorises a customer record and later regurgitates it. That happens, but it is not the common case. The common case is duller and more frequent: an identifier lands in a place it was never scoped for, a prompt log at a third-party provider, a vector store with no field-level access control, a debug trace someone left at INFO. Once it is there, you have a notification obligation and no clean way to prove the blast radius. The point of a data-loss layer is to make sure the raw value never arrives in those places to begin with.

Detect first, and treat detection as an ML problem

You cannot protect what you cannot find, and finding PII in free text is harder than the regex demos suggest. Account numbers have a dozen formats. Names collide with ordinary words. An IBAN split across two lines by a PDF extractor is invisible to a pattern that expects one. So the detector is a model, or a stack of them, and it earns the same discipline you would give a credit model: a labelled eval set built from your own documents, precision and recall measured per entity type, and a false-negative budget set before anyone argues about convenience.

The budget framing matters because the two errors are not symmetric. A false positive redacts a word that was safe and mildly annoys a reader. A false negative ships a live identifier to a vendor. We tune recall high on the entities that carry regulatory weight, government IDs, card numbers, account and routing numbers, and accept a fatter false-positive rate there than we would tolerate on, say, a person’s first name. Contextual detectors help: a nine-digit number next to “SSN” or “Tax ID” is not the same as a nine-digit invoice reference, and a model that reads the surrounding tokens catches the difference a standalone pattern misses.

Detection also drifts. New document templates, a new partner’s export format, a product that starts collecting a field you never saw before. So the eval set stays live. Re-run it whenever the input distribution changes, and watch per-entity recall the way you watch model performance in production, because a silent drop in SSN recall is a breach waiting for its date.

Tokenise when you need the value back, redact when you do not

Once you have found the sensitive spans, you have two moves, and choosing between them per field is most of the design.

• Redaction removes the value and replaces it with a type marker, so John Okafor becomes [NAME]. Use it when the downstream task does not need the identifier at all: summarising a call, drafting a complaint narrative, classifying a ticket. The raw value never enters the prompt, so it cannot leak from the prompt.
• Tokenisation swaps the value for a surrogate that maps back through a vault you control. Use it when the pipeline genuinely needs identity, for joins, deduplication, entity resolution, or straight-through processing that has to write a decision back to the real account.

The trap with tokenisation is inconsistency. If the same account number gets a different token in two tables, every join breaks and your entity resolution quietly fragments one customer into three. So the tokens are deterministic and, where the schema demands it, format-preserving: the same input always yields the same token, and a card-shaped field stays card-shaped so downstream validation does not reject it. That gives you referential integrity on the surrogate. Analysts and models operate on tokens; only a small, audited service holds the key to reverse them, and every detokenisation is a logged event with a caller, a purpose, and a timestamp.

Format-preserving tokens have a second benefit worth naming. Because the surrogate keeps the shape and check-digit validity of the real value, you can run reconciliation and lineage checks on tokenised data without ever touching the vault. The audit trail follows the token from ingestion to decision, and when an examiner asks where a given customer’s data went, you answer with lineage instead of a shrug.

Put the controls at the boundary, and log what crosses it

Redaction and tokenisation are pointless if there is a bypass, and in most architectures there are several. The way to close them is to treat the model boundary as a checkpoint that all traffic passes through, not a suggestion each service opts into.

• Egress inspection. A DLP proxy sits between your systems and any external model or vendor. It inspects outbound prompts, applies the redaction and tokenisation policy, and blocks or quarantines anything carrying an unresolved high-severity identifier. Nothing reaches a third party un-inspected.
• Response scanning. Model output goes through the same detector on the way back, because a model can reconstruct or paraphrase an identifier that was not literally in the prompt. This is the second net, sized for the residual cases, not the primary control.
• Log hygiene. The quietest leak is the observability stack. Prompt logs, traces, error payloads, and eval captures all get the same redaction pass as production traffic, because a full record sitting at INFO for ninety days is exactly the exposure the whole layer exists to prevent.
• Field-level access on stores. Vector stores and feature tables carry column and namespace controls so a retrieval query cannot pull a field the caller has no right to see. Tokenised-at-rest means a compromised index yields surrogates, not customers.

None of this is exotic. It is boundary engineering: know where sensitive data can cross into a place you do not control, put a policy-enforcing checkpoint there, and log every crossing. The teams that get breached are rarely the ones who chose the wrong tokenisation scheme. They are the ones who left a path with no checkpoint on it and found out from a customer.