Synthetic Data for UK AI Compliance Testing

Synthetic data can let a team build software, exercise controls, and test AI without routinely copying live customer records into lower-trust environments. It cannot make the source data, generator, or release automatically anonymous, representative, or compliant. Its value depends on a declared purpose and evidence that it is useful enough for that purpose while disclosure risk remains acceptable.

That distinction matters because “synthetic” covers very different artefacts. Random but correctly formatted rows may be ideal for testing a file import. A statistically fitted dataset may support model development but carry more disclosure risk. Artificial edge cases may test a rule that production data rarely exercises, yet say nothing about real-world prevalence. One dataset should not be promoted across those purposes without re-evaluation.

This article reflects sources checked on 31 July 2026. It addresses UK organisations under the UK GDPR, Data Protection Act 2018 as amended, and the Data (Use and Access) Act 2025, with sector obligations layered on top. It is not a legal determination that a dataset is anonymous or a regulator-approved compliance test.

Define the job before choosing a generator

Start with a one-sentence purpose and an allowed-use statement. Common purposes include:

• schema, integration, and performance testing;
• training staff in a sandbox;
• exercising fraud, vulnerability, or exception workflows;
• developing or comparing models;
• sharing a lower-disclosure research sample; and
• simulating rare operational scenarios.

Then write the prohibited uses. Format-only data should not validate statistical fairness. A dataset tuned to a specific model should not become an independent test set for that model. A research sample should not be used to make decisions about named people. Synthetic records should never be reintroduced into live customer, financial, clinical, or regulatory records.

The ONS synthetic data policy says synthetic data will not preserve every property of real data, must be fit for its intended use, and needs disclosure checking before broader release. Treat that as the operating premise rather than a caveat in small print.

Classify the data product and its lineage

Keep a registry entry for every synthetic dataset: source snapshot, controller, generator and version, parameters, privacy controls, intended users, approved purpose, evaluation results, expiry date, and release decision. Label every file and table visibly as synthetic.

Preserve lineage without exposing the real records to every user. The team consuming synthetic data needs to know what relationships were intentionally preserved, which were not, how missingness was handled, and which decisions the data cannot support.

Do not assume synthetic means anonymous

The legal question is whether people are identifiable in context, not whether the rows have invented names. A generator can memorise uncommon combinations, reproduce source records, reveal membership, or make confidential attributes easier to infer. A recipient may combine the release with other data.

The ICO’s anonymisation introduction says information that does not meet the legal threshold for effective anonymisation must be treated as personal data. Its identifiability guidance recommends contextual assessment, including a motivated-intruder test and regular review.

Assess at least:

• exact and near matches to source records;
• unusual combinations and small groups;
• membership-inference and attribute-inference risk;
• nearest-neighbour distance and record linkage;
• leakage from generator APIs, checkpoints, prompts, or logs;
• recipient knowledge, access, incentives, and onward-sharing ability; and
• the persistence of a public release that cannot realistically be recalled.

If risk is unclear, keep the dataset inside the source security boundary and treat it as personal data. Pseudonymisation, redaction, and synthetic generation can reduce risk but do not by themselves move information outside data-protection law.

Evaluate utility at the decision level

Global resemblance is not enough. A dataset can match every column’s average while destroying the relationship that drives a credit, safety, or vulnerability decision. Conversely, exact statistical fidelity may be unnecessary for a load test and may increase disclosure risk without improving the test.

Use a purpose-specific utility plan:

• Format and constraint tests: types, lengths, nulls, invalid values, referential integrity, encodings, and volume.
• Business-rule tests: each rule branch, boundary, combination, expected result, and appeal or correction path.
• Analytical work: univariate and multivariate distributions, subgroup sizes, missingness, seasonality, and task-relevant relationships.
• Model development: downstream performance on synthetic data followed by a protected evaluation on real, held-out data.
• Rare-event work: curated cases reviewed by domain experts, explicitly separated from estimates of real prevalence.

The ONS synthetic data pilot warns that preserving fine multivariate structures can increase disclosure risk and recommends focusing on the relationships actually needed. Its SynthGauge work frames utility and privacy as a use-case-specific trade-off, not a single score.

Compare results across protected real and synthetic evaluation sets where lawful and necessary. Report differences, uncertainty, and subgroup performance. Do not use a synthetic dataset as the only evidence that a model will work on people or events it was designed to represent.

Separate compliance rules from the data generator

Synthetic data can exercise a compliance control; it cannot decide whether the underlying control is legally sufficient. Build expected outcomes from an independently approved rule specification. If the same model generates a case, predicts the answer, and grades itself, the test is circular.

For each scenario, record:

• the source rule, policy, contract term, or control objective;
• the version and effective date;
• input facts and expected outcome;
• permitted alternatives and escalation paths;
• who approved the oracle;
• what evidence constitutes a pass; and
• what the test does not establish.

Include negative and adversarial cases: conflicting instructions, missing consent, expired permissions, vulnerable customers, unusual names and addresses, threshold boundaries, repeated retries, and a subject exercising a right. Test the whole workflow, including notice, logging, human review, correction, deletion, and downstream posting—not only the model response.

The FCA’s 2025 synthetic-data governance considerations are expressly insights rather than formal guidance, but they show how generation and use can fit within existing model and data governance. Regulated firms must still map their own rules and supervisory expectations.

