Synthetic Data Requires Evidence Before Reclassification

A synthetic dataset can look operationally separate from the sensitive records that produced it. Developers may receive generated customer records instead of production data, researchers may work with simulated populations, and an AI team may train or evaluate a model without handing downstream users the original dataset.

Governance still has to account for what happened before that separation. The source data was collected and processed, a generator learned from it, and new artifacts were produced from that process. In August 2026, a NIST workshop report recorded a clear warning from its PETs Testbed presentation: synthetic data alone does not adequately protect privacy unless the original data is also secured.

Synthetic generation can change the privacy characteristics of a dataset. Reclassifying the result is a separate decision, and that decision requires evidence.

Synthetic data consists of algorithmically generated records designed to reproduce useful characteristics of a source population. Its privacy status depends on more than the absence of original rows.

NIST SP 800-226 distinguishes conventional synthetic-data methods from differentially private synthetic data. Conventional methods generally offer informal privacy guarantees and can remain vulnerable to attacks that reveal information about their source. Differential privacy provides a formal mechanism for limiting the influence of individual records, with the strength of that protection determined by its parameters and implementation.

Legal classifications follow their own tests. Under HIPAA, for example, protected health information can qualify as de-identified through the Expert Determination or Safe Harbor methods. Under European data protection law, genuinely anonymous information can fall outside GDPR's personal-data scope, while pseudonymized information remains personal data.

Synthetic, anonymous, de-identified, and differentially private are different classifications and technical properties. Moving between them requires evidence.

How the Mechanism Works

The governance path can be represented as a lineage chain:

Source dataset → synthesis process → synthetic dataset → downstream use

Each stage creates a different question.

At the source: Why was the data collected, who can access it, how long can it be retained, and what deletion or contractual obligations apply?

During synthesis: Which source snapshot entered the pipeline? Which generator and code version processed it? Was differential privacy applied? What privacy testing occurred before release?

At the output: Can information about people in the source still be isolated, linked, or inferred?

That last question is where the distinction between generated and anonymous data becomes consequential. The DOMIAS study presented at AISTATS 2023 demonstrated membership-inference attacks against released synthetic datasets, with uncommon records particularly vulnerable. ICML 2025 research on LLM-generated synthetic text similarly showed that an attacker receiving generated outputs could infer information about records used to fine-tune the generator.

For a person represented by an unusual medical condition, transaction pattern, occupation, or other rare combination of attributes, this is the practical privacy stake: a dataset containing no literal copy of their record can still reveal that they were part of the source population or expose information associated with them.

Differential privacy provides a stronger technical boundary. It limits how much one person's participation can affect an output distribution and provides mechanisms for accounting for cumulative privacy loss across repeated analyses.

Privacy status can therefore change along the lineage chain. Reclassification is the point where an enterprise needs evidence that it has.

Analysis: Why This Matters Now

That evidence requirement is becoming more explicit in 2026.

NIST IR 8607, published in August, documented two relevant but separate discussions from its Cyber AI Profile workshop. The SSDF AI Profile presentation described tracking data and code to understand what happens from data collection through their use in AI training. In the subsequent PETs Testbed presentation, NIST recorded the conclusion that synthetic data alone provides inadequate privacy protection unless the original data is secured. These are workshop findings, not new binding NIST requirements.

In Europe, the EDPB adopted Guidelines 02/2026 on Anonymisation for public consultation in July. The draft, which remains open for feedback through October 30, 2026, organizes anonymity around three tests:

No Record Isolation: Can someone single out information associated with one person?

No Linkage: Can information in the released data be connected with information about the same person elsewhere?

No Inference: Can sensitive or identifying information about a person be derived from the data?

Those tests shift attention from how a dataset was produced to what an attacker or recipient can learn from it.

For enterprise governance, that changes the question a catalog entry needs to answer. is_synthetic: true describes provenance. It does not demonstrate anonymity.

The governance problem is moving from labeling the output to proving the transition.

Implications for Enterprises

A useful first control is to make that transition visible. Instead of recording only is_synthetic: true, a synthetic asset can carry: source_dataset_id, source_version, synthesis_job_id, generator_version, privacy_method, epsilon_delta, and, where applicable privacy_test_results, approved_purpose, release_scope, reassessment_date.

This creates an auditable path from a downstream AI workload back through the released dataset, generator, and source snapshot.

Classification policy can then operate on evidence. One workable internal rule is: synthetic datasets retain the source classification until an approved privacy assessment establishes a different classification under the applicable legal and organizational standard.

That assessment can combine membership inference, linkage, attribute inference, singling-out analysis, near-duplicate detection, and targeted testing of rare records. Differentially private releases should also retain their privacy parameters and cumulative privacy accounting where the same source population is used repeatedly.

The same lineage should drive deletion and incident response. When a source record is subject to erasure, teams need to identify affected generators and released derivatives and assess their current status. A genuinely anonymous derivative may fall outside GDPR's personal-data scope. A derivative that remains personal data continues to be governed as such. Under HIPAA, the corresponding question is whether health information satisfies the rule's de-identification standard.

This is where lineage becomes operational rather than documentary.

If privacy testing later finds that a supposedly low-risk synthetic release exposes rare records, the organization needs to know where that dataset went, which models consumed it, which source snapshot produced it, and what else was generated from the same pipeline. Without that graph, the problem becomes an incident-scoping problem.

Risks and Open Questions

Three unresolved boundaries matter most.

First, how much evidence is enough to reclassify a derivative? There is no universal synthetic-data privacy score. Membership inference, linkage, and rare-record exposure can produce different risk profiles even when aggregate utility and similarity metrics look acceptable.

Second, how should organizations account for multiple releases? Several synthetic datasets generated from the same population can create cumulative exposure. Differential privacy provides formal composition mechanisms for tracking that loss. Conventional synthesis requires cross-release risk assessment without an equivalent universal privacy accountant.

Third, how far does the lineage graph extend? The released table is only one possible derivative. Generator weights, checkpoints, intermediate files, logs, later synthetic versions, and models trained on those outputs can all become relevant to an investigation or governance decision.

Synthetic generation can justify broader access, different retention, or a new classification when the applicable technical and legal tests support that change.

Until then, provenance matters more than the label.

The control boundary should move when the evidence supports moving it. The presence of synthetic records is not that evidence.

Further Reading

• NIST IR 8607, Workshop Summary Report for the "Cyber AI Profile" Hybrid Workshop #2
• NIST SP 800-226, Guidelines for Evaluating Differential Privacy Guarantees
• EDPB, Guidelines 02/2026 on Anonymisation, draft guidelines under public consultation
• HHS, Guidance Regarding Methods for De-identification of Protected Health Information
• van Breugel et al., Membership Inference Attacks against Synthetic Data through Overfitting Detection
• Meeus et al., The Canary's Echo: Auditing Privacy Risks of LLM-Generated Synthetic Text