Synthetic data generation (privacy & training data)

Real data is often locked away by GDPR, banking secrecy or simple scarcity, which blocks software testing, analytics sharing and ML training. Generative models learn the structure of a source dataset and emit new records that keep its statistics but map to no real person. Done well, this unlocks data access in days instead of months; done carelessly, it only creates a false sense of anonymity.

Problem & value

• Today: developers test with copies of production data (a compliance risk) or hand-made dummy data (unrealistic). Data-sharing with partners, universities or cloud teams needs lengthy approvals. ML teams lack examples of rare events (fraud, defects, rare diseases).
• AI value: faster, lower-risk access to realistic data; balancing of rare classes; reproducible test sets of any size; data for demos and training.
• Evidence base: vendors cite large speed-ups in data provisioning, but no independent, uniform benchmark exists. Treat quoted ROI figures as vendor claims and measure your own baseline (time-to-data-access, test coverage, model uplift).
• Key caveat: synthetic is not automatically anonymous. Similarity-based privacy metrics can miss attacks on "truly anonymous" synthetic datasets [6], and the Article 29 Working Party criteria (singling out, linkability, inference) still apply [1].

Variants

• Tabular / relational (core): customer, transaction or patient tables with referential integrity across tables.
• Software test data: rule-based and model-based generators for databases, APIs and CI pipelines (masking plus generation).
• Time series and sequences: sensor, ECG or payment histories.
• Text: LLM-generated synthetic documents, dialogues, support tickets or clinical notes, often seeded from personas, then PII-scanned; also instruction data for fine-tuning (see DATA-023, LANG-027).
• Images and video: simulation and generative imagery for vision training (see VIS-030 for the anonymisation side).
• Private use: rare; mainly hobbyists generating dummy data for learning and demos.

How it works

1. source data (restricted environment)
2. profiling + schema/constraint capture
3. generator training (GAN / VAE / diffusion / transformer / copula / LLM, optionally with differential privacy)
4. sampling (+ business-rule and constraint enforcement)
5. evaluation: fidelity (distributions, correlations), utility (train-on-synthetic, test-on-real), privacy (nearest-neighbour, membership inference, attribute inference)
6. human / DPO release decision
7. synthetic dataset delivered to the wider organisation

• Generators: statistical models (Gaussian copula, CTGAN, TVAE in the SDV library), autoregressive transformer models for relational data (MOSTLY AI), differentially-private fine-tuning for text and tabular data, and prompted LLMs for text.
• Privacy controls: differential privacy (DP) gives a formal guarantee at a utility cost; empirical tests (membership inference, distance-to-closest-record) are complementary, not a substitute.
• Human-in-the-loop: a data-protection officer or data steward signs off on the privacy report before release; domain experts check realism and edge cases.

Data preparation

The source is typically relational data from ERP, CRM, HR or core systems, plus exports in file shares and Excel sheets. Text corpora (tickets, mails) sit in mail servers and DMS. Typical gaps: undocumented schemas, missing foreign keys between exports, inconsistent codes and duplicates, free-text fields with hidden personal data, and no clear owner who may release the data.

Preparation steps: 1. Inventory candidate tables and agree an owner per source (PREP-001, PREP-004). 2. Extract a consistent snapshot via exports or connectors (PREP-005) and clean it into tidy tables (PREP-011). 3. Document schema, constraints and business rules (valid ranges, referential integrity); these become generator constraints. 4. Check purpose and legal basis for using real data to train the generator (PREP-025) and pseudonymise direct identifiers first (PREP-022). 5. Keep a held-out real test set for the utility check.

Tools: pandas or dbt for cleaning, SDV or MOSTLY AI for generation. Rough share of effort: about 40 to 50 percent, because the generator is only as good as the cleaned, constrained input. See also DATA-003 and DATA-023.

Implementation paths

Which path for whom

