Privacy and preparation
Does de-identification reduce the value of business data?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
De-identification usually does not reduce the value of business data much, because AI developers license records for how work moves from request to decision to outcome, not for who the customers were. Value falls when preparation goes too far: outcomes deleted, threads broken by inconsistent placeholders, or text summarized away. Remove identities; keep the workflow.
Key takeaways
- Buyers of operational records want the workflow, the reasoning and the result; names and contact details add little to that.
- Over-redaction, inconsistent placeholders, summarization and aggregation are the preparation choices that cut value.
- Replacing identities with stable tokens keeps threads and linked records usable while removing who was involved.
- Whether data counts as de-identified under a given law is a separate legal question, assessed deal by deal with counsel.
Why removing identities usually keeps the value#
Removing identities usually keeps the value because the useful part of an operational record is the work it captures. A support ticket matters for how an agent diagnosed a fault and what fixed it; a dispatch record matters for the job type, the equipment, the technician's notes and whether a callback followed.
AI developers use records like these to train and evaluate systems that do similar work: resolving tickets, triaging requests, drafting quotes, reviewing code. A customer's name or phone number does not help a model learn any of that, and carrying it adds legal and reputational risk for both sides.
That is why careful preparation can remove personal details from support conversations, CRM histories, email threads and job records without removing the reasons a buyer wanted them.
What actually reduces value during preparation?#
Value drops when preparation removes or flattens the structure buyers pay attention to. The pattern holds across record types: the fewer decisions and outcomes survive, the less the dataset can teach.
Most of these choices are made for convenience, not out of legal necessity, which means a better alternative is usually available at modest extra effort.
| Preparation choice | Effect on value | Better alternative |
|---|---|---|
| Deleting names outright | Threads lose track of who said what | Consistent placeholders per person or account |
| A new tag for every mention | Linked records can no longer be joined | One stable token per entity across systems |
| Removing all numbers | Error codes, part numbers and quantities disappear | Target only identifying number patterns |
| Dropping timestamps | Sequence and response times are lost | Keep order; shift dates consistently if needed |
| Summarizing threads | Reasoning and wording replaced by a paraphrase | Keep original text with identifiers replaced |
| Excluding internal notes | The decision and its rationale vanish | Keep notes; scrub identifiers inside them |
| Aggregating to counts | Individual workflows can no longer be studied | Record-level data with identities removed |
Which records keep their value after de-identification?#
Records keep their value after de-identification when their substance is about the work rather than the person. Most operational records fit that description: the customer, agent or technician was incidental to a fault, an order exception or a repair.
Records that are about people, such as candidate files, HR cases or performance reviews, are the exception. Once the person is removed, little of the record is left, so they usually rank lower for licensing and often carry a heavier privacy burden as well.
| Record type | What carries the value | What gets removed |
|---|---|---|
| Support tickets and chats | Problem, diagnosis steps, fix, outcome | Customer and agent identities, contact details |
| Engineering issues and code reviews | Bug report, discussion, change, result | Developer names, credentials, customer identifiers |
| CRM histories | Deal stages, objections, decisions, timing | Contact names, emails, phone numbers |
| Job and dispatch records | Job type, equipment, notes, callbacks | Homeowner names, addresses, access notes |
| Quality and maintenance logs | Defect, root cause, corrective action | Operator names where they are not needed |
| Recruiting records | Little, once candidates are removed | Most of the record, which centers on a person |
Is de-identified data the same as anonymized data under the law?#
Not always: de-identified is a defined term in most US state privacy laws, while anonymized is often used loosely to describe a technique. California's definition, as amended by the CPRA, is a common reference point: the business must take reasonable measures so the data cannot be associated with a consumer or household, publicly commit to keep it in deidentified form and not try to re-identify it, and contractually require any recipient to comply too.
Other state laws use similar tests with differences in wording. Pseudonymized data, where names are swapped for tokens and the company keeps the key, may be treated differently from de-identified data depending on the law. Whether a specific dataset meets a specific law's standard may turn on the data, the controls and the contract, so it is assessed deal by deal with counsel.
Can you measure re-identification risk?#
Re-identification risk can be measured for structured fields with established metrics. Google's Sensitive Data Protection API, for example, offers k-anonymity, l-diversity, k-map estimation and delta-presence estimation, and notes that the last two rely on statistical models because the attacker's data is unknown.
Free text is harder. A support thread can mention a rare product configuration, a small town and a job title that together point to one person. For text, risk control comes from detection tools, human review of samples and coarsening rare details, such as a small town or an unusual job title, to a broader category.
Contract terms complete the picture. A license can prohibit re-identification attempts, restrict linking the data with other sources and require the buyer to report any identifying detail it finds, so technical and contractual controls work together.
Illustrative: an industrial distributor prepares order exception records#
Illustrative: a fictional industrial distributor keeps order history in Epicor and handles exceptions through a shared customer service inbox. Its CEO worries that removing customer identities will leave nothing worth licensing.
A first draft from an outside contractor summarized each email thread into a single line and removed customer company names. The review shows the summaries have lost the reasoning: why a substitute part was offered, who approved the credit, how the shipment was rerouted.
The second draft keeps the original text, replaces each customer and contact with a stable token across Epicor and the inbox, and keeps part numbers, carriers and outcomes. The CEO approves it: the dataset shows how exceptions were resolved without showing who the customers were.
Questions to ask before you approve a redaction plan#
Ask these questions before approving a redaction plan, whether it was prepared in-house, by a contractor or with a transaction partner.
- Does every record still show the request, the decision and the outcome?
- Is each person and account replaced by the same token everywhere it appears?
- Were technical terms, part numbers and error codes protected by an allow list?
- Was the original text kept, or replaced with summaries?
- Has someone read a sample for lost meaning as well as for missed personal details?
- Is the token mapping kept by the company and excluded from delivery?
How SourceX approaches de-identification and value#
SourceX assesses records with the SourceX Enterprise Data Value Framework before preparation choices are made, so everyone knows which fields carry the workflow and outcome. Preparation in the SourceX five-step transaction then removes personal and confidential details around those fields.
The privacy record in the SourceX Evidence Packet lists the methods used, such as redaction, pseudonymization or masking, and the supplier approves it. Industry provenance standards point the same way: the Data and Trust Alliance's Data Provenance Standards include an element for the privacy-enhancing technologies applied to a dataset.
Frequently asked questions
Will buyers ask for identified data instead?
For most operational records, no. Buyers generally want the work captured in the records and prefer not to receive personal data they would then have to protect. Some uses need specific attributes, such as region or industry, which can often be kept as coarse fields without identifying anyone.
Does de-identified data still need a rights review?
Yes. Removing personal details addresses privacy, but it does not settle whether you have the right to license the records. Customer contracts, confidentiality clauses, vendor terms and ownership of client deliverables still need review in the Rights step.
Can we de-identify the data ourselves?
Yes, and many companies prefer to keep raw records inside their own systems. Doing it in-house means owning the tool configuration, the token mapping and the review. Whoever does the work, document the method so a buyer can see what was removed and how.
Does de-identification change what the data is worth?
Done carefully, it mainly changes risk rather than substance. There is no fixed price list for business records; value becomes clear only once a buyer engages with a specific, documented package. Over-redaction is the preparation choice most likely to weaken that conversation.
Is aggregated data worth licensing?
Sometimes, for analytics uses, but aggregated counts rarely support training models that do the work themselves. Most AI buyers of operational records want record-level text and events with identities removed, because that is where decisions and outcomes are visible.
Should we keep dates and locations?
Keep them in a form that preserves meaning without pinpointing a person. Sequence and elapsed time usually matter more than exact dates, so consistent date shifting or month-level dates often work. Location can usually be kept at metro area, region or climate zone level, which still explains the work; small towns are worth coarsening further.
Sources
- Google's Sensitive Data Protection API offers four re-identification risk-analysis metrics: k-anonymity, l-diversity, k-map estimation and delta-presence estimation; k-map and delta-presence are estimated with statistical models because the attacker's dataset is unknown. Source
- The Use group of the Data and Trust Alliance Data Provenance Standards includes an element for privacy-enhancing technologies applied, alongside confidentiality classification, consent documentation location and license to use. Source
- Under Cal. Civ. Code 1798.140(m), as amended by the CPRA, deidentified information requires reasonable measures against association with a consumer or household, a public commitment not to reidentify, and contractual obligations on recipients. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.