Measuring Over-Redaction in a De-Identified Dataset

Why over-redaction is a quality defect, not a privacy win

Over-redaction is a quality defect because every false positive deletes signal the license was paid for, while adding nothing to privacy. When a detector tags the error code E-4471, the SKU HX-220-B or the product name "Atlas Pro" as [ID] or [ORG], a support transcript loses the exact tokens a fine-tuned model needs to resolve the ticket. A RAG index built on the same text can no longer answer "what does E-4471 mean."

Privacy and utility are separate axes. Benchmarks such as the Text Anonymization Benchmark (TAB) score anonymization with a recall measure for privacy and a separate precision measure for utility, precisely because one accuracy number hides the trade-off [2]. Your privacy engineer owns recall (what was missed); this page covers the other half. For recall testing, see how to measure what PII redaction pipelines miss.

Over-redaction also hides itself. A delivery with 9% of tokens masked looks "thorough" in a summary report, and nobody notices until an SFT run produces answers full of [NUMBER] or an NER evaluation set has its gold entities replaced by placeholders.

Where over-redaction comes from in operational text

Most over-redaction in operational data comes from a small number of predictable detector behaviors. Regex and pattern recognizers for phone numbers, account numbers and IDs match any digit run of the right length, so part numbers, order numbers, firmware versions and ticket IDs get caught. Named-entity models tag capitalized product names, internal tool names and team names as PERSON or ORG.

Address recognizers are another source. A business address or a warehouse location is usually not personal data about a customer, but detectors trained on consumer text tag it as LOCATION or ADDRESS. In health data the line moves: HIPAA Safe Harbor lists identifiers of the individual or of relatives, employers or household members, so an employer name inside a patient note is a legitimate removal [4] [5].

Configuration choices compound this. Curation toolkits such as NVIDIA NeMo Curator let operators choose which entity types to detect and whether to redact or replace them [6]; a supplier that enables every available entity type with a low confidence threshold will trade precision for recall. One study on educational records reports low precision for general-purpose detectors and roughly threefold higher precision from a fine-tuned model [1]. Evaluations of LLM-based redactors show a similar precision and leakage trade-off across model architectures and training strategies [3].

Typical over-redaction targets in support, engineering and finance records:

• Product, model and feature names tagged as PERSON or ORG
• Part numbers, SKUs, error codes, build numbers and stack-trace hashes tagged as ID or NUMBER
• Business addresses, store numbers and data-center locations tagged as LOCATION
• Dates on system events (deploy times, invoice due dates) removed when only dates tied to individuals needed treatment
• Agent names that were already pseudonymized upstream, redacted a second time

What you need from the supplier before you can measure

You need a redaction manifest, because surrogate replacement makes false positives invisible without one. If the supplier replaced "Dana Ortiz" with "Mark Ellison," and also replaced "Atlas Pro" with "Beacon Max," you cannot tell from the text which spans were touched. Masked placeholders like [PERSON_3] are easier to find but still lose the original entity type when labels are coarse.

Ask for a span-level manifest that records, per redacted span, the record ID, field, character offsets in the delivered text, detected entity type, detector or rule name, confidence score and the operator applied (mask, replace, hash, drop). It should not contain original values. With it, you can sample spans and compute token shares without seeing any personal data.

The original text stays with the supplier. That means a false-positive judgment is made in one of two ways: buyer-side reviewers judge from context and the manifest (a span tagged PERSON in "restart the [PERSON] service" is almost certainly a false positive), or the supplier's reviewers adjudicate sampled spans against originals under its own controls and return labels only. The second is more accurate; the first is often enough to find systematic errors. For the wider document set to request, see the de-identification evidence package checklist.

The redaction precision audit, step by step

The audit is a stratified sample of redacted spans, double-labeled, scored per stratum. A practical sequence:

