TL;DR: Synthetic data is not automatically GDPR-exempt. The test is re-identification risk under Recital 26. If source data was personal, you need a re-identification risk assessment, a ROPA entry, and documentation of the generation methodology. California AB 2013 requires disclosure of synthetic data use. EU AI Act Annex IV requires training data documentation that includes synthetic data characteristics.
The appeal of synthetic data for AI development is obvious. If you can generate statistically realistic data that preserves the properties of your actual user dataset without containing any real user records, you solve a major compliance problem: you can train, test, and share datasets without triggering GDPR, CCPA, or sector-specific data regulations.
The problem is that this is not automatically true. Whether synthetic data is personal data under GDPR depends on a legal and technical assessment that many teams skip. In 2026, with GDPR enforcement authorities and national AI regulators paying closer attention to AI training data, the assumption that synthetic means anonymous is not a safe one.
This guide covers the legal framework, the technical conditions that matter, and what you need to document.
What synthetic data is, and what it is not
Synthetic data is data generated by a computational process, typically a generative model trained on real data, designed to preserve statistical properties of the source data without directly copying individual records. The output looks like real data: it has the right distributions, correlations, and patterns. But no specific row in the synthetic dataset corresponds to a specific real person.
At least, that is the intent. Whether it achieves anonymization in the legal sense is a different question.
It is worth distinguishing synthetic data from related concepts. Data masking replaces real values with pseudonyms or scrambled values while preserving the underlying record structure: it is pseudonymization, not anonymization, and it is clearly personal data under GDPR. Tokenization replaces sensitive fields with tokens while retaining a mapping: also pseudonymization. Aggregation combines individual records into group statistics: the aggregated output may or may not be personal data depending on group size and re-identification risk.
Synthetic data generated by a properly calibrated generative model is the strongest candidate for genuine anonymization. But "properly calibrated" does most of the work in that sentence.
The GDPR question: is synthetic data personal data?
GDPR Article 4(1) defines personal data as any information relating to an identified or identifiable natural person. The anonymization exception in Recital 26 says that personal data that has been rendered anonymous in such a manner that the data subject is not identifiable no longer falls within the scope of GDPR.
The standard for anonymization is whether the data subject is identifiable by "any means reasonably likely to be used, taking into account all the means reasonably likely to be used by the controller or by any other person." This is a risk-based standard, not a categorical one. It requires assessment of the available means and probability of re-identification.
For synthetic data, the analysis turns on three questions:
1. Does the synthetic generation process constitute true anonymization?
Generative models trained on personal data learn patterns from individual records. Depending on the model architecture, training data size, and generation method, the synthetic output may be more or less likely to leak information about specific individuals. Differentially private generation methods provide a mathematical bound on this leakage. Standard generative adversarial networks or variational autoencoders do not.
2. What are the available means for re-identification?
Available means in 2026 include model inversion attacks (recovering training data from model outputs), membership inference attacks (determining whether a specific record was in the training set), and linkage attacks (combining synthetic data with other available datasets to re-identify individuals). The question is not whether these attacks are possible in theory but whether they are reasonably likely given who will have access to the synthetic data and what other information they could combine with it.
3. What is the probability of re-identification in practice?
For a large, diverse dataset with differential privacy applied, the re-identification probability may be genuinely negligible. For a small dataset (say, 500 patients from a specific clinic) generated with a standard GAN, the re-identification risk may be substantial because any outlier records in the source data will tend to be reproduced or closely approximated in the synthetic output.
The practical conclusion: synthetic data from large, diverse datasets with differential privacy applied is the strongest candidate for GDPR anonymization. Synthetic data from small datasets or generated without formal privacy guarantees requires a careful re-identification risk assessment before being treated as outside GDPR scope.
The role of the source data
Even if you conclude that the synthetic output is genuinely anonymous and therefore outside GDPR scope, the process of generating it is not. If the source data is personal data, then:
- Collecting or retaining that source data is processing under GDPR and requires a lawful basis.
- Training a generative model on personal data is processing under GDPR.
- Both of these activities must appear in your ROPA.
The synthetic generation process does not erase the compliance obligations that attached to the source data. It creates an output that may itself be outside GDPR scope, but the journey to that output runs through activities that are squarely within GDPR.
This is a common misunderstanding. Teams sometimes assume that once they have synthetic data, they can delete the original personal data and the compliance slate is clean. The original processing still happened, still required a lawful basis, and should still be documented.
GDPR Article 30 and the ROPA
Article 30 requires controllers to maintain a record of processing activities. If you are generating synthetic data from personal data, the ROPA should include:
- The purpose of the synthetic data generation (e.g., AI model development, third-party testing, research)
- The lawful basis for processing the source personal data (consent, legitimate interests, or another basis under Article 6)
- Categories of data subjects and data types in the source dataset
- Recipients of the synthetic dataset, including third parties
- Retention periods for both the source data and the synthetic output
- The re-identification risk assessment result (with a reference to the full document)
- Whether a Data Protection Impact Assessment (DPIA) was conducted (required if the source processing was high-risk)
If you conclude that the synthetic output is fully anonymous and outside GDPR scope, you do not need a ROPA entry for sharing or using the synthetic data. But you do need the ROPA entries for the source data processing that preceded it.
California AB 2013
California AB 2013, which took effect on January 1, 2026, creates a transparency obligation for developers of AI systems trained on data and offered for sale or lease in California. Covered developers must publicly post a summary of the training data used for each AI system.
The required summary must include, if applicable:
- Whether the training data included synthetic data
- What percentage or proportion of the training data was synthetic
- The general methodology used to generate the synthetic data (e.g., GAN, diffusion model, differential privacy technique)
- Whether the synthetic data was generated from real personal data
This applies to AI systems offered commercially in California, which includes most consumer and enterprise software products. The disclosure goes on a public web page, not just in vendor contracts.
For teams building AI products that may be offered in California, AB 2013 adds a documentation obligation that is separate from GDPR. Even if your synthetic data passes the GDPR anonymization test, you still need to disclose its use under AB 2013.
EU AI Act and training data documentation
For high-risk AI systems under the EU AI Act, Article 10 and Annex IV establish requirements for training data documentation. Annex IV Section 2 requires technical documentation to include:
- The training, validation, and testing datasets used
- Relevant characteristics of the datasets, including provenance, scope, and main characteristics
- Data collection methodologies and data augmentation techniques
Synthetic data generation is a data augmentation technique. Providers of high-risk AI systems (and deployers who develop their own systems) must document the synthetic data generation methodology as part of Annex IV compliance.
National market surveillance authorities can request this documentation during conformity assessments. If your documentation simply says "training data: [dataset name]" without addressing synthetic augmentation, that is an incomplete Annex IV record.
Governance checklist for synthetic data use
Use this checklist when your team generates or uses synthetic data for AI training:
Before generating synthetic data
- Identify the source data and confirm it is personal data or not
- If personal data: confirm the lawful basis for using it for synthetic generation
- Add a ROPA entry for the synthetic generation activity
- Determine whether a DPIA is required (required if source processing is high-risk under Article 35)
- Select a generation methodology appropriate to the re-identification risk context
- Document the intended use of the synthetic output and who will have access
After generating synthetic data
- Complete a re-identification risk assessment for the synthetic output
- Document the assessment methodology and conclusion
- If re-identification risk is negligible: document the basis for this conclusion and retain it
- If re-identification risk is not negligible: treat the synthetic data as personal data and add a ROPA entry for its use
- If sharing with third parties: confirm whether a DPA is required based on the re-identification risk conclusion
- If the AI system may be offered in California: prepare the AB 2013 training data disclosure
For high-risk AI systems under the EU AI Act
- Include synthetic data generation methodology in the Annex IV technical documentation
- Document the proportion of the training dataset that was synthetic
- Include the re-identification risk assessment result in the training data documentation
When synthetic data reduces compliance burden, and when it does not
Synthetic data genuinely reduces GDPR compliance burden in these scenarios:
- Third-party testing and development: If you share synthetic data (that passes the re-identification test) instead of actual customer data, you eliminate the need for a DPA, a data transfer mechanism, and vendor data processing controls for that activity.
- Retention after the original data period expires: If you need to retain analytical patterns but the retention period for the underlying personal data has expired, properly anonymized synthetic data can preserve the statistical utility without retaining personal data.
- Development without production access: Developers can work with realistic data without needing access to production systems containing actual personal data, reducing access control and logging obligations.
Synthetic data does not reduce compliance burden when:
- The source data was personal data and was processed without a clear lawful basis. Generating synthetic data from unlawfully obtained personal data does not cure the underlying Article 6 violation.
- The re-identification risk is not negligible. In this case the synthetic data is personal data, and you have simply added another processing activity to your ROPA.
- The generation methodology itself creates new risks, for example by producing outputs that could be confused with real individuals' records by downstream users.
The governance principle is straightforward: synthetic data is a powerful tool, but it requires the same documentation rigor as any other privacy-by-design technique. The work is in the assessment, not in the label.
Related reading
- AI data privacy for small teams, GDPR and CCPA
- GDPR Article 30 AI tools record of processing activities template
- California AB 2013 AI training data transparency
- EU AI Act Annex III high-risk AI systems
- EU AI Act high-risk AI documentation templates
- Privacy-first AI APIs, no training clause, GDPR and CCPA
- AI governance for small teams, complete guide
- AI Agent Memory and GDPR: How to Handle Persistent Context Without a Com
- GDPR AI fines 2026: enforcement cases and what small teams must know
- GDPR Article 22 and AI Tools: What Automated Decision-Making Rules Mean
