Selling to Labs

De-identification that survives counsel

Not legal advice

"We removed PII" is a claim with no evidentiary content. It says nothing about what was looked for, what fraction was found, where the search did not reach, or whether the remaining data still identifies people by combination. A buyer's privacy review is not asking whether you tried. It is asking for the measurements — and a seller who has them clears review in days rather than losing the deal in month two.

The claim you are actually making

There are three quite different claims, and sellers conflate them constantly:

Make the strongest claim you can actually evidence and no stronger. An overclaim discovered in diligence is worse than a modest claim stated precisely, because it recalibrates everything else you have said.

Where redaction actually fails

Structured fields are the easy part and are almost always handled. Every failure we see in intake is in one of these four places:

1. Free text. The note field, the comment, the transcript, the operator's narration. Names, locations, employers, relationships and dates appear in prose that no column-level policy touches. This is where the residue lives, and it is the first place a buyer looks.
2. Rare-value quasi-identifiers. Nothing in the record is an identifier, but the combination — a role, a region, a date, a rare condition or a rare transaction — narrows to one person. Redacting names does nothing about this.
3. Non-text payloads. Screenshots with a logged-in username in the corner, document metadata, EXIF, embedded file paths containing a home directory name, audio with someone saying their own name. Trajectory and computer-use corpora are dense with these.
4. Third parties. Your consent covers your users; the person your user is talking about never consented to anything. Buyers ask about this and sellers are routinely unprepared for the question.

The five measurements a buyer expects

1 · Detection recall on a labelled sample

Draw a random sample, have humans annotate every identifier in it, run your pipeline against the same sample, and report recall and precision per entity type. Recall is the number that matters; precision only tells you how much content you destroyed. Report it per type, because aggregate recall hides the fact that your detector finds emails perfectly and person-names poorly.

2 · A free-text sweep, reported separately

Report structured-field and free-text results as separate numbers. A pipeline with 0.99 recall on fields and 0.85 in prose has 0.85 recall as far as the buyer is concerned, and averaging the two conceals exactly the risk they are assessing.

3 · A held-out audit nobody tuned against

Keep a slice out of development entirely and audit it once, at the end. Any slice used to tune thresholds reports optimistic numbers. State the sample size and the confidence interval — a 200-record audit that finds zero residual identifiers is consistent with a residual rate above one per cent.

4 · A re-identification attempt

Name an attacker: someone with a voter roll, a professional register, a public social profile, or the organisation's own directory. Attempt to link records back. Report how many succeeded, and at what effort. This is the measurement that distinguishes de-identification from redaction, and almost nobody arrives with it.

5 · Uniqueness statistics on quasi-identifier combinations

Count records whose combination of quasi-identifiers is unique in the corpus, and unique in the population you drew from. Then say what you did about them: suppression, generalisation, or acceptance with a stated rationale. All three are defensible answers; silence is not.

What to retain, and for how long

• The detection configuration, versioned — patterns, models, thresholds, and which ran on which fields.
• The annotated evaluation sample, held securely, so the recall figure can be re-derived rather than believed.
• The audit report with its date, sample size and interval.
• The re-identification test: attacker model, auxiliary data used, method, outcome.
• The suppression log: what was removed or generalised and why — but never a mapping back to the original values in the same place as the delivered corpus.
• Sign-off from whoever is accountable for privacy in your organisation, dated before delivery rather than after the buyer asks.

Retention outlives the deal. If a question arises in two years, the evidence package is what answers it, and reconstructing it after the fact is not possible once the pipeline has changed.

The part sellers resist

Aggressive redaction damages the asset. Every name replaced by a token is a small loss of coherence, and a corpus scrubbed to the point of incoherence trains nothing.

This tension is real and the resolution is not to redact less. It is to replace rather than delete — consistent surrogate names, shifted but internally consistent dates, generalised locations — so the linguistic and logical structure survives while the identity does not. State the surrogacy scheme in the datasheet. A buyer who knows dates were shifted by a per-subject offset can still use temporal reasoning; one who finds [REDACTED] where a date should be cannot, and will assume the worst about the rest of the corpus.

Standards, thresholds and what counts as adequate vary by jurisdiction and by data type, and none of this is legal advice. What is portable is the principle: every claim in your privacy section should have a number and a method behind it.

Read next: Article 53 in one page for data owners — what your buyer has to publish, and therefore what they need from you.