De-identified data for AI training: a buyer's guide to privacy-safe licensed datasets

One label, three legal tests: HIPAA, GDPR and the CCPA

A dataset described as "de-identified" can pass one regime's test and fail another's, because HIPAA, the GDPR and the CCPA ask different questions about the same records. The table states each test as of October 2026.

In the EU, the Court of Justice held in EDPS v SRB (C-413/23 P, 4 September 2025) that sufficiently strong pseudonymisation can leave data personal for the controller holding the key but not for a recipient with no means to reverse it or identify people otherwise; the assessment is case by case [4]. As of September 2026, Digital Omnibus proposals to narrow the definition of personal data and to confirm legitimate interest for AI development were still proposals, not law [6].

In the UK, the ICO's anonymisation guidance (published March 2025; under review) recommends the "motivated intruder" test [7][8] and warns that re-identifying people from pseudonymised or ineffectively anonymised data can be a criminal offence [9]. Compare the four labels in de-identified, anonymised, pseudonymised and aggregated; SourceX's glossary defines data anonymization.

Sector and state rules that follow particular records

Some records carry rules that a general de-identification claim does not settle, so identify the source system and the people in it first.

• Education records. FERPA allows release without consent once all personally identifiable information is removed and the releaser reasonably determines, across multiple releases and other available information, that no student is identifiable [10] (FERPA guide).
• Financial records. Nonpublic personal information received under a Regulation P exception may be used only for the purpose it was received, even by a recipient that is not a financial institution [11]; ask counsel whether de-identified transactions still qualify (GLBA guide).
• Substance use disorder records. HHS's 2024 final rule aligned parts of 42 CFR Part 2 with HIPAA, with a compliance date of 16 February 2026 [12]; ask whether any records came from a Part 2 program (Part 2 records).
• Biometrics. Illinois' BIPA treats voiceprints and face geometry scans as biometric identifiers, requires a written release before collection and bars profiting from them [13]. Removing names does not help when the voice or face is the identifier (biometric data guide).
• Washington consumer health data. The My Health My Data Act counts inferences drawn from non-health data as consumer health data, and selling it needs a separate authorization that seller and purchaser must both keep for six years [14].

Why stripping identifiers does not make data anonymous

Removing names and account numbers leaves quasi-identifiers, such as dates, places, job titles and rare events, that outside data can link back to a person. Sweeney's k-anonymity requires each person to be indistinguishable from at least k-1 others on those attributes, and even then attacks can succeed when release policies are ignored [15]. Rocher et al. estimated with a generative model, not from actual re-identifications, that 99.98% of Americans would be correctly re-identified in any dataset using 15 demographic attributes, so releasing only a sample does not make data anonymous [16].

NIST documents real re-identification cases and notes that medical text, photographs and genetic data are harder to de-identify than tables [17]. SP 800-188 (2023) cautions about the limits of traditional methods compared with formal ones such as differential privacy [18]. Watch for indirect identifiers in business text and linkage risk when combining licensed sets; SourceX's explainer is de-identified data truly anonymous? gives the short version.

Where identifiers hide in text, audio, images and tables

The method has to match the modality, because identifiers sit in different places in a support ticket, a call recording, a video frame and a claims table. Test each type's weak point in a sample.

Privacy risk that carries into the trained model

Training can memorize personal data that survived de-identification, so the model itself can become the disclosure. Carlini et al. extracted hundreds of verbatim training sequences from GPT-2, including contact details, using only queries [23], and Nasr et al. (ICLR 2025) recovered thousands of training examples from aligned production models [24]. Alignment is not a privacy control.

A law-firm summary of EDPB Opinion 28/2024 (17 December 2024) reports that a model trained on personal data cannot be presumed anonymous; it is anonymous only if extracting personal data from it, directly or through queries, is insignificant [25] (EDPB Opinion 28/2024 for data buyers). In the US, the FTC's 2021 Everalbum order required deletion of models and algorithms built from users' photos and videos [26].

Residual personal data therefore decides whether you can ship weights or open a public API. Differential privacy bounds what any single record can reveal, usually at some cost in accuracy [18]; see memorization risk, differential privacy for LLM fine-tuning and releasing weights trained on personal data.

The privacy evidence to request before you sign

Ask for evidence that a named standard was met on this dataset, not a description of the supplier's general process.

1. Standard and jurisdiction. The regime claimed and where the data subjects live.
2. Method. Detector and version, entity types, masking or surrogate policy, date and location rules, and dropped fields.
3. Measured misses. Recall per entity type on a labeled sample from this dataset, with sample size and labeler.
4. Expert Determination report, if used. Methods, results, recipient assumptions and date [2]; HHS notes that because technology and information availability change over time, re-examination may be appropriate [1].
5. Key custody. Who holds any re-identification code or pseudonymisation key; HIPAA permits such codes only under stated conditions [2].
6. Residual risk. Quasi-identifiers left in and any re-identification test results; SP 800-188 recommends such studies and a disclosure review board [18].
7. Your obligations. No re-identification, no linkage, onward-transfer limits and a duty to report found personal data (re-identification prohibition clauses).
8. Source-side basis. Notice and consent records, and any Article 9 condition for special categories (consent and notice records).

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

dataset_id: support-tickets-r1
source_system: helpdesk export (ticket bodies and replies; attachments excluded)
standard_claimed: CCPA 1798.140(m) deidentified   # GDPR status: not claimed
data_subject_locations: [US-CA, US-TX, US-NY]
method:
  detection: NER model + regex rules (card numbers, SSNs)
  entity_types: [PERSON, EMAIL, PHONE, ACCOUNT_ID, STREET_ADDRESS, CARD_NUMBER]
  replacement: consistent surrogates within each ticket thread
  dates: shifted per customer; intervals preserved
  dropped_fields: [attachments, agent_email, ip_address]
qa_sample:
  records_reviewed: 2000
  labeling: two annotators, adjudicated
  recall_by_entity: {PERSON: 0.97, EMAIL: 1.00, PHONE: 0.99, ACCOUNT_ID: 0.95}
residual_risk_notes: product names and small-town names retained
reidentification_key: none retained by supplier
recipient_obligations: [no re-identification, no linkage to customer records, report found personal data]

For datasets sourced through SourceX, personal details such as names, emails, phone numbers and account numbers are removed or replaced before delivery, the method is recorded per dataset, and a sample is checked after processing; health records must meet HIPAA Safe Harbor or Expert Determination before a license is considered. Diligence materials on source, rights, preparation and allowed use are prepared per dataset. No method is perfect, so keep your own checks and describe the records and privacy standard you need. See the full de-identification evidence package checklist; suppliers can follow SourceX's playbook for de-identifying company data.

Controls that stay with the buyer after delivery

Supplier de-identification lowers risk at the source; your controls decide whether it stays low once the data meets other data and a model.

• Scan before training. Check inputs and context fields, not only targets (scanning a corpus before fine-tuning).
• Block linkage. Keep licensed sets out of joins with CRM data, logs or other licensed sets unless a fresh risk assessment covers the combination.
• Contain access. SP 800-188 lists protected, non-public enclaves among its data-sharing models [18]; train inside one where you can.
• Test the model. Run extraction probes or planted canary strings before any external release.
• Rehearse the incident. Agree how found personal data is quarantined, reported and deleted (response playbook).

What de-identification costs the model, and how to specify around it

Every method removes signal, so list the fields your model needs before choosing a standard. Safe Harbor removes all elements of dates tied to the person except the year and geographic units smaller than a state (three-digit ZIP codes for geographic units containing more than 20,000 people may be retained), and groups ages over 89 [2]. That can break a readmission or seasonal-demand model; Expert Determination has no fixed list, so an expert may allow more detail if the risk stays very small [1][2] (what Safe Harbor dates and ZIP codes cost).

In vision, a CVPR 2023 workshop study found that face-only anonymization of detection datasets caused a minimal accuracy drop, while traditional anonymization hurt noticeably, especially when whole bodies were masked [27] (blurring evidence). Privacy constraints also narrow coverage: a paper in Stanford's GRACE journal argues that de-identified health datasets used for foundation models are often outdated and demographically limited [28]. For high-risk systems, EU AI Act Article 10(3) requires data that is sufficiently representative of the people the system serves [29], so check coverage after de-identification; the compliance hub gives application dates as amended in 2026.

Start here: privacy guides by question

Each question below has its own guide.

For the rest of the purchase, start at the AI data buyer's hub.

Mistakes that turn a de-identified dataset into a liability

Most privacy failures in data deals come from trusting a label instead of the test behind it.

• Treating HIPAA de-identification as GDPR anonymisation. Safe Harbor answers a US question; any records in the same file that fall under the GDPR still face the Recital 26 test [3].
• Assuming pseudonymised data is non-personal for you. After EDPS v SRB the question is whether you could re-identify, including with data you already hold [4].
• Signing flow-down terms you cannot honor. Joining records to customer data puts the CCPA no-re-identification commitment at risk [5].

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

Sourcing data that contains personal information?

Describe the records you need, where the people in them are located, and the privacy standard your reviewers require. SourceX looks for US companies that hold that data, checks the data and the supplier's licensing permissions, and manages the license and delivery through private, access-controlled workflows. Share your data and privacy requirements.