Redacting Before the Call, and What Redaction Cannot Do
We removed the names, the addresses and the customer numbers before sending a support ticket to a hosted model, and a colleague reading the redacted version identified the customer from the remaining sentence in about ten seconds.
The Ten Seconds
The pipeline replaced every detected name, address, phone number and customer reference with a typed placeholder before the text left our infrastructure. On paper that is a clean data-minimisation story and it passed our own review.
Then someone read a redacted ticket aloud. It described a specific machine at a specific plant with a specific fault that had occurred twice before, and anyone who works with that account knows exactly who it is. The identifiers were gone and the identification was not.
Two Different Problems
Removing direct identifiers is a solved engineering problem, roughly. Removing the possibility of identification is not, because identification works from combinations, and the combination that identifies a business customer is often the technical content that makes the ticket worth processing at all.
We had conflated them, and the conflation is comfortable because the first one is measurable. You can count the names you caught. You cannot count the inferences a reader could make, which means a redaction metric can look excellent while the property you care about is untouched.
The Research That Frames It Correctly
Pilán and colleagues published work in late 2024 on text sanitisation guided by inference attacks, where the question is not only whether identifiers were removed but whether what remains still allows an adversary to infer the protected attribute, while keeping the sanitised text truthful.
That framing is the one we adopted. Sanitisation evaluated against what can be inferred is a much harder standard than sanitisation evaluated against a list of patterns, and it is the standard that corresponds to what a data protection officer actually means when they ask whether the data is personal.
| Measure | What it achieves |
|---|---|
| Remove names and numbers | Removes direct identifiers only |
| Generalise technical detail | Reduces inference, degrades the answer |
| Keep the data in our own infrastructure | Removes the question |
| Contractual controls with the provider | Legal, not technical. Both are needed |
What We Changed
We stopped presenting redaction as anonymisation. Internally and to customers, redacted data is pseudonymised data that has left our infrastructure, with all that follows from that, and we say so in the system document rather than implying a stronger property.
For the two customers where that was not acceptable, the pipeline stopped sending anything. Their classification and extraction run on a self-hosted model, which costs more and is the honest answer to a requirement that redaction cannot meet.
The Placeholder Detail That Mattered
Our first implementation replaced every entity with the same marker. That kept the answer safe and made it useless: a ticket mentioning three different people became three identical placeholders, and the model could no longer tell who was reported to have done what.
Typed and numbered placeholders fixed it. A first person, a second person, a first company. The text stays coherent, the relationships survive, and the answer can be mapped back on our side. It is a small implementation detail and it is the difference between a redaction step that works and one that quietly ruins the output.
What We Do Not Redact
Free-text descriptions of a fault, which is where the identifying combination usually lives. We tried generalising them and the answers degraded so far that the system stopped being useful, and a system that is useless is not a privacy improvement, it is a project that failed for a stated reason.
So the choice we present to customers is explicit: send the technical description to a hosted model as pseudonymised data, or run the step on infrastructure you control. We no longer offer a third option that sounds like both, because that option does not exist.
What We Log
Not the redacted text. Our traces store a reference to the original record and the placeholder mapping, so a support engineer can reconstruct what was sent without the trace itself becoming a second copy of customer data in a system with different access rules.
That was a finding from the same review. We had built a careful redaction step and then written the input and output to a log with a ninety-day retention and broader access than the source system, which undid a fair amount of the care.
What We Do Not Claim
We do not claim our redaction anonymises anything. It removes direct identifiers, it reduces exposure, and under the standard that matters it is pseudonymisation. Claiming otherwise would be the kind of statement a customer could rely on to their cost.
We also do not claim self-hosting settles the question. It changes who processes the data and leaves the rest of the obligations in place, including the ones about what the system may infer and how long anything is kept.