LLM prompt pseudonymization: how it works and where it breaks

Pseudonymization sits between your application and the model provider. It inspects the outbound prompt, identifies values matching your policy, substitutes tokens, forwards the sanitised request, and reverses the substitution on the way back so the user sees a coherent answer. Under GDPR it is explicitly recognised as a risk-reduction measure — and explicitly not as anonymisation.

The mechanics

1. Detection. Find candidate values using pattern matching for structured data, dictionaries and directory lookups for known entities, and named entity recognition for unstructured text such as person and organisation names.
2. Classification. Decide what each match is, because the handling differs. A national identification number, a customer name and an internal project codename warrant different treatment.
3. Substitution. Replace with a token that preserves enough type information for the model to reason correctly — PERSON_1 rather than a random string, so the model understands it is dealing with a person and can track them across the text.
4. Mapping. Store the token-to-value mapping for the duration of the request, keyed to the session, held outside the provider's reach.
5. Reversal. Substitute real values back into the response before it reaches the user.

Where detection fails

Unstructured identifiers

Structured data is straightforward: card numbers, IBANs and national identifiers have checkable formats. Names, addresses and free-text descriptions do not. Named entity recognition handles common cases well and degrades on unusual names, non-Latin scripts, and the mixed-language text that is completely normal in Nordic and Baltic business communication.

Context-dependent sensitivity

The most difficult category. 'The Riga office' is not personal data. 'The Riga office employee who filed the complaint' identifies a person if that office has four staff. No detector reliably catches this, because the sensitivity is in the combination and the surrounding real-world facts, not in any single token.

Inference from residue

Even a fully tokenised prompt can be re-identifying. A prompt reading 'PERSON_1, the CFO of ORG_1, resigned after the audit finding in the Q3 filing' contains no direct identifiers and identifies a specific individual to anyone who reads financial news. Pseudonymization removes identifiers; it does not remove information.

Secrets in pasted material

Detectors tuned for personal data frequently miss API keys, tokens and connection strings, which is a distinct pattern class. Any deployment should carry a secret detector alongside the personal data detector — and any secret that reaches a prompt should be treated as compromised regardless.

What it does and does not achieve

The fifth row deserves emphasis because it is where vendor messaging most often overreaches. A pseudonymization layer is a risk-reduction control, not a compliance exemption. Anyone selling it as the latter is describing a product that does not exist.

Architectural decisions that determine the risk profile

Where does detection run?

If the gateway is hosted by a third party, it receives raw prompts in order to inspect them — which means you have added a party to the data flow rather than removed one. That can still be a net improvement if the gateway operates under stronger terms and jurisdiction than the model provider, but it must be an explicit decision. A self-hosted data plane, where raw prompts and reversible mappings never leave your environment, has a materially different risk profile. Ask any vendor which model they operate, and get it in writing.

Where does the mapping live, and for how long?

The mapping table is now one of the most sensitive stores in your estate: it converts tokens back into real identities. It should be short-lived, scoped to a session, encrypted, and access-controlled more tightly than the application it serves.

What happens on detection failure?

Fail open — forward the prompt and log the uncertainty — or fail closed — block it. Fail-closed is correct for regulated data flows and produces user friction that drives people back to unmanaged tools. Fail-open preserves usability and permits leakage. Most sensible deployments differentiate by policy: fail closed for defined high-sensitivity categories, fail open with logging for everything else.

Where it genuinely fits

• Internal applications sending structured records to a model, where the sensitive fields are known in advance. This is the strongest case — detection is near-deterministic because you control the schema.
• Support and ticketing workflows where customer identifiers appear predictably.
• Code assistance where secret detection matters more than personal data detection.
• As an audit and visibility layer, giving you a record of what your applications actually send.

Where it fits least well is free-form staff usage of a general assistant. Detection quality on arbitrary unstructured text is the weakest case, and a control that works most of the time invites reliance it cannot support. For that scenario, a sanctioned tool with proper contractual terms plus a clear policy remains the stronger answer.