Key takeaways
- Combine rules (IDs, phones, IBANs) with an NER model for names and places.
- Redact at ingestion, and again before inference.
- Measure recall on your own data, not on a benchmark.
- Log what was redacted, never the original values, and remember that redacted data can still be personal data.
Redaction reduces risk, but it is not automatically anonymisation
Combine format rules for identifiers with named entity recognition for names and contextual details. Redact personal data the task does not need before indexing and before model calls, including user prompts. Test on your documents and transcripts. Masking reduces exposure, but GDPR still applies if someone can identify a person from the remaining text or a separate mapping.
Techniques
| Approach | Good at | Misses |
|---|---|---|
| Regex / rules | IDs, phones, emails, IBANs | Names, free-text context |
| Rules with validation | IBANs checked by their checksum, Spanish DNI and NIE checked by their control letter | Anything without a fixed format |
| NER model | Names, places, organisations | Rare formats, domain codes |
| Dictionary lookup | Known names, departments, product and clinic codes | Anything not in the list |
| Hybrid | Both | Needs tuning per domain |
How to replace what you find
| Strategy | Example | Use when |
|---|---|---|
| Plain mask | [REDACTED] | The value is not needed for the task |
| Typed placeholder | [PERSON_1], [IBAN] | The model needs to know what kind of thing was there |
| Consistent token | The same person is always [PERSON_1] in a document | The model must follow who did what |
| Generalisation | A birth date becomes a year, a postcode becomes a region | Some detail is useful but the exact value is not |
| Synthetic replacement | A realistic fake name | Text must read naturally, but beware of mistaking fakes for real people |
Where redaction belongs
Redact once when data enters the system, and again right before any call to a model. The second pass catches whatever a user typed straight into a prompt.
- At ingestion, before documents are chunked, embedded and stored.
- Before every model call, on the prompt as well as on the retrieved passages.
- In logs and traces, so that monitoring does not become a second copy of the raw data.
- On outputs, where a model might repeat something it should not.
Why speech pipelines are harder
In speech, the identifiers are spoken. A phone number arrives as a string of digit words, an ID is read out letter by letter and a name may be misrecognised before any redaction rule sees it. The sensible order is to transcribe first, redact the text, and only then pass it to a language model. Test the redaction on transcripts, not on typed text, because the errors are different.
How to measure whether it works
- Assemble a labelled sample of your own documents or transcripts, in every language you handle.
- Mark every personal detail a person would want removed.
- Run your redaction and compare, entity by entity.
- Track recall first, because a missed name is a leak, and precision second, because over-redaction destroys meaning.
- Rerun the test whenever you change a model, a rule or a language.
- Sample real outputs in production every week and add what you find to the test set.
Log what was redacted, such as the entity type and position, but never the original values. A redaction log full of the original names defeats its own purpose.
Common failures
| Failure | Cause | Fix |
|---|---|---|
| A rare or foreign name slips through | NER trained mostly on common names | Add a dictionary for known people and test per language |
| A drug name is replaced as if it were a person | Over-eager NER | Add a domain allow-list and review false positives |
| An ID split across two lines survives | Rules applied line by line | Normalise whitespace before matching |
| Personal data in file names, metadata or URLs | Only the body text was redacted | Redact metadata and sanitise names on ingestion |
| Raw text in logs | Logging happens before redaction | Move redaction ahead of the logger |
Tell us which documents, languages and identifiers your pipeline handles. We can design and test redaction before data reaches your model or logs.
Discuss your redaction pipelineFAQ
Can redaction be reversed?
Only if you keep a mapping. Store it separately with tighter access, or don't store it at all.
Is redacted data anonymous?
Not automatically. If the remaining text could still be linked back to a person, it remains personal data under the GDPR, so keep the other safeguards in place.
Do we still need redaction if the model is hosted in the EU?
Yes, in most regulated work. EU hosting settles where the data is processed. Redaction limits what the model, its logs and its operator ever see, which lowers the damage of any mistake.
Sources
- Regulation (EU) 2016/679 (GDPR), Article 4(1) and (5) and Recital 26
- European Data Protection Board, Guidelines 01/2025 on pseudonymisation
- OWASP Top 10 for LLM Applications, sensitive information disclosure
About the author
Erik Salo Akimov · Co-founder · Engineering
Erik runs engineering at ESADEX. He designs the platforms, infrastructure and security controls that sit behind client systems.