Govern the source and generator

Real data used to fit a generator remains governed. Apply purpose limitation, minimisation, access control, retention, and security to the source extract, training environment, generator artefacts, and evaluation logs. Complete a DPIA where processing is likely to result in high risk, and document controller, processor, and sub-processor roles.

The ICO’s privacy-enhancing technologies guidance includes synthetic data and differential privacy, but is under review following the Data (Use and Access) Act. Use it with the ICO’s current amendment notices and seek specialist advice where the legal status matters.

Security controls should include:

• isolated generation environments and least-privilege access;
• approved, versioned source snapshots;
• no unreviewed prompts or sample rows in public services;
• signed code and dependency scanning;
• protected model checkpoints and privacy parameters;
• immutable release and evaluation records;
• expiry and deletion for source extracts; and
• incident response for suspected memorisation or disclosure.

The NCSC secure AI development guidelines treat security as a lifecycle responsibility and call out data poisoning, supply chains, secure deployment, and monitoring. A generator supplied by a vendor is part of that chain.

Protect rare groups and inconvenient errors

Generation methods tend to smooth or underproduce sparse patterns. Those may be the exact cases a compliance system most needs to handle: a rare disability adjustment, an unusual household structure, a small fraud pattern, or an exceptional accounting status.

Create an edge-case catalogue separately from the fitted dataset. Have domain owners specify necessary scenarios and reviewers check that they are plausible, respectful, and not stereotypes. Retain realistic missing and invalid values when the intended system must cope with them. Track coverage by scenario rather than celebrating a large row count.

Do not infer fairness from balanced synthetic groups alone. Evaluate the deployed system on appropriate real-world evidence, investigate error consequences, and maintain correction and redress. Artificially equal group counts can hide biased labels, omitted variables, or unequal operational treatment.

Prevent contamination and false confidence

Use separate namespaces, access roles, storage locations, and visual banners for synthetic assets. Block synthetic identifiers from live imports. Test deletion and reset routines before every exercise. Record when synthetic data reaches dashboards so that teams do not treat simulated revenue, incidents, or customers as real.

Common failure modes include:

• direct sampling or lightly altered real rows sold as synthetic;
• selecting privacy settings after seeing the desired utility result;
• publishing before a disclosure-risk review;
• using the generator’s training data as the final evaluation set;
• omitting rare cases because aggregate metrics look good;
• allowing synthetic outcomes into operational reporting;
• treating a compliance scenario as legal assurance; and
• retaining the real source extract indefinitely “for regeneration.”

Synthetic data should reduce exposure, not create a parallel uncontrolled data estate.

Run a 90-day controlled programme

Days 1–30: purpose and inventory. Choose one bounded use, such as testing an onboarding import or exercising a refund rule. Identify source ownership and lawful processing, map sensitive fields, define users, write prohibited uses, establish baselines, and choose privacy and utility tests before generation.

Days 31–60: generate and attack. Produce versioned candidates inside the approved environment. Measure exact matches, linkage and inference risks, schema coverage, task utility, rare cases, and subgroup behaviour. Have a separate reviewer challenge both the generator and expected outcomes.

Days 61–90: restricted use. Release to named internal users under an expiry date. Monitor access, defects, misuse, and contamination. Run the intended software or control tests, then confirm key conclusions against protected real evidence where appropriate. Prepare a data card and release decision.

Do not expand to external sharing merely because the internal pilot worked. The recipient context and irreversibility change the disclosure assessment.

Define stop and release gates

Pause generation or use if:

• exact or near-source matches breach the agreed threshold;
• a high-risk individual or small group may be inferred;
• a dataset is used outside its approved purpose;
• material task relationships or rare cases are not preserved;
• the compliance oracle is disputed, outdated, or model-generated;
• synthetic records reach production or official reporting;
• source, generator, or evaluation lineage cannot be reproduced;
• a vendor changes training, retention, or sub-processing terms; or
• protected real-data confirmation contradicts the synthetic result.

A release decision should name the recipient, purpose, privacy evidence, utility limits, licence or contract controls, expiry, and owner. “Synthetic” is a description of how data was produced, not an approval status.

Connect the work to existing controls

Poor master data can make synthetic generation faithfully reproduce inconsistent codes and invalid relationships. The master-data guide explains how to establish dependable source definitions first. For the wider legal and operational context, use the UK AI privacy and compliance guide alongside current ICO guidance.

Decision

Use synthetic data when it demonstrably reduces exposure and improves a named test. Scale only when lineage is reproducible, privacy risk has been assessed in the release context, utility is measured against the actual task, rare cases are covered, and synthetic assets cannot contaminate live records. The strongest programme is not the one that creates the most realistic rows; it is the one that knows exactly which conclusions those rows can and cannot support.

Primary sources

• ONS: Synthetic data policy
• ONS: Synthetic data pilot working paper
• ONS Data Science Campus: Evaluating synthetic data with SynthGauge
• ICO: Introduction to anonymisation
• ICO: Assessing effective anonymisation
• ICO: Privacy-enhancing technologies
• FCA: Synthetic data governance considerations, August 2025
• NCSC: Guidelines for secure AI system development