Is synthetic data personal data under GDPR?

It can be. Recital 26 says data is anonymous only if no one can identify a person using all the means reasonably likely to be used. The EDPB's draft anonymisation guidelines name synthetic data as a case where inferences about a real person can still be drawn.

What is a re-identification risk assessment for synthetic data?

A written test of whether someone could single out a real person in the source data, link the synthetic set to other data about them, or infer something new about them. The EDPB's draft calls these No Record Isolation, No Linkage and No Inference.

Does my ROPA need to include synthetic data generation?

Yes, if the source data was personal data. Generating synthetic data from it is processing, so it needs an Article 30 record with the purpose, data categories, recipients and erasure time limits, like any other processing.

What does California AB 2013 require for synthetic data?

Developers of generative AI made available to Californians must post training data documentation, including whether the system used or continuously uses synthetic data generation in its development. Describing why it was used is optional.

Does the EU AI Act address synthetic training data?

Indirectly. High-risk providers must document data origin and preparation steps, and under Article 4a they may process special category data for bias correction only when synthetic or anonymised data can't do the job.

When does using synthetic data actually reduce GDPR compliance burden?

When a documented assessment shows the output is anonymous. Then sharing it with a testing vendor, keeping it after the source data's retention period ends, or giving it to developers falls outside GDPR. The source data processing still needs its own record and lawful basis.

Synthetic data and GDPR: what to document in 2026

Image: Unsplash.

Synthetic data looks like a way out of privacy law: train and test on records that resemble your users without being your users. Sometimes it is. But GDPR doesn't care what you call the dataset. It cares whether a real person can still be identified from it, and that's a test you have to run and write down.

Our short answer: treat synthetic data as personal data until a written re-identification assessment says otherwise. Below is what that assessment checks, what goes in your records either way, and the two other laws that ask about synthetic data directly.

Recital 26 of the GDPR sets the test. To decide whether someone is identifiable, "account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person." Cost, time and the technology available count too. Data that passes is anonymous, and GDPR doesn't apply to it. Data that fails is personal data, whatever the generation method.

The European Data Protection Board has applied that test to AI twice. Its December 2024 opinion on AI models says a model counts as anonymous only if it's very unlikely that people whose data trained it can be identified, or their data extracted through queries, and that this is for regulators to judge case by case. Then in July 2026 it adopted draft Guidelines 02/2026 on Anonymisation, open for public comment until October 30. They set three criteria: No Record Isolation, No Linkage and No Inference. If data passes all three, it "can be safely considered anonymous."

The draft names synthetic data outright. Data that captures correlations rather than the records themselves can still leak, and "this would, in particular, be the case for AI models or synthetic data." Query it with what you already know about someone, and you may learn something new about them. That breaks No Inference.

Page 25 of the EDPB's draft Guidelines 02/2026 on Anonymisation: paragraphs on membership inference and inferred linkage, ending with paragraph 82, which says such inferences can be drawn from AI models or synthetic data

Screenshot: Guidelines 02/2026 on Anonymisation, version 1.0 (draft for consultation), European Data Protection Board.

In practice, three things move the risk:

How the generator was trained. Differential privacy is, in NIST's words, "a mathematical framework that quantifies privacy loss" when someone's data is in a dataset. A generator trained with it gives you a number to put in the assessment. A plain GAN or variational autoencoder gives you no such bound.
How small and unusual the source is. A few hundred patients from one clinic is a different risk from a national survey. Outliers in a small source tend to come back out of the generator looking much like themselves.
Who gets the output. The Recital 26 test counts means available to "another person," not only you. A dataset kept in-house carries less risk than one sent to a vendor or published.

If you want a lawyer's walk-through of the draft guidelines and what they mean for AI training data, Giulio Coraggio of DLA Piper covers them in this episode of his Legal Break series:

The source data doesn't get a pass

Even if the synthetic output turns out to be anonymous, the steps that produced it aren't. If the source data is personal data:

Collecting and keeping it is processing, and needs a lawful basis under Article 6.
Training a generator on it is processing too.
Both belong in your record of processing activities.

Deleting the originals once you have a synthetic copy doesn't erase what came before. The processing happened, it needed a basis, and it should be on file. The EDPB's 2024 opinion makes the same point about models: if one was developed with unlawfully processed personal data, that can affect whether it may lawfully be deployed, "unless the model has been duly anonymised."

What goes in the ROPA

Article 30(1) lists what a controller's record must contain. For a synthetic data run built from personal data, that means:

the purpose (model development, vendor testing, research)
the categories of data subjects and of personal data in the source
the recipients, including anyone outside the EU
the time limits for erasing the source data
a general description of your security measures

Article 30 doesn't ask for the lawful basis or the re-identification result, but we'd put both in the same entry, or link to them. When someone asks why a synthetic set left GDPR's scope, that's where the answer should be.

