Skip to content
unformation
Back to the blog

Blog

Pseudonymization vs anonymization vs redaction: which one do you need?

Three ways to strip identifying data from a document, how they differ in reversibility, and why consistent labels beat black bars when the file goes to an AI.

Published Updated 6 min read

"Anonymize this document" can mean three different things, and the difference matters when the document is going into an AI assistant. Redaction protects a court filing; anonymization protects a published dataset; pseudonymization protects a document you still need to work with. This post defines each, shows what they look like on the same paragraph, and explains why LLMs work best with the third.

Three definitions

Redaction removes content and leaves a visible gap: a black bar, "[REDACTED]" or "███". The reader knows something was there and nothing else. It is irreversible by design and is the standard for disclosure to outside parties who must not learn the value.

Anonymization transforms data so that the person can no longer be identified by anyone, using any means reasonably likely to be used, and the transformation cannot be undone. Under the GDPR (Recital 26), truly anonymous data is out of scope of the regulation. In practice it is achieved with generalization ("42" → "40 to 49"), aggregation, suppression of rare values, and similar techniques, and it is hard to reach with free text.

Pseudonymization replaces identifying values with labels or tokens so the data can no longer be attributed to a person without additional information, which is kept separately (GDPR Article 4(5)). "Jane Doe" becomes "Person 1", and a mapping table stores the link. It is reversible for whoever holds the table, and irreversible for everyone else. The data is still personal data in legal terms, but the risk is much lower.

The same paragraph, three ways

Original:

On 3 March, Jane Doe from Acme GmbH emailed jane@acme.example to say that Bosch had rejected invoice 4711 and asked Michael Roe to call her on +49 30 1234567.

Redacted:

On ███, ███ from ███ emailed ███ to say that ███ had rejected invoice ███ and asked ███ to call her on ███.

Anonymized (generalized):

In early spring, an employee of a German manufacturer emailed a colleague to say that a customer had rejected an invoice and asked a coworker to call her.

Pseudonymized:

On 3 March, Person 1 from Company A emailed email1@example.com to say that Company B had rejected invoice ID 1 and asked Person 2 to call her on +49 30 0000001.

Read them as if you were an assistant asked "who should follow up, and with whom?". The redacted version cannot be answered. The anonymized version answers vaguely. The pseudonymized version answers precisely: Person 2 should call Person 1 about Company B's rejection.

When each one is appropriate

RedactionAnonymizationPseudonymization
ReversibleNoNoYes, with the mapping table
Still personal data (GDPR)Depends on what remainsNo, if done properlyYes, but with reduced risk
Keeps document structurePartlyPoorlyYes
Keeps who-did-what contextNoWeaklyYes
Typical useCourt filings, FOI responses, public disclosurePublished statistics, research datasets, open dataAI prompts, outsourcing, testing, internal analysis
Effort on free textMediumHighLow to medium

Some rules of thumb:

  • If the recipient must never be able to learn the value and you do not need the document to remain analyzable, redact.
  • If you are publishing data and no one, including you, should be able to re-identify people afterwards, anonymize and validate the result.
  • If you need to keep working with the document (summarize it, translate it, extract data from it, ask questions about it) and you want to restore names later, pseudonymize.

AI prompts almost always fall in the third category.

Why redaction breaks LLM context

Language models rely on entities being distinguishable. When every name becomes the same black bar, the model loses:

  • Coreference. It cannot tell that the person in paragraph one is the same as the person in paragraph seven.
  • Roles. Buyer and seller, claimant and defendant, manager and employee collapse into "███".
  • Counts. "Three parties" becomes an unknown number of gaps.
  • Format cues. A redacted email or date is no longer recognizably an email or date, so extraction and validation tasks fail.

The result is a summary full of hedges ("someone contacted someone else about a document") or, worse, a confident answer that has silently merged two people into one.

Consistent labels fix all four problems. "Person 1" in paragraph one is "Person 1" in paragraph seven. "Company A" and "Company B" remain two companies. email1@example.com still looks like an email. The model does not need to know who Person 1 is to reason about what Person 1 did.

Consistency is the whole trick

Pseudonymization only works if it is consistent:

  • Same input, same label, across the whole document and across every file in the same batch. If "Jane Doe", "J. Doe" and "Doe" get three labels, the model sees three people.
  • Different input, different label. Two people should never share "Person 1".
  • Format-preserving where it matters. Replace an IBAN with an IBAN-shaped placeholder, a date with a date, so tables and scripts keep working.
  • A mapping table you keep, and the provider never sees. That table is the "additional information" in the legal definition. If it travels with the document, you have done nothing.

Tools help here because they never forget a label. In Unformation, every detected value gets a stable label per category (Person 1, Company A, email1@example.com), the same mapping is applied across up to 10 files at once, and the table can be exported as CSV or JSON. The de-anonymizer applies it in reverse to the assistant's answer.

Where anonymization still wins

Pseudonymization is not the answer to everything:

  • Publishing. If a document or dataset will be public, labels are not enough; rare combinations of remaining attributes can still identify people. Use real anonymization techniques and test them.
  • Long-term storage without a purpose. If you will never need to re-identify, do not keep the key.
  • Special categories. Health data or criminal records need more caution than a label; the safest choice for a general-purpose assistant is often to leave that content out entirely.

Where redaction still wins

  • Legal disclosure where the counterparty must not infer even the shape of the value.
  • Screenshots and images, where consistent text replacement is not practical.
  • Single-value hiding, such as a password in a log line.

Summary

Redaction hides, anonymization erases, pseudonymization relabels. For anything you plan to feed into a language model, relabelling with consistent placeholders keeps the document useful and takes most of the risk out of the prompt, as long as the mapping table stays with you.

Try it on a real file: anonymize a document in your browser, then restore names in the answer with the de-anonymizer. Nothing leaves your device; see security for how to verify that.

Try it on your own document

Anonymize a DOCX, PDF, PPTX, XLSX or text file in your browser. No upload, no account, works with Wi‑Fi off.

Open the tool

Blog

More from the blog

All posts