Is synthetic data personal information under CCPA?

It depends entirely on how it was produced. Data generated from a statistical specification with no real consumer records involved is not personal information — there is no consumer it relates to. Data sampled from a generative model that was fitted on real customer records is a harder case: CCPA defines personal information as anything that identifies, relates to, describes or is reasonably capable of being linked with a particular consumer or household, and a synthetic record that reproduces or closely approximates a real one can meet that definition. The label 'synthetic' is not a legal status; the generation process is what determines it.

What does CCPA actually require for data to count as de-identified?

Section 1798.140(m) sets a three-part test, and only the first part is technical. The information must not reasonably be capable of being associated with, or linked to, a consumer. Beyond that, the business must take reasonable measures to ensure the information cannot be re-associated, publicly commit to maintaining and using it only in de-identified form and never attempting to re-identify it, and contractually obligate any recipient to the same terms. A perfectly anonymised dataset held without those governance commitments does not meet the statutory definition.

Can a generative model leak the real records it was trained on?

Yes, and it is a well-documented failure mode rather than an edge case. Generative models overfit on rare records — the outlier customer with an unusual combination of attributes is exactly the one most likely to be reproduced near-verbatim in sampled output, because the model had few examples to generalise from. Membership inference attacks can also determine whether a specific individual was in the training set from the model's outputs alone. Both mean a synthetic dataset can carry linkage back to identifiable people even when no field was copied directly.

Does differential privacy solve the CCPA problem?

It is the strongest available technical answer to the first prong and does nothing for the other two. A formal differential privacy guarantee with a tight, documented epsilon gives you a defensible argument that outputs are not reasonably linkable to any individual. But CCPA still requires the public commitment not to re-identify and the contractual flow-down to recipients. Employ differential privacy for the technical claim; do not treat it as a complete compliance answer, and be honest internally about the epsilon you actually shipped rather than the one in the design doc.

If we generate synthetic data from customer records, do we still have to honour deletion requests?

You must honour the request for the underlying records, which is straightforward. Whether the request reaches the synthetic dataset and the generator model depends on whether they qualify as de-identified. If they do, they fall outside the definition of personal information and outside the deletion right. If they do not — because the generator memorised outliers or the synthetic set is linkable — then a deletion request logically extends to them, and you face the same machine-unlearning infeasibility problem that applies to any trained model. The practical posture is to document the de-identification analysis before the deletion request arrives, not after.

Home / Blog / CCPA, Synthetic Data and De-Identification

"It's Synthetic" Is an Engineering Claim, Not a Legal One

Synthetic data has become the standard answer to every privacy objection raised during AI development. Need production-like data in a dev environment? Generate it. Want to share a dataset with a vendor? Synthesise it. Worried about training on customer records? Train the generator once, then train everything else on its output. The pitch is that the privacy problem is solved at the source, and the resulting dataset is outside the regulation entirely.

CCPA does not have a synthetic-data exemption. It has a de-identification standard with three prongs, two of which are governance obligations that no generation technique can satisfy — and a first prong that a generative model fitted on real records can fail in ways that are invisible unless you test for them.

The distinction that matters: synthetic data generated from a specification (schema, distributions, business rules) never touched a consumer and is genuinely out of scope. Synthetic data sampled from a model fitted on real customer records is derived from personal information, and its status depends on whether it clears the statutory de-identification test. Most enterprise "synthetic data" is the second kind.

The three-prong test, and why two of them surprise engineers

CCPA as amended defines de-identified information at section 1798.140(m). Read operationally, it requires all of the following:

Prong 1 — Not reasonably linkable

The information cannot reasonably be used to infer information about, or otherwise be linked to, a particular consumer. This is the technical prong and the only one most teams evaluate. Note the phrasing: it covers inference about a consumer, not merely identification of one. A synthetic dataset that allows an attacker to conclude something about a real individual can fail this even without naming them.

Prong 2 — Reasonable measures plus a public commitment

The business must take reasonable measures to prevent re-association and must publicly commit to maintaining and using the information only in de-identified form, with no attempt at re-identification. "Publicly commit" means something visible — a privacy policy statement — not an internal runbook. This prong is failed by omission at a large share of companies that believe they hold de-identified data.

Prong 3 — Contractual flow-down

Any recipient must be contractually obligated to the same restrictions. If you hand a synthetic dataset to an analytics vendor, a model-training partner or an offshore development team under a generic MSA with no de-identification clause, the exemption claim weakens at the moment of transfer — which is usually the exact moment the dataset was created for.

The structure is deliberate. The legislature treated de-identification as an ongoing commitment about how a business behaves, not as a property a dataset possesses. That is why a technically excellent anonymisation pipeline with no corresponding policy language and no vendor clauses still leaves you holding personal information as a matter of statute.

How generative pipelines fail prong one

Four failure modes account for most of the real-world risk, and none of them are visible in a summary-statistics comparison of the synthetic set against the source.