1. Profile first. From the manifest, compute redacted tokens divided by total tokens, broken down by entity type and by field (for example ticket_body, agent_notes, subject, resolution_code). Flag any field where the share is far above the others.
2. Stratify. Sample per entity type and per field, not uniformly. Uniform sampling spends most of the budget on PERSON spans in free text and misses a small field where every token was masked.
3. Size the sample. About 200 spans per major entity type gives a usable estimate; report a Wilson confidence interval with each precision figure so a stratum of 30 spans is not over-read.
4. Label twice. Two reviewers mark each span true_pii, false_positive or unsure, with a reason code (product_name, part_number, business_address, system_date, other). Resolve disagreements and track agreement, using the methods in inter-annotator agreement metrics.
5. Score. Precision = true PII / (true PII + false positives), excluding unsure, which you report separately. Over-redaction rate = 1 minus precision.
6. Estimate token loss. Multiply each stratum's false-positive rate by its redacted token count to estimate wrongly removed tokens per field.
7. Check the precision vs recall trade-off. If the supplier uses confidence scores, plot precision by score band. A threshold change that removes most false positives may cost little recall, and that is the proposal to bring to the privacy engineer.

Treat recall as a hard constraint and precision as the thing you optimize. Never ask a supplier to loosen redaction in a way that reduces recall on real identifiers; ask for allowlists, field-specific rules or a better detector instead.

Illustrative audit record and summary table

The two artifacts below are what a completed audit should produce: one labeled record per sampled span, and a per-stratum summary that goes into the supplier findings.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "audit_id": "redact-audit-2026-10",
  "record_id": "tkt_000418",
  "field": "ticket_body",
  "span_offsets": [212, 220],
  "delivered_text_window": "...firmware [ID_7] fails on boot after...",
  "detected_type": "ID",
  "detector_rule": "regex_account_number",
  "confidence": 0.61,
  "operator": "mask",
  "reviewer_a": "false_positive",
  "reviewer_b": "false_positive",
  "reason_code": "part_number",
  "adjudicated_by_supplier": true
}

Illustrative example: invented to show structure; it does not describe an available dataset.

Read the table by token loss, not by precision alone. The DATE row has middling precision but the largest redacted share, so it removes the most useful text; the ID row is the most fixable, because part numbers follow a pattern an allowlist can exempt.

How to report findings to the supplier

Report over-redaction as a specific, reproducible defect with examples, a proposed fix and a re-test plan. A supplier's privacy team will not relax a pipeline on a general complaint, and should not.

Illustrative example: invented to show structure; it does not describe an available dataset.

Set the acceptance threshold before re-processing, the way you would in acceptance sampling for dataset deliveries. For how masking and surrogate replacement differ in what they preserve, see PII masking vs surrogate replacement and the broader training data quality assessment hub.

Limits of the measurement in regulated data

The audit measures utility loss; it does not certify de-identification and cannot override it. In health data, a span that looks like over-redaction may be a required removal under Safe Harbor, or a judgment made in an Expert Determination [4] [5]. Changes there go back through the expert or the covered entity's process, not through a buyer request.

Two other limits matter. Context-only buyer judgments miss false positives that look plausible as personal data, so treat buyer-side precision as an upper bound unless the supplier adjudicated against originals. And lowering redaction raises re-identification risk, so any agreed change should be checked against the test in LLM-assisted re-identification of de-identified text.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

How SourceX handles de-identified operational data

SourceX sources operational datasets from US companies on request, including support and sales histories, engineering records and documents. Personal details such as names, emails, phones and account numbers are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect. Health records require HIPAA de-identification by Safe Harbor or Expert Determination. Diligence materials covering source, rights, preparation and allowed use are prepared per dataset. Read how personal details are removed, or see the glossary entries for redaction and data anonymization. AI teams can describe the de-identified data they need.

Sourcing de-identified data you can audit for over-redaction

If your team needs de-identified operational text with its preparation method recorded, describe the data, fields and intended use rather than specific businesses. SourceX looks for US businesses that hold it, and every release is approved by the supplying company; a request does not guarantee a match. Start a data request at sourcex.si/buyers.