How-to· 1 min
Keeping personal data out of an LLM, and the limits of redaction
The second category is the one that gets organisations in trouble.
AI Tools Hub Editorial · published · updated
Detectable mechanically
- Names via NER and dictionaries
- Phone numbers and email addresses by pattern
- Addresses by pattern plus place dictionaries
- National ID and card numbers by length and checksum
- Dates of birth by date pattern
Not detectable mechanically
- "The head of the second sales division" — unique inside the organisation
- "The person who joined last week"
- "Handled the account with that supplier"
- "Was off for three months with the same illness" — potentially sensitive category data
These are context-dependent, so pattern matching cannot reach them. Either a person reads the document, or documents of this kind never go to the model.
A workable line
| Document type | Handling |
|---|---|
| Contains customer personal data | Do not send, or only via a contractually zero-retention path |
| Internal HR material | Do not send |
| Internal documents containing names only | Redact mechanically and send |
| Public or technical material | Send as is |
Make replacements consistent
Map each individual to a stable placeholder so the relationships survive. Replacing everything with the same token destroys the context and the output quality with it. Keep the mapping on your side and never send it.
FAQ
Does running locally remove the issue?
It removes the third-party transfer question. Internal access control remains — check that HR data is not readable by everyone.