Synthetic data still needs a privacy argument

Synthetic data can reduce the need to expose original records, but the label “synthetic” is not a privacy conclusion. Before a French organisation shares or uses a generated dataset, it needs an evidence-based account of where the source data came from, how the synthetic output was produced, what disclosure risks were assessed and what the release permits.

CNIL's AI development guidance, dated 5 January 2026, recognises synthetic data as a possible safeguard while explicitly warning that they are not systematically anonymous. The guidance discusses legitimate interests and safeguards; it does not declare every synthetic dataset exempt from the GDPR. The French original prevails over the courtesy English translation.

A demonstration of a software form may need only a few deliberately invented records. Testing analytical behaviour may require more realistic distributions. These are different purposes with different evidence needs. Describe the intended task before choosing a generation method or copying a production database into a new tool.

Ask which properties must be retained for the test and which should deliberately be absent. A field included merely because it appears in the source system may add risk without making the test more useful. Document exclusions so a later user does not assume the data support an analysis that was never assessed.

Generating a new dataset does not erase the earlier processing of personal information. Keep the source-data access, tool permissions, provider arrangements and retention decisions within the organisation's approved process. A privacy specialist should determine the applicable legal basis and assessment requirements; a synthetic-data supplier's marketing statement is not that determination.

An original release record can connect four questions: the source and permissions; the generation method and version; the tests appropriate to the expected disclosure risk; and the intended recipients and uses. Retain the decision maker and any unresolved limitation alongside the output's identifier.

Test design should be selected by competent privacy and technical reviewers. Relevant concerns may include reproduction of source records, exposure of unusual combinations or what an informed recipient could infer using other information. A check for exact duplicates alone cannot answer every such question. Nor does a visually realistic table establish that the statistical relationships are useful for the intended task.

Avoid publishing a universal “safe similarity” score. The meaning of a test depends on its assumptions, reference data and likely recipient. Preserve those assumptions with the result. Where a risk has not been assessed, describe it as unassessed instead of turning absence of evidence into a pass.

A dataset can be less revealing and still unsuitable for an analysis. Conversely, a dataset that reproduces useful patterns may need tighter release restrictions. Ask reviewers to state both conclusions separately: what the recipient may do with the data, and which analytical uses are supported by validation.

For a hypothetical software demonstration, manually invented customer names and deliberately fictional transactions might be enough to show a screen's behaviour. They would not support a claim about real customer churn. Label such records as fictional and keep them separate from a model-generated dataset derived from real customers. This is an illustration of purpose limitation, not a measured privacy test.

The article on redaction and data minimisation addresses another practical control. Redaction, pseudonymisation and synthetic generation should not be treated as interchangeable guarantees; each needs an assessment appropriate to the actual information and use.

Consider a fictional team asking to release a generated dataset for a dashboard demonstration. A duplicate-record check found no exact copies of the reference records, but no wider disclosure-risk assessment or analytical validation has been completed. This is an invented example, not a measured result.

Under the stated facts, the release record should keep anonymity and analytical suitability unconfirmed. A format demonstration is not evidence for either conclusion.

For a limited screen demonstration, the team could instead prepare clearly fictional records from scratch, avoiding a real-customer source altogether. Label their purpose and excluded uses. That choice does not retroactively settle how an earlier production-derived dataset was processed.

A useful handover records the file version, origin, permitted purpose, recipient restrictions, actual checks and outstanding review. CNIL's warning that synthetic data are not automatically anonymous remains the starting point; there is no invented numerical privacy threshold in this example.

Record who can receive the file, whether onward sharing is allowed, which uses are excluded and when review is needed. A controlled internal test and publication for unrestricted download create different exposure conditions. Cross-border sharing also requires assessment of applicable transfer and recipient arrangements where personal data are involved; “synthetic” is not a shortcut around that question.

Revisit the assessment when the source population, generation model, fields, recipients or purpose changes. Preserve earlier versions so a reviewer can identify which decision covered which release. If the required evidence is missing, use clearly fictional test records for a limited demonstration or hold the release while the assessment is completed.

The useful outcome is a bounded, reviewable release decision. It should explain why this dataset is appropriate for this use, rather than promising that generated data are always anonymous.

AI assistance was used in research and drafting. No client engagement, firsthand test or independently verified outcome is claimed.

This article is general information. Verify current requirements and seek qualified advice for your specific circumstances.

Spotted an issue? Contact our editorial desk.