A redaction pass answers whether a document still contains identifiers. The control question is whether this content may go to that destination for that purpose, and a scrubber has no way to evaluate it.
Somewhere in the last year, "PII redaction before egress" became a standard line item in AI control catalogs. I see it on gateway proposals, in vendor questionnaires, and in the control mappings customers send me before a diligence call. It sits under data handling with a green checkmark next to it, credited with work nobody confirmed it can do. A scrubber tells you a document no longer matches a set of detectors. It does not tell you whether the content is permitted to go where it is going. Those are different questions, and only the second one is a control.
I run security and DevOps for a fintech platform serving more than 1,500 financial institutions, so I sit on both sides of this. I answer the questionnaire and I write the control. What convinced me the line item is misfiled was not an incident. It was reading the regulatory text redaction is supposed to satisfy and noticing a pattern: every regulator who published a list of identifiers to strip also published the clause explaining why stripping them is not sufficient.
Minimization has no meaning until somebody names the purpose
Start with the sentence everyone cites. GDPR Article 5 (opens in new tab) requires personal data to be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed. Read the tail of it. Necessary in relation to the purposes. The principle immediately above it, Article 5(1)(b), requires those purposes to be "specified, explicit and legitimate" in the first place. Minimization is not an absolute quantity you can measure inside a file. It is a ratio, and the denominator is a purpose somebody declared.
So a scrub that runs before anyone declares a purpose is executing a control whose predicate was never evaluated. The gateway has no idea whether a counterparty's identity is incidental decoration or the entire point of the request. Remove that name from a contract and you have helped, if the question is whether the termination clause is unusual. You have destroyed the work if the question is whether we have a conflict. Same document, same scrub, opposite verdicts. The detector has no way to know which situation it is in.
The inverse is more common and worse. A price, a date, and a named institution are exactly what a commercial-terms comparison needs, and exactly what should never leave the building for a routine formatting cleanup. The scrub decides what to remove; the purpose decides what is allowed to remain. Run them in that order and you have inverted the control.
Everyone who published a list of identifiers also published the clause admitting the list is not enough
The mental model people carry into AI redaction comes from HIPAA, whether they know it or not. Under 45 CFR 164.514 (opens in new tab), the Safe Harbor method at (b)(2) lists eighteen categories of identifiers, from names and geographic subdivisions to device identifiers and biometrics, and says remove them. That is the closest thing in US law to "scrub it and you are clear."
Except that (b)(2) has a second half almost nobody quotes. 164.514(b)(2)(ii) also requires that the covered entity "does not have actual knowledge that the information could be used alone or in combination with other information to identify an individual who is a subject of the information." The list is not the test. The list, plus the absence of knowledge sitting in your own head, is the test. Notice who holds that knowledge. Not the tool.
Safe Harbor is also only one of two permitted methods. The other, at (b)(1), requires a person with appropriate statistical and scientific expertise to determine that the re-identification risk is very small, and to document the methods and results. Same legal outcome, reached through a risk assessment with a named human attached to it. A regulator who believed identifier removal was sufficient on its own would not have needed the second method or the second clause. Both exist because the drafters understood that a document's safety depends on facts outside the document.
Sensitivity is a property of what the recipient already knows
NIST is blunter about it. SP 800-188 (opens in new tab), published in September 2023, states that "the ability to re-identify depends on vulnerabilities such as the original dataset, the de-identification technique, and the availability of additional data (publicly available or privately held) that can be linked with the de-identified data, as well as specific threats, such as the technical skill of the data intruder and the intruder's available resources and motivation." It adds that the true probability of re-identification likely increases over time, as techniques improve and more contextual information becomes available.
Read that list as an architect. The de-identification technique is one item out of six, and the only one that is a property of the file. Everything else is a property of the recipient, the recipient's other data, the recipient's motivation, and the calendar. A document does not have a safety rating. A pairing of document and destination has one, and it decays. "We scanned it and it came back clean" is not a fact about the document. It is a fact about the scanner, on that day.
This is the mirror image of an error I have written about before. When I argued that "we don't train on your data" answers the wrong question, the point was to interrogate where the payload travels and where it rests rather than what the model learns. Redaction fails the same way from the other direction: the pledge answers the wrong leg of data governance, the scrubber answers the wrong object. Both let you feel finished without ever naming the destination.
The categories that would actually end my week are contextual, not lexical
Detectors find things shaped like identifiers. That is a hard engineering problem and the good tools are respectable at it. It is also not the exposure profile of a regulated platform.
The maintainers of Presidio (opens in new tab), the open-source PII detection engine that a great many redaction pipelines are built on, say so in their own documentation: "because it is using automated detection mechanisms, there is no guarantee that Presidio will find all sensitive information." That disclaimer belongs in every control mapping that claims redaction as the data-handling control. Every commercial gateway I have evaluated wraps the same class of technique, and none has arrived with a measured recall figure against our own documents. I ask. I get a product name and a list of supported entity types.
Now the part no detector will ever reach. Strip every name-shaped token out of a partnership document and you can still be left with a top-twenty institution in a named region, a member count, a go-live quarter, and a price. Nothing in that description is an identifier. All of it is material nonpublic information, and anyone who follows the sector can resolve it over lunch. Internal deal code names are the cleanest case, because a code name is engineered to look like ordinary vocabulary. It survives every scan by construction, which is the entire reason it exists. The most sensitive fact in a regulated shop is frequently not a string inside the document. It is the inference the document licenses. And any reduction that keeps a document useful for a question tends to keep it disclosive about the same subject, because those are frequently the same features.
The clean copy is a new asset your classification scheme has never met
The second failure is quieter, and it surfaces in audits rather than incidents. The scrubber produces a file. That file is a derivative of a classified source and it carries no label. Your scheme has a row for the original and nothing for the child. Nobody scheduled its retention, nobody owns it, and its provenance is a filename.
It is also lighter than it looks, in a way that misleads reviewers. Rebuilding a document to remove identifiers commonly drops comments, tracked changes, embedded metadata, and external relationships along the way. The output looks tidier, and reviewers read tidiness as safety. What actually happened is that the record of who objected to which clause got deleted alongside the phone numbers, and the reviewer is reading a cleaner artifact with less evidence in it.
Then it travels. A copy cleaned for one question becomes a general permission slip that follows the document into every later question, because it is sitting on somebody's desktop and it already has "redacted" in the filename. The authorization was granted for a question. The artifact outlives the question and carries no expiry. I have argued that agent memory is a data-residency problem because summaries and embeddings are retention nobody classified. A sanitized document is the same class of derived artifact. It is just one an auditor can open and read back to you.
None of this is credible without the ordinary plumbing underneath it. Privacy is an operations problem, and if you cannot answer where a copy went, the scrub is one step inside a workflow you cannot reconstruct. That is a worse position than having no scrubber at all, because now you have documented diligence you cannot evidence.
Write the control as a routing decision with the scan inside it
The fix is not to rip out redaction. It genuinely reduces blast radius and it belongs in the stack. The fix is to demote it from authorization to hygiene, and to build the authorization above it. Six changes, in the order I would make them.
- Bind the authorization to the request, not the file. Purpose, destination, and data class get declared at submit time and logged. The scan becomes a step inside that decision rather than a substitute for it.
- Make the derivative inherit. A sanitized copy carries the source classification until a named person downgrades it, and the downgrade records who, when, and for which question.
- Give the authorization an expiry tied to the question. A copy cleared for a termination-clause review is not cleared for a conflicts check. New question, new decision.
- Measure the misses, not the hits. Sample scrubbed output against your own corpus and count what got through. A detector with no measured recall against your documents is not a control, it is a vendor claim.
- Put the categories detectors cannot see into the request-time declaration. Deal code names, unannounced partnerships, privileged advice, institution-specific facts. The requester declares them, because the requester is the only party who knows.
- Log the tuple, not the file. Source, destination, purpose, actor, timestamp. That is the record that answers "where did this content go," and no amount of reading the clean copy will produce it.
Do the fourth one on Monday. Pull thirty documents of the kind you actually push through the gateway, run them, and read the output against the originals yourself. Count what survived. That number costs a morning, and until it exists nobody should be calling the scan a control.
This is tractable because it is a control shape you already run. When I wrote that you should govern the line rather than ban the tool, the argument was that what a thing touches decides its category, not the builder's intent. This is the same move applied to content instead of tooling. What a request is for, and where it is going, decides whether the content may move. Whether a detector happened to stay quiet decides nothing.
Some work needs a different room, not a lighter document
The last piece is the one people resist, and it is the one that makes the rest believable. There is a category of work where the sensitive facts are the reason the work has value at all. A complete patient history for a clinical review. A full transaction set for a fraud model evaluation. An entire deal file for a diligence question. No reduced copy answers the same question, and any copy that does answer it was not meaningfully reduced.
For that category, the destination has to change, not the document. Either an approved environment that can hold the full information under real controls, or no AI on that task this quarter. That answer is unwelcome in a room that just signed for a redaction gateway, and it is the only honest one available. In practice it is a small share of the work, which is why saying it costs so little. A policy claiming everything can be sanitized down to safe gets tested once by somebody with a real deadline, and after that nobody believes any of it.
So rename the line item. Not "PII redaction before egress" sitting under data handling as though it settled something. Something closer to what you actually run: purpose and destination authorization at the request layer, identifier reduction as a downstream hygiene step, and a documented category of work that does not get a reduced copy at all. That is a control an examiner can test, because it produces a decision record with a human name on it instead of a scan result with a checkmark.
I would like to hear how other teams are binding purpose at the request layer without it collapsing into a dropdown everyone clicks through on the way to the prompt box. And if anyone has a measured false-negative rate for their redaction step against their own document corpus, rather than a vendor's benchmark against somebody else's, I would like to see the methodology. Every time I have asked for that number, I have been handed a product name instead.