Pseudonymization vs Anonymization for LLM Prompts
Pseudonymization replaces identifiers with substitutes while a separately held mapping allows reversal, so the data generally remains personal data under GDPR. Anonymization removes the ability to assign data to a person, which is hard to demonstrate for free-text prompts. Choose per data type and use case, then enforce the choice on each interaction at runtime.
Where each technique fits in the prompt flow
- 1
1. Classify the interaction
Identify the data types present and the use case, then look up the policy: pseudonymize, remove, allow or block.
- 2
2. Detect identifiers
Find entities in free text and structured fields. Define the action for low-confidence or unparseable content.
- 3
3. Transform
Replace values with consistent pseudonyms where reversal is needed, or remove them where it is not.
- 4
4. Store the mapping separately
Hold the table or key outside the model path, with its own access control, retention and audit trail.
- 5
5. Submit and receive
The model sees only transformed content. Output may echo pseudonyms or infer context.
- 6
6. Re-insert if permitted
Restore real values only for authorized recipients and purposes. Output with restored values is personal data and needs matching controls.
Evaluation criteria for runtime enforcement
- Each data type is assigned to pseudonymization, anonymization, removal or block by policy, with the rationale recorded.
- The same policy applies across models and tools, not per application or per team.
- Enforcement happens before content reaches the model, and allow, redact and block are distinct, configurable actions.
- The mapping table or key is a separate controlled asset, and you can state who holds it and what protects it.
- Pseudonymized content is handled as personal data in retention, access and rights-handling processes.
- Each interaction produces evidence of which policy applied, which transformation was performed and what action was taken.
Definitions and vocabulary
Teams often use pseudonymization, anonymization and redaction as if they were interchangeable. They are different design choices with different legal and operational consequences.
GDPR Article 4(5) defines pseudonymisation as processing personal data so that it can no longer be attributed to a specific data subject without additional information. That information must be kept separately and be subject to technical and organisational measures that prevent attribution to an identified or identifiable person. In a prompt flow, the additional information is the token mapping or key.
The EDPB treats pseudonymisation and anonymisation as two different concepts. It describes pseudonymisation as a safeguard that reduces the linkability of data to a person without fully removing that link, and anonymisation as altering data so that it can no longer be assigned to a person.
One vocabulary note matters for policy documents. NIST IR 8053 uses de-identification as the general term and describes pseudonymization as a particular type of anonymization. This page follows the EDPB usage, where the two are distinct, because the legal outcomes differ. Whichever vocabulary your policy adopts, state it explicitly and apply it consistently.
Redaction is a mechanism, not a legal category. Removing or masking a span of text can support either approach, depending on whether a mapping is kept and what other content remains in the prompt.
How the two techniques compare
The comparison below applies to text submitted to internal and third-party models. The differences drive where each technique fits and what obligations remain after it is applied.
- Reversibility: Pseudonymization: reversible when the mapping table is retained or the pseudonym can be re-generated, for example by decrypting a key-protected identifier. Anonymization: not reversible by design, so values cannot be re-inserted into responses.
- Re-identification risk: Pseudonymization: whoever controls the mapping or key controls re-identification, and consistent pseudonyms keep records linkable. Anonymization: depends on whether any remaining content still allows assignment to a person, which is difficult to establish for free text.
- Utility for prompts: Pseudonymization: keeps entity relationships and consistency across a conversation, and supports restoring real values in output. Anonymization: may reduce response quality or break downstream workflows that need the original value.
- GDPR treatment: Pseudonymization: Recital 26 treats pseudonymised data attributable with additional information as information on an identifiable person, so obligations continue. Article 25 names it as a safeguard supporting data minimisation. Anonymization: the outcome is data that can no longer be assigned to a person.
- Operational burden: Pseudonymization: requires a protected mapping store with its own access control, retention and rights handling. Anonymization: no mapping to protect, but the claim of anonymity needs a documented rationale per data type.
Why anonymizing free-text prompts is difficult
Structured fields have known positions and formats. Prompts do not. A user may paste an email thread, a clinical note or a support transcript, and identifiers can appear anywhere in it.
Two problems follow from general reasoning about text. First, any entity detector can miss an identifier, so a prompt treated as clean may still contain a name or account number. Detection should be designed as a control that can fail, with a policy decision for what happens when confidence is low.
Second, removing direct identifiers does not necessarily remove identifiability. A role, a location, a date and a described event can together point to one person even when no name appears. The standard definitions cover replacement of direct identifiers. They do not establish that the remaining context is safe, so a claim of anonymity for free text needs more than a successful redaction pass.
The practical consequence is conservative. Treat prompt content that has been masked or tokenized as personal data unless you can document why nothing in it can be assigned to a person. Reversible tokenization should never be described as having removed data protection obligations. Recital 26 points the other way, and the retained mapping is exactly what makes the data attributable.
Irreversible removal has its own cost. It eliminates re-insertion, and the model may lose the context it needs to answer well. Decide per data type whether that loss is acceptable.
Enforcing the choice with Trussed
Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. For prompt content, policy can allow, redact or block on an individual interaction, so the decision is enforced at runtime, not reviewed after the fact.
Enforcement generates audit-ready evidence continuously, mapped to frameworks including HIPAA, EU AI Act and NIST. A regulated enterprise can use that evidence to show what policy applied to a given interaction and what happened to the content. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency, which bears on where mappings and evidence are held.
The technique decision itself, and the assessment of whether any data is truly anonymous, remains with your privacy and security teams.
Four treatments of sensitive prompt content
Pseudonymization
Identifier replaced by a pseudonym. Reversible if the mapping or key is retained.
Anonymization
Association with the person removed. No means of re-insertion into responses.
Redaction
Span removed or masked. Whether the result is anonymous depends on what remains.
Policy action
Allow, redact or block, decided and enforced per interaction.
Make the technique decision enforceable
Talk to an expert about enforcing allow, redact and block policy on prompt content, with audit-ready evidence for each interaction.
Talk to an Expert