Run a DPIA first if the source processing is "likely to result in a high risk" to people's rights, which is the Article 35 trigger. Article 35(3) names large-scale processing of special category data, such as health records, as a case that always needs one.

If the assessment shows the output is anonymous, you don't need a ROPA entry for using or sharing it. You still need the entries for the source processing.

California AB 2013: one yes-or-no question

California Civil Code section 3111, added by AB 2013, applies to developers of generative AI systems or services made publicly available to Californians, paid or free, released on or after January 1, 2022. They had to post training data documentation on their website by January 1, 2026, and again before each new release or substantial modification.

On synthetic data, the law asks one thing: "whether the generative artificial intelligence system or service used or continuously uses synthetic data generation in its development." A developer "may" add why. It doesn't ask for the share of training data that was synthetic, the generation method, or whether the seed data was personal. Other items in the same list do ask whether the datasets include personal information and whether they were cleaned or modified.

California AB 2013 bill text, Civil Code section 3111: the list of required training data disclosures, from sources and owners of datasets to item 12 on synthetic data generation

Screenshot: AB 2013 (chaptered text), California Legislative Information.

Two limits matter for small teams. It covers generative AI only, so a fraud model trained on synthetic transactions isn't in scope. And it's separate from GDPR: an anonymous synthetic set still gets disclosed under item 12.

EU AI Act: documentation, and one place synthetic data is named

For high-risk systems, Article 10(2) requires data governance covering, among other things, "data collection processes and the origin of data" and preparation steps "such as annotation, labelling, cleaning, updating, enrichment and aggregation." Annex IV, point 2(d), asks the technical documentation to describe training data sets, "their provenance, scope and main characteristics," how the data was obtained and selected, and cleaning methods.

Neither provision mentions synthetic data or augmentation by name. But if part of your training set was generated, that's where its origin and the generation step get described. A record that names only the real dataset leaves out where some of the training data came from.

Synthetic data is named in one place. The Digital Omnibus moved the rule on processing sensitive data for bias detection into a new Article 4a. A provider may do it only if, among other conditions, the job "cannot be effectively fulfilled by processing other data, including synthetic or anonymised data," and the ROPA records why.

EUR-Lex text of Regulation (EU) 2026/1744 inserting Article 4a into the AI Act: special categories of personal data may be processed for bias detection only if synthetic or anonymised data can't do the job

Screenshot: Regulation (EU) 2026/1744, Article 1, point (6), EUR-Lex.

So if you plan to use health or ethnicity data to test a high-risk system for bias, first write down why a synthetic version wouldn't work.

Checklist: synthetic data for AI training

Before you generate

Decide whether the source data is personal data, and write the answer down
If it is, record the lawful basis for using it this way
Add a ROPA entry for the generation run
Check whether the source processing needs a DPIA under Article 35
Pick the generation method with the risk in mind; note whether it uses differential privacy and with what parameters
Write down who will get the output

After you generate

Test the output against No Record Isolation, No Linkage and No Inference, including queries a recipient could run
Record the method, the result and who signed off
If the result is anonymous, keep the assessment with the dataset
If it isn't, treat the output as personal data and add a ROPA entry for its use
Before sharing with a vendor, decide from the result whether you need a processing agreement
If the system is generative AI available to Californians, answer item 12 on your AB 2013 page

If the system is high-risk under the EU AI Act

Describe the generated share of the training set and how it was made in the Annex IV documentation
If you'll process special category data for bias testing, record why synthetic or anonymised data wasn't enough

When synthetic data actually saves work

It helps when the assessment passes:

Vendor testing. Sending an anonymous synthetic set instead of customer records means no personal data goes to the vendor for that work, so no processing agreement or transfer mechanism is needed for it.
Keeping patterns after deletion. When the source data's retention period ends, an anonymous synthetic copy can keep the statistical value without keeping anyone's data.
Developer access. Developers can build against realistic data without access to production records.

It doesn't help when:

The source data had no lawful basis. Generating from it doesn't fix that.
The assessment fails. Then you've added another processing activity, not removed one.
Downstream users could mistake synthetic rows for real people's records and act on them.

Our take

Synthetic data is a privacy tool, not a legal category. The EDPB's draft is the clearest signal yet that regulators will ask how you know the output is anonymous, and that "it's synthetic" isn't an answer. The good news is that the work is the same everywhere: one assessment, one ROPA entry, one line on your AB 2013 page. Do it once per dataset and keep it with the data.

Correction, October 15, 2026: an earlier version said AB 2013 requires disclosure of the synthetic share of training data, the generation method and whether the seed data was personal; the law asks only whether synthetic data generation was used. It also described AB 2013 as covering AI "offered for sale or lease"; it covers generative AI made publicly available to Californians, paid or free. It said Annex IV requires documenting "data augmentation techniques"; neither Annex IV nor Article 10 uses that phrase. And it misquoted Recital 26 of the GDPR. All four are fixed above.