Outlier memorisation. Generative models generalise where they have density and memorise where they do not. The customer with a rare combination of ZIP code, age band, product mix and transaction size is precisely the record most likely to reappear near-verbatim in output. Privacy risk in synthetic data is concentrated exactly where the population is thinnest.
Membership inference. Even without record reproduction, an adversary can often determine whether a specific person was in the training set by observing how confidently the model handles their attributes. Knowing someone was in a dataset of, say, high-risk borrowers is itself an inference about that person.
Quasi-identifier survival. Synthetic generation preserves joint distributions — that is the point. It therefore preserves the combinations that make individuals unique. The classic result that a small number of demographic fields uniquely identifies most of a population does not stop applying because the rows were resampled.
Auxiliary-data linkage. Linkage attacks combine the released dataset with outside information. The relevant question is not whether your synthetic set is identifiable in isolation but whether it is identifiable when joined against a data broker file, a public voter roll or a breach corpus.

Aggregate consumer information is a separate, narrower category

CCPA also excludes "aggregate consumer information" — data about a group from which individual identities have been removed and that is not linkable to any consumer or household. Row-level synthetic data is not aggregate information, even though teams frequently invoke the aggregate exclusion for it. If your output has one row per synthetic individual, you are making a de-identification claim, not an aggregation claim, and the three-prong test applies.

Does the generator model itself become regulated?

This is the question most synthetic-data programmes never ask, and it has real consequences. The generator was fitted on personal information. If it can be probed to recover training records — through prompting, membership inference or model-inversion techniques — then the model weights are reasonably capable of being linked to consumers, and the same analysis that applies to the synthetic output applies to the artifact that produces it.

Practically, that means the generator belongs in your data inventory as a regulated asset: documented provenance, an access model, a retention decision, and a position on what happens when a consumer whose data was in the training set exercises deletion rights. Teams that treat the generator as tooling rather than as data discover this gap during a diligence review or a regulator inquiry, at which point the honest answer is that nobody knows what is in it.

A defensible synthetic-data posture

Classify the generation method up front. Specification-driven or model-fitted. Record the answer per dataset. Only the second kind needs the rest of this list, and conflating them wastes effort on the datasets that were never in scope.
Prefer a formal privacy guarantee. Train the generator under differential privacy with a documented epsilon and delta. A formal bound is far easier to defend than a post-hoc similarity check, and it is the only approach that constrains attacks you did not think to test.
Run adversarial privacy testing, not similarity metrics. Nearest-neighbour distance to source records, membership inference AUC, and attribute inference on held-out individuals. Set pass thresholds before you run the tests and record failures as well as passes.
Sample-audit the tails. Pull the rarest synthetic records and manually compare them against the source population. This is where verbatim reproduction lives and where an automated aggregate metric will not find it.
Write the public commitment. Add explicit de-identification language to the privacy policy stating that the business maintains such data in de-identified form and does not attempt re-identification. Prong two is unsatisfiable without it.
Paper every recipient. A de-identified data clause in every agreement covering transfer of the synthetic set — including internal transfers to affiliates and contractor agreements.
Inventory the generator. Treat model weights fitted on consumer data as a regulated asset with the same catalogue entry, retention schedule and access controls as the source table.
Re-test on drift. Regenerating with new source data, a new architecture or a looser privacy budget invalidates the prior assessment. Tie the privacy test to the pipeline, not to a one-time sign-off.

Frequently Asked Questions

Our vendor certifies their synthetic data as privacy-safe. Is that enough?

Vendor certification addresses prong one at best, and it addresses it on the vendor's terms. Ask what the guarantee actually is: a formal differential privacy bound with a stated epsilon, or a similarity heuristic. Ask whether they tested membership inference, and on which population. Then note that prongs two and three are obligations on you, not on them — the vendor cannot make your public commitment or paper your downstream recipients.

Can we use synthetic customer data in a development environment without CCPA obligations?

If it clears the three-prong test, yes, and this is one of the strongest use cases for synthetic data because the recipients are internal and easy to bind contractually. The common failure is scope creep: the dev dataset gets copied into an analytics workspace, then shared with a contractor, then used to train a production model, and the controls that supported the original claim do not travel with it. Bind the dataset, not the environment.

Is de-identified data the same as anonymised data under GDPR?

No, and mapping one to the other causes real errors. GDPR anonymisation is an absolute standard — genuinely anonymous data falls outside the regulation entirely, with no ongoing obligations. CCPA de-identification is a conditional status maintained through commitments and contracts, and de-identified data remains subject to those conditions. Data can be validly de-identified under CCPA and still be personal data under GDPR.

What happens if someone re-identifies our synthetic dataset?

Successful re-identification is evidence that prong one was never met, which retroactively undermines the exemption for the entire period you relied on it — including any disclosures made on the assumption that the data was out of scope. This is why the documented pre-release privacy testing matters so much: it is the record showing the linkability assessment was reasonable at the time, which is the standard the statute sets.

Do the CPPA's ADMT and risk-assessment regulations apply to synthetic data pipelines?

The risk-assessment requirement is triggered by processing that presents significant risk to consumer privacy, and training a generative model on consumer records is a strong candidate. If the resulting system feeds automated decision-making about consumers, the ADMT obligations attach to that use regardless of the synthetic intermediate step. Synthesising the training data does not launder the downstream decision out of scope.

The claim is only as good as the record behind it

Every synthetic-data programme eventually gets asked to prove the exemption — by an enterprise buyer's security review, an acquirer's diligence team, or a regulator. The organisations that answer well are not the ones with the best generator. They are the ones that wrote down the generation method, ran adversarial privacy tests before release, published the commitment, and papered the recipients.

Do that work while the dataset is being built. Reconstructing it afterwards, for a pipeline that has already shipped to four downstream consumers, is a much worse project.