[EAAPL-DAT004] Synthetic Data Generation

Category: Data Architecture
Sub-category: Synthetic Data / Privacy-Preserving AI
Version: 1.2
Maturity: Proven
Tags: synthetic-data, GAN, VAE, differential-privacy, k-anonymity, privacy-validation, utility-validation
Regulatory Relevance: GDPR Article 5, Privacy Act Australia APP 3/11, EU AI Act Article 10, APRA CPS 234, ISO 42001 §8.4

1. Executive Summary

Many of the most valuable enterprise AI use cases — fraud detection, clinical risk prediction, credit underwriting — require training on data that organisations cannot freely share: patient records, account transactions, personally identifiable information. Synthetic data generation creates statistically faithful, privacy-preserving datasets that can be used for AI training, testing, and sharing without exposing real individuals.

This pattern defines a production synthetic data generation pipeline covering three generation techniques (GAN/VAE/statistical), privacy validation (differential privacy, k-anonymity, membership inference testing), utility validation (statistical fidelity, downstream model performance parity), and the regulatory framework for accepting synthetic data in lieu of real data for AI training and testing.

Organisations that implement this pattern have unlocked AI use cases previously blocked by privacy constraints, accelerated model development cycle times by 40–60% through unrestricted test data availability, and reduced privacy incident risk in development and testing environments.

Target audience: Chief Privacy Officers, Chief Data Officers, ML Platform leads, Data Science leads.

2. Problem Statement

Business Problem

AI programmes are blocked or slowed by inability to use real data outside production environments. Development and test environments cannot receive production data due to privacy regulation; third-party data science partners cannot access customer data; cross-border data transfer restrictions prevent AI development in global teams.

Technical Problem

• Real patient/customer/financial records cannot legally be used in development, test, or partner-facing environments.
• Data anonymisation (masking, tokenisation) degrades statistical relationships, destroying the signal AI models need.
• Small datasets for rare events (fraud, rare diseases) are insufficient for model training.
• Class imbalance in real data requires augmentation techniques that preserve statistical properties.
• Testing AI edge cases with real data creates production data exposure in test environments.

Symptoms

• AI development cycle stalled waiting for "data access approval" that may never come.
• Test environments using obviously fake data that does not reflect real statistical patterns, causing test AI models to fail in production.
• Third-party data science partners blocked from receiving any data.
• Rare event classes (fraud, rare diseases) under-represented in training data, degrading model recall.
• Privacy incidents caused by real production data in development environments.

Cost of Inaction

3. Context

When to Apply

• AI training or testing requires data that cannot be shared due to privacy, regulatory, or contractual restrictions.
• Small training datasets need augmentation (class imbalance; rare events).
• Development/test environments need representative data without PII.
• Third-party partners (model vendors, data scientists) need data to work with.
• Cross-border transfer restrictions prevent sharing real data across jurisdictions.

When NOT to Apply

• Real data is freely available and shareable (no privacy constraint) — synthetic data adds cost and validation overhead with no benefit.
• The AI use case requires exact real-world records (e.g., training on specific known fraud patterns that must be preserved exactly).
• Synthetic data utility validation cannot be performed (no access to real data even for validation).
• The risk of generated data containing memorised real records is unacceptable (very small original datasets).

Prerequisites

Industry Applicability

4. Architecture Overview

Design Philosophy

Synthetic data generation is not a single technique — it is a pipeline with four stages: generation, privacy validation, utility validation, and certified publication. Skipping any stage creates either privacy risk (insufficiently private synthetic data) or utility failure (synthetic data that does not produce models with parity performance to real data).

Generation Techniques. The pattern supports three generation approaches, selected based on data type and privacy requirements:

Statistical/parametric synthesis uses marginal and joint distributions estimated from real data (SDV's GaussianCopula, CTGAN-light). It is computationally cheap and interpretable but may not capture complex non-linear feature dependencies. Best for tabular data with moderate complexity.

Variational Autoencoders (VAE) learn a continuous latent space representation of the data and sample from it. VAEs are effective for tabular data with complex correlations and naturally support conditional generation (generate samples with a specific class label). They are faster to train than GANs and produce more stable outputs.

Generative Adversarial Networks (GAN) — specifically CTGAN and TabularGAN — train a generator/discriminator pair to produce synthetic records indistinguishable from real. GANs produce the highest-fidelity synthetic data but are prone to mode collapse (under-representing some data regions) and are computationally expensive. Best for high-fidelity requirements where computational budget is available.

Privacy Validation — Three Layers. No single privacy metric is sufficient:

1. k-anonymity and l-diversity check that no synthetic record is unique to an identifiable individual in the original dataset. These are necessary but not sufficient.
2. Differential privacy (DP) provides mathematical privacy guarantees: the synthetic dataset's statistical properties would be the same regardless of whether any individual record was included in the training data. DP is applied as a privacy mechanism during GAN/VAE training (DP-SGD), adding calibrated noise to gradient updates. The privacy budget (ε) is tracked and reported; typical production thresholds are ε ≤ 1 (high privacy) to ε ≤ 10 (moderate privacy).
3. Membership inference attack testing trains an adversarial classifier to determine whether a specific real record was in the training data. If the attack accuracy is near 50% (random chance), the synthetic data provides strong privacy. If attack accuracy is significantly above 50%, the synthetic data leaks real record membership.

Utility Validation. Privacy and utility trade off: more privacy noise reduces data fidelity. Utility validation measures this trade-off across three dimensions:

1. Statistical fidelity: Compare marginal distributions (KS test), pairwise correlations, and higher-order statistics between real and synthetic datasets.
2. Train-on-Synthetic, Test-on-Real (TSTR): Train an AI model on synthetic data; evaluate on real data. Compare AUC/F1 against a model trained on real data. A TSTR performance ratio ≥ 0.90 indicates high utility.
3. Train-on-Real, Test-on-Synthetic (TRTS): Train on real, test on synthetic — validates that synthetic data represents the same distribution as real.

A synthetic dataset is certified for AI training only when both privacy validation and utility validation pass their thresholds.

5. Architecture Diagram

6. Components

7. Data Flow

Primary Flow

Error Flow

8. Security Considerations

Authentication & Authorisation

• Real source data access for generator training is highly restricted; access logged and time-limited.
• Synthetic dataset access controlled by usage policy in catalogue; different tiers for internal/partner/public.

Secrets Management

• Source data credentials for generator training stored in secrets manager; not retained beyond training session.
• Generator model artefacts access-controlled; a trained generator can be used to generate more synthetic data and must be treated as sensitive.

Data Classification

• Generator model (trained on real data) classified at least as Confidential — it encodes statistical properties of real data.
• Certified synthetic datasets classified per usage policy; may be Internal or Shareable depending on privacy validation.

Encryption

• Source data encrypted at rest during generator training; access keys in KMS.
• Synthetic datasets encrypted at rest; encryption may be relaxed for low-sensitivity certified datasets per policy.

Auditability

• All access to source data for generation logged.
• Synthetic dataset access logged per usage policy.
• Privacy and utility validation results stored immutably with dataset version.

OWASP LLM Top 10 Mapping

9. Governance Considerations

Responsible AI

• Synthetic data must preserve demographic representation; if real data is biased, synthetic data may amplify bias.
• Bias audit required as part of utility validation: compare demographic distributions in real vs. synthetic.

Model Risk Management

• Models trained on synthetic data must be validated on real data before production deployment.
• TSTR ratio ≥ 0.90 is minimum bar; risk committee may require higher threshold for high-risk AI.

Human Approval Checkpoints

• Privacy Officer must approve Synthetic Dataset Certificate before publication to external partners.
• Legal counsel review required for cross-border synthetic data sharing.
• Risk committee approval required for synthetic data used in high-risk AI (EU AI Act Annex III).

Governance Artefacts

10. Operational Considerations

Monitoring

SLOs

Logging

• All generation runs logged with source dataset version, generator type, privacy parameters, validation results.
• Retained 7 years for regulatory compliance.

Incident Management

• Privacy gate failure with external partner data → P1; Privacy Officer notified immediately.
• Unexpected source data access to generate synthetic data → P1 security incident.

Disaster Recovery

11. Cost Considerations

Cost Drivers

Optimisations

• Use open-source SDV or CTGAN for initial synthetic data; move to enterprise platform only when scale demands.
• Cache trained generators; regenerate synthetic data without retraining if source distribution unchanged.
• Run membership inference testing on a sample rather than full synthetic dataset.

Indicative Cost Range

12. Trade-Off Analysis

Option Comparison

Architectural Tensions

13. Failure Modes

14. Regulatory Considerations

15. Reference Implementations

AWS

Azure

GCP

On-Premises

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven — Core synthetic data generation techniques (CTGAN, VAE, SDV) are mature and production-proven. Differential privacy integration (Opacus) is mature. Regulatory acceptance of DP-validated synthetic data is growing but jurisdiction-specific.

18. Revision History