• smb: Path C. Source data is usually personal or confidential, and open-source generators such as SDV run on HW2 so real records never leave the company; use an external partner for the first run.
• enterprise: Path C. Banking, insurance and health data are sensitive and a shared internal platform amortises the effort; commercial generators (Path A) fit once a vendor is approved.
• developer: Path C. Open-source libraries give full control over constraints and privacy tests, and cost nothing per record.
• public: Path C. Citizen data must stay in sovereign infrastructure, and procurement favours open, auditable tools.

Path A — Buy (off-the-shelf)

• EU: MOSTLY AI (Vienna; commercial platform plus open-source SDK), Syntheticus (Switzerland), Aindo (Italy), Statice (Germany; acquired by Anonos, check current availability), Clearbox AI (Italy).
• Non-EU: Tonic.ai, Hazy (software assets acquired by SAS, Nov 2024), NVIDIA (which reportedly acquired Gretel in March 2025; the standalone Gretel service has been folded into NVIDIA offerings, check current status) [4], Synthesis AI for images, K2view for entity-based test data.
• Choose A when: regulated data (banking, health), no in-house ML team, need audit-ready privacy reports and connectors to databases and warehouses.

Path B — Build on cloud APIs

• Text: frontier LLMs (Claude, Gemini, GPT, Mistral via EU regions) prompted with schemas and personas; use structured outputs for consistent JSON; always run a PII/leak scan. Never send real personal records to non-EU APIs without a legal basis.
• Tabular: managed ML platforms (Azure ML, Vertex AI, SageMaker in EU regions) running SDV or similar libraries; Microsoft Presidio and cloud DLP services to detect residual PII [5].
• Choose B when: you need custom logic or text generation and already operate in a cloud tenancy.

Path C — Self-host (open source)

• Tabular: SDV (MIT licence; CTGAN, TVAE, copulas, multi-table, time series) [2], MOSTLY AI SDK (Apache-2.0) [3], ydata-synthetic, synthcity, SmartNoise (OpenDP) for DP synthesis.
• Text: open-weight LLMs (Llama, Qwen, Mistral, Gemma families) via vLLM or Ollama; DP fine-tuning with Opacus; evaluation with open libraries such as the SDMetrics package.
• Test data: Faker, Mimesis, and Synth-style rule-based generators for software QA.
• Hardware: tabular models run on HW1 (CPU) for modest tables, HW2 (one 24 GB GPU) for large relational data or 7-8B text models; HW3 for 30B+ text generation.

Path D — Custom training

Worthwhile for niche modalities (medical time series, industrial sensors) or when formal DP guarantees are needed. Requires the full source data in a secure enclave, a privacy-engineering team and an evaluation harness; plan for months.

State of the art (2026)

• Tabular: transformer and diffusion-based generators now outperform GANs on fidelity for mixed-type tables; multi-table generation with referential integrity is mainstream in commercial tools.
• Text: LLM-based synthetic corpora are widely used for fine-tuning and evaluation, but quality depends on prompt diversity; repeated training on synthetic output risks model collapse and loss of tail diversity.
• Evaluation: frameworks combine statistical, structural and graph-based fidelity checks [7]; no single metric is accepted as proof of anonymity.
• Consolidation: the market moved in 2024-2025 (Hazy into SAS, Gretel into NVIDIA), so vendor continuity is a selection criterion [4].
• Limits: rare combinations may be memorised and leak; outliers are hardest to protect; synthetic data rarely captures correlations absent from the source; bias in the source is reproduced or amplified; DP at strong settings degrades utility.

Shared resources & combinations

• Shared stack: tabular-ml and llm-general capabilities, a secure data enclave, and PII detectors shared with DOC-018 (document anonymisation) and VIS-030 (image anonymisation).
• Upstream: DATA-003 (cleaning and master data) provides clean source tables; DATA-008 (quality monitoring) can validate synthetic outputs.
• Downstream: DATA-023 (labelling) and model fine-tuning; CODE-001 (coding assistants) consume synthetic test data; LANG-027 (synthetic respondents) is the persona-simulation cousin.

Effort, cost & KPIs

• Path A: days to weeks for a first dataset; licence typically by data volume or seats.
• Path B: 1-2 months including privacy evaluation.
• Path C: 1-3 months; mainly engineering and evaluation effort, little compute.
• Path D: quarters.
• Cost drivers: privacy-evaluation work and expert review, not GPU time.
• KPIs: time-to-data-access, fidelity score (distribution and correlation distance), train-on-synthetic/test-on-real utility ratio, privacy-attack success rate, number of production-data copies eliminated from test environments, audit findings.

People & change

Involve management for the mandate and the DPO early: the DPO decides whether the synthetic output counts as anonymous and signs off the privacy report, and a DPIA is likely when the generator is trained on special-category data (Art. 35 GDPR). Data owners release sources, IT and information security set up an isolated environment, and the department lead defines the test scenarios. Test teams are the end users.

Works council: usually no, because the system processes business data, not employee behaviour. If HR or time-tracking data is used as the source, the system is arguably suited to monitor staff and §87(1) no. 6 BetrVG applies; inform the council anyway under §90(1) no. 3 where work processes change.

AI literacy: support staff with a short session on what synthetic data can and cannot guarantee (Art. 4 AI Act, measures to support literacy). Pilot with one test-data use case, measure the saved wait time for data access, and show sceptics the privacy report. Typical concern: "is it really anonymous?" Answer with membership-inference tests and a human release decision. Guides: GUIDE-005, GUIDE-003, GUIDE-009.

Risks, regulation & compliance

• EU AI Act: typically minimal risk; AI literacy (Art. 4) applies. If synthetic text, images or audio are published as realistic content, Art. 50 transparency (machine-readable marking of synthetic outputs) can apply. Synthetic data used to train a high-risk system falls under Art. 10 data-governance duties (bias examination, relevance, representativeness) [8].
• GDPR: the training step processes real personal data and needs a legal basis and purpose compatibility; data is outside GDPR only if truly anonymous, judged case by case against the WP29 criteria [1]. The EDPB's Opinion 28/2024 stresses that anonymity of AI models and outputs must be demonstrated, not assumed [9]. Run a DPIA where source data is sensitive (Art. 9 data such as health).
• Sector rules: banking secrecy, medical confidentiality and supervisory expectations (e.g. EBA/BaFin on model data) may add constraints.
• Risks and mitigations: memorisation and re-identification (DP, nearest-neighbour tests, release only to controlled recipients under contract); bias propagation (compare subgroup fidelity); overclaiming "anonymous" in marketing (document the residual-risk assessment); model collapse (mix with real data).

Getting started

1. Pick one concrete need (test data for one application, or one shareable dataset) and write down the privacy requirement with your DPO.
2. Prototype with SDV or the MOSTLY AI SDK on a non-sensitive table to learn the fidelity metrics.
3. Define the evaluation gate: fidelity thresholds, train-on-synthetic/test-on-real utility, membership-inference test.
4. Run the real pipeline in a secure environment, document the anonymisation assessment, and record the DPO sign-off.
5. Compare with a commercial tool on the same dataset before scaling.

Sources

1. Article 29 Working Party, Opinion 05/2014 on Anonymisation Techniques — https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf
2. Synthetic Data Vault (SDV) — https://github.com/sdv-dev/SDV
3. MOSTLY AI open-source SDK — https://github.com/mostly-ai/mostlyai
4. Overview of synthetic data tools 2026 (Gretel/NVIDIA, MOSTLY AI, SDV) — https://www.k2view.com/blog/best-synthetic-data-generation-tools/
5. Microsoft Presidio (PII detection and anonymisation) — https://github.com/microsoft/presidio
6. Ganev & De Cristofaro, The Inadequacy of Similarity-based Privacy Metrics: Privacy Attacks against "Truly Anonymous" Synthetic Datasets — https://arxiv.org/pdf/2312.05114
7. Synthetic Data Blueprint (SDB): evaluation framework for synthetic tabular data — https://arxiv.org/pdf/2512.19718
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
9. EDPB Opinion 28/2024 on data protection aspects of AI models — https://www.edpb.europa.eu/our-work-tools/our-documents/opinion-board-art-64/opinion-282024-certain-data-protection-aspects_en