Updated: 22 October 2026.
A redaction tool removes names, telephone numbers and email addresses from a document. Is the remaining text safe to share?
I would read what survives before answering. A person may still be identifiable through their role, location, dates or a distinctive event, even when their name has disappeared.
That is the central difficulty with PII redaction: some identifiers have a recognisable format, while others become identifying only in context.
Start with the information and its audience
Imagine this fictional sentence: “The only database administrator at the east office requested leave after the incident on Monday.” Removing a name would not necessarily conceal the person from colleagues.
The audience matters. A description that reveals little to a stranger may be obvious to somebody who knows the organisation. I would therefore define the sharing purpose and intended recipients before deciding what needs removal or generalisation.
I would also distinguish redaction from pseudonymisation and anonymisation. Replacing a name with a stable label can preserve links between records. It may be useful, but it does not by itself establish that re-identification is no longer possible.
Know what the detector supports
Pattern matching can work well for some structured identifiers. Names, free-form addresses, mixed languages and organisation-specific codes need different treatment.
A detector’s supported entity list is a starting point. I would test the formats and languages present in the actual material, including spacing variations, abbreviations and transcription errors. A general model may not recognise a local identifier or an internal reference number.
The input format also matters. If a tool analyses pasted text, it has not necessarily inspected an attachment’s metadata, comments, images or hidden document layers. An OCR step introduces another opportunity to miss or misread an identifier.
Redaction needs checks for missed identifiers, indirect clues and the final exported file.
flowchart TD
A["Define audience and sharing purpose"] --> B["Detect supported identifiers"]
B --> C["Redact or generalise"]
C --> D{"Identifiers or context still reveal a person?"}
D -->|Yes| C
D -->|Uncertain| E["Escalate for review"]
E --> C
D -->|No identified issue| F["Inspect actual export"]
F --> G{"Hidden content or metadata remains?"}
G -->|Yes| C
G -->|No identified issue| H["Authorised sharing decision"]
Measure misses and unnecessary removals
I would create a synthetic test set with known examples and mark the expected spans. Include ordinary sentences without personal data as well as difficult positive examples.
Then review false negatives and false positives separately. A missed account number may create a privacy problem. Excessive redaction can make a report useless or remove the context an investigator needs.
I would compare results across entity types rather than accept one overall accuracy number. A tool can perform well on email addresses and poorly on names while still producing an attractive average.
Review the output and the processing path
Before sharing sensitive material, I would inspect the final output for indirect identifiers and check the actual exported file. A coloured rectangle over visible text does not prove that the text was removed from the document underneath it.
I would also examine where the original input goes. A redaction service that sends source documents to logs, analytics or an external model creates a separate data-handling decision. Browser-based processing can reduce transmission, but that behaviour needs verification rather than a label.
For high-impact sharing, I would combine automated detection with a human review appropriate to the material. The tool’s useful contribution is finding likely sensitive spans consistently and showing what it changed. The decision to disclose the remaining information still depends on its content and context.