A redacted support ticket can still point to one person. Here is how data leaders should test de-identification before business records are licensed for AI.
- Why unstructured data breaks field-level thinking
- Privacy and utility pull in opposite directions
- Five questions to ask about any de-identification report
- Trace one record from source to output
- What a licensing process should add on top
- Technical de-identification standards for unstructured data
- Sources
- Frequently Asked Questions
- Why is removing names and direct identifiers insufficient for de-identifying unstructured data?
- How can data teams preserve analytical utility while protecting privacy in unstructured text?
- What questions should teams ask when auditing a de-identification report?
- What must be verified alongside technical de-identification before licensing business records?
De-identifying unstructured records requires reviewing whole threads and linked cases, not just stripping names, because rare job titles, locations, dates, and incident details can still identify a person. This applies to data teams preparing support, CRM, or clinical records for AI licensing. The trade-off is deliberate transformation—relative dates, consistent placeholders, banded amounts—that preserves analytical value without creating unwanted links across records.
In unstructured records, the identifying detail often hides inside an ordinary sentence.
Here is a support ticket after a standard redaction pass:
“[NAME] from the Duluth warehouse again. Since I took over as the only night supervisor in April, the scanner has failed every Tuesday.”
Every name, email address, and phone number is gone. In this illustrative scenario, anyone who knows the company could still tell you who wrote it.
That gap between a clean-looking record and a genuinely de-identified one is one of the hardest problems in preparing unstructured business data for AI. In our view, it also creates a commercial challenge when AI developers look to licensed company records, because de-identification quality decides whether a dataset is safe to share at all, and whether it’s still worth using once prepared.
- Contextual clues defeat field-level redaction: Rare job titles, locations, and dates inside free text can identify a person even after names and emails are stripped.
- Transformations must match the AI task: Relative date intervals and consistent placeholders preserve utility for evaluation without leaving raw personal details exposed.
- Audit the pipeline beyond a single score: Ask the five report questions covering denominators, review bias, high-risk sampling, error classification, and scope leakage.
- Trace records and verify licensing rights: Follow test cases end to end from source to output, and run contract and rights checks alongside technical preparation.
Why unstructured data breaks field-level thinking
Structured exports are comparatively friendly. A CRM table has an email column, and you can drop it. A support thread doesn’t cooperate. Those same details turn up in signatures, forwarded messages, quoted replies, pasted log lines, and screenshot descriptions. Internal chat adds nicknames, in-jokes, and references that only make sense when joined to another system.
Pattern matching catches some of this. It can’t catch everything that makes a person identifiable: a rare job title, an unusual incident, a small location, a precise date, or the combination of all four. The useful unit of review is often a whole thread or a linked set of cases, not a single field. According to Datavant’s analysis of clinical data, most traditional de-identification programs were built for structured records, which make up only 10% to 20% of health data. Security visibility across file and ticket repositories shows a similar gap: a Thales data security study found that only 35% of surveyed organizations report full visibility into where their unstructured data resides, while 56% have only partial visibility across distributed cloud and SaaS systems.
In fact, a majority of data (80% to 90%, according to multiple analyst estimates) is unstructured information like text, video, audio, web server logs, social media, and more. That’s a huge untapped resource with the potential to create competitive advantage for companies that figure out how to use it.
Tam Harbert in Tapping the power of unstructured data | MIT SloanNIST SP 800-188 specifically addresses government agency datasets, framing de-identification as a mix of technical methods and governance that includes an assessment of disclosure risk against the intended release.[1] Though written for government datasets, the lesson travels well for enterprise big data teams: a transformation is only as good as the review process built around it and the context where the output will be used.
Privacy and utility pull in opposite directions
Suppose the goal is an illustrative collection that tests whether an AI agent can apply a refund policy correctly. Strip every product reference, amount, and date, and the cases become unreadable. Keep everything because it feels realistic, and sensitive context survives. Neither extreme produces a usable dataset.
Good preparation makes deliberate trade-offs. Precise dates can become relative intervals that preserve the order of events. Consistent placeholder identifiers let a reader follow one customer through a thread without learning who they are. Amounts can be banded. Each choice should trace back to the permitted use, because the same consistency that helps a reader follow a case in one collection could create an unwanted link across records in another.
The UK ICO draws an important line here in its guidance on anonymisation and pseudonymisation. Pseudonymised data, where identifiers are replaced with artificial tokens or keys but could still be restored or linked back to an individual using additional information, remains personal data under UK data protection law.[2] Replacing names with tokens is a step, not a finish line.
Five questions to ask about any de-identification report
A single impressive accuracy figure tells you very little. When a vendor, an internal team, or a data partner presents results, ask the following.
What was the denominator? In practice, counting detected entities, all labeled entities, affected records, and complete threads will produce very different numbers.
Who checked the output, and did they review only the items the system had already flagged?
Which source types and information categories were tested, and were rare, high-risk records such as incident reports sampled on purpose?
How were errors classified, so that a missed identifier is distinguished from an unnecessary removal of useful content?
Did excluded material stay excluded? Quoted messages can drag in records from outside the agreed date range, and attachments can slip into an export meant only for message text.
A team that answers those questions clearly understands its analytics pipeline. A team that offers only a green status light probably doesn’t.
Trace one record from source to output
A revealing practitioner exercise is also a simple one. Take an approved test case and follow it end to end: from the scoped source system, through each transformation, to the final record. Note what was removed, what was generalized and why, and what a careful reader can still infer. Use material approved for testing instead of circulating a sensitive original to prove that its replacement looks safer.
When an error turns up, scope it properly. A missed detail in a quoted email may be copied across many threads in a repository. Record where it appeared, why it matters, how far the follow-up review extended, and whether the correction reached every affected output.
What a licensing process should add on top
De-identification solves only part of the problem. A cleanly prepared collection can still fall outside the supplier’s rights to license it because of customer contracts, vendor terms, or the original purpose of collection. Rights review has to run alongside the technical work.
SourceX, which licenses business data directly from companies for AI training and evaluation, states in its published process that it builds both into its workflow.[3] According to the supplier’s documentation, the supplier decides which systems, records, and date ranges are in scope, while a rights review checks that the company owns the records and can license them. Under its stated process, data is de-identified through approved processing routes before it’s used or shared, and a diligence packet documents source, rights, preparation, and permitted use. Large datasets can stay in the supplier’s own storage or ship on encrypted drives.
In its trust center documentation, the company is also direct about limits. It notes that no de-identification method is perfect, and the supplier agreement records that re-identification may still be possible. According to SourceX, its stated controls include organization-level access, private storage with short-lived links, a full audit trail, and terms locked per deal, while SOC 2 Type II, ISO/IEC 27001, and ISO/IEC 27701 are listed as in progress and not yet issued. That kind of plain statement is what a data leader should expect from any partner.
Technical de-identification standards for unstructured data
Evaluating unstructured de-identification requires technical verification across three areas: defined data scope, contextual disclosure review, and validation against the intended AI task. Teams should verify how surrounding clues were assessed and ensure the output withstands end-to-end review before deployment or licensing.
For data leaders whose companies hold years of support, CRM, or engineering records, that discipline can also support a potential licensing opportunity when terms permit. A company can check its fit with SourceX in a few quick questions, with no uploads and no commitment, and keep every record inside the business until the scope and terms are clear.
Sources
1. NIST SP 800-188: De-Identifying Government Datasets
2. UK ICO guidance on pseudonymisation
3. SourceX trust center
Frequently Asked Questions
Why is removing names and direct identifiers insufficient for de-identifying unstructured data?
Removing names and direct identifiers is insufficient for de-identifying unstructured data because contextual clues like rare job titles, small locations, precise dates, and unusual incident details can still identify a person. In free text, identifying details hide inside ordinary sentences and across whole threads or linked cases. Pattern matching drops explicit fields, but combinations of surrounding details defeat field-level redaction.
How can data teams preserve analytical utility while protecting privacy in unstructured text?
Data teams can preserve analytical utility while protecting privacy in unstructured text by applying deliberate transformations rather than extreme stripping. Precise dates become relative intervals to preserve the sequence of events, and consistent placeholder identifiers allow tracking a customer through a thread without revealing their identity. Banded amounts also protect details, ensuring transformations match the intended AI task and permitted use.
What questions should teams ask when auditing a de-identification report?
When auditing a de-identification report, teams should ask five specific questions about the pipeline rather than relying on a single score. They should ask what was the denominator, who checked the output and whether they reviewed unflagged items, which source types and high-risk categories were sampled, how errors were classified, and whether excluded material stayed excluded.
What must be verified alongside technical de-identification before licensing business records?
Before licensing business records, contract and licensing rights must be verified alongside technical de-identification. Teams must confirm customer contracts and vendor terms permit the transfer, and verify the company owns the records for the intended purpose. A diligence packet should document source, rights, preparation, and permitted use alongside approved processing routes.
