Synthetic Data Approval Gates For UK AI Testing

AI Trust & Governance

8 July 2026 | By Ashley Marshall

Synthetic data can make AI testing safer, faster and more realistic. It can also hide weak evidence behind a privacy-friendly label.

Synthetic data needs approval gates, not optimism

Synthetic data is useful because it lets a team test cases that real operational data cannot safely or easily provide. For a UK SME, that can mean extra examples of rare complaints, edge cases in a pricing workflow, simulated customer records for a prototype, or test traffic for an AI agent before it is allowed near live systems. The risk is that synthetic data can sound safer than it is. Once a dataset has the word synthetic attached to it, teams can start treating privacy, fairness and evaluation as already solved.

That is the wrong starting point. The GOV.UK AI Insights page on synthetic data, updated on 13 March 2026, is explicit that synthetic data is not a replacement for real-world data, and that it must be combined with real-world testing and validation. It also warns that synthetic data is just as vulnerable to weakness, bias, omission and artificial patterns as real-world data. That is the line SME leaders should keep pinned to the wall.

The practical answer is an approval gate. Before synthetic data is used for AI testing, someone accountable should approve the purpose, source, privacy claim, quality checks and evidence plan. This does not need to be a heavyweight committee. In a smaller business, it can be a 30 minute review with the product owner, data lead, risk owner and the person who will sign off the test result. What matters is that the team cannot move from generation to testing to release without proving what the synthetic dataset is for, what it is not for, and what evidence would show that it has failed.

The privacy gate asks whether the data is genuinely safer

The first approval gate is privacy. Synthetic data may reduce risk, but it does not automatically remove the UK GDPR question. If the synthetic dataset can be linked back to a person, if it preserves unusual combinations from the source data, or if it can be attacked with external data, the organisation still needs to treat it as a data protection issue rather than a free testing asset.

The ICO's anonymisation guidance is useful here because it frames anonymity as an identifiability risk assessment, not a magic label. It asks organisations to consider the spectrum of identifiability, the motivated intruder test, who else may be able to identify people from the data, and when identifiability risk assessments should be reviewed. It also distinguishes anonymisation from pseudonymisation, with pseudonymised data still sitting inside data protection law.

For an SME, the operating model can be simple. The privacy gate should record the source datasets used, the generation method, whether personal data was processed to create the synthetic data, who can access both the source and generated data, and whether the synthetic output has been tested for memorisation or re-identification risk. The gate should also stop teams from making casual claims such as anonymous, de-identified, safe or non-personal without evidence. If the team cannot explain the privacy claim in plain English, it should not pass.

Tools can help, but they do not remove accountability. Teams using platforms such as Gretel, Mostly AI, Tonic.ai, Syntho or SDV should still review configuration, privacy metrics, sampling choices and access controls. A vendor privacy score is useful evidence, not a board-level decision. The approval question is narrower and more commercial: can we use this dataset for this test, with this access model, without pretending we have eliminated all privacy risk?

The quality gate checks whether the test evidence will mean anything

The second gate is quality. Synthetic data can be excellent for controlled tests, stress cases and under-represented scenarios. It can also make weak AI look stronger than it is. GOV.UK gives a clear warning: if synthetic test data is configured similarly to synthetic training data, a model can pass training and testing but fail on real-world data in production. That is one of the most common ways synthetic data launders risk. The evidence looks tidy because the test set shares the same artificial assumptions as the training set.

A practical quality gate should ask five questions. What real-world distribution is the synthetic data meant to mimic? Which edge cases is it deliberately adding? Which relationships were preserved, changed or removed? What independent validation set will be used? Which metric will decide whether the synthetic data is good enough for this testing purpose? Those questions are deliberately concrete. They move the conversation away from synthetic versus real and towards whether the dataset can support the claim the team wants to make.

The gate should also separate test types. Synthetic data used for unit-style checks, workflow rehearsals or privacy-preserving demos does not need to prove the same thing as synthetic data used for model evaluation. For model evaluation, the bar is higher. Teams should compare synthetic distributions with source distributions, test outputs on real holdout data where lawful and proportionate, and record limits around rare cases, hidden dependencies and protected characteristics. Where the use case affects people materially, such as lending, recruitment, health triage or insurance, fairness testing should not rely on synthetic data alone.

SMEs do not need a research lab to do this well. They need a repeatable evidence template. Record the dataset version, generator version, prompt or configuration, sampling assumptions, validation metrics, known gaps and sign-off decision. If the model later fails in production, that record lets the business learn instead of reconstructing decisions from Slack messages and notebook outputs.

The assurance gate turns synthetic data into auditable evidence

The third gate is assurance. The point is not to create paperwork for its own sake. The point is to make a claim about the AI system that another person can inspect. DSIT's Introduction to AI assurance, published on 12 February 2024, describes assurance as the process of measuring, evaluating and communicating the trustworthiness of AI systems. It also says assurance helps organisations demonstrate compliance, manage reputational risk and build customer trust. That matters for SMEs because trust is often the commercial bottleneck, not model accuracy.

The UK approach also gives a useful structure. The government's AI white paper sets out five cross-sector principles: safety, security and robustness, appropriate transparency and explainability, fairness, accountability and governance, and contestability and redress. Synthetic data approval should map to those principles. For example, a fraud detection test might use synthetic transactions to probe robustness, but the approval gate should also ask how the test handles fairness, what explanation will be given to staff, and how a customer could challenge an outcome if the AI system moves beyond testing.

The DSIT portfolio of AI assurance techniques lists techniques such as impact assessment, bias audit, compliance audit, certification, conformity assessment, performance testing and ongoing testing. An SME does not need to use all of them. It should choose the techniques that match the risk of the use case. A low-risk internal routing tool may need a documented impact assessment and performance test. A customer-facing eligibility tool may need a fuller bias audit, human review process and legal sign-off.

In practice, the assurance gate should produce an evidence pack. That pack should contain the approved use case, risk classification, data lineage, privacy assessment, quality checks, evaluation results, sign-off names and limits on reuse. Reuse is important. Synthetic data approved for one workflow should not quietly become training data for another. Approval should be scoped, versioned and time limited.

The security gate protects models, datasets and development workflows

The fourth gate is security. Synthetic data can reduce exposure to live customer records, but it can also create a false sense that the development environment no longer matters. That is dangerous. Models, prompts, evaluation datasets, embeddings, notebooks, logs and generated outputs can all reveal business logic or sensitive patterns. If a synthetic dataset was generated from personal or commercially sensitive source data, the generation workflow itself may be more sensitive than the final file.

The NCSC's Machine learning principles, published as version 2.0 on 22 May 2024, make this point in broader terms. They say AI and machine learning systems are subject to novel security vulnerabilities and should be secured across design, development, deployment, operation and end of life. They also include a specific principle to manage the full life cycle of models and datasets. That maps directly to synthetic data because the dataset is not a disposable test fixture. It is part of the AI supply chain.

An SME security gate should be practical. Restrict access to source data and synthetic data separately. Store generation scripts, prompts and configuration in version control. Keep synthetic datasets out of public repos and shared drives unless a privacy review has explicitly allowed it. Log who generated the data, who downloaded it and which model tests used it. Review whether synthetic examples are being captured in prompts, screenshots, support tickets or third-party analytics tools. Set a retention date.

This is also where supplier control comes in. If a team uses a synthetic data vendor, a cloud AI platform, a labelling service or an external consultant, the approval gate should check contractual controls, subprocessors, data location, deletion terms and evidence export. A sensible question for the risk owner is: if a regulator, customer or enterprise buyer asked how this synthetic dataset was created and controlled, could we answer within a day?

The decision gate stops synthetic data becoming a shortcut

The final gate is the release decision. This is where the counterargument usually appears: if synthetic data protects privacy and lets us test faster, why slow the team down with approvals? The answer is that the gate is not there to slow testing. It is there to prevent the wrong conclusion being promoted as evidence. Synthetic data is at its best when it expands what a team can test. It is at its worst when it becomes a way to avoid the harder parts of validation, stakeholder review and real-world monitoring.

The decision gate should be a short meeting or asynchronous approval, but it should ask disciplined questions. What decision are we making from this test? What evidence came from synthetic data, and what evidence came from real data, expert review, user testing or production monitoring? What risks remain unresolved? What condition would force a rollback, extra review or rejection? Who owns the next monitoring checkpoint? Without those answers, the business is not approving an AI system. It is approving a story about an AI system.

For SMEs, the best operating model is a tiered gate. Low-risk prototypes can use a light approval: purpose, privacy check, dataset version and expiry date. Medium-risk internal tools should add quality metrics, data lineage and human review. High-risk or customer-facing systems should require data protection review, fairness testing, security review, legal sign-off where needed, and a monitoring plan. The point is proportionality. A five-person business does not need enterprise bureaucracy. It does need a clear line between experimentation and evidence used for release.

Good synthetic data governance is not anti-innovation. It lets teams move faster because everyone knows the rules before the experiment starts. It also gives customers, investors and partners something more credible than reassurance. It gives them a chain of evidence showing that the business understands synthetic data as a tool, not a loophole.

Frequently Asked Questions

Is synthetic data automatically outside UK GDPR?

No. If people can be identified directly or indirectly, or if the generation process uses personal data in a way that creates identifiability risk, UK GDPR considerations still matter. Treat the privacy status as something to evidence, not assume.

Can synthetic data replace real-world testing?

No. Synthetic data can extend testing, fill gaps and reduce exposure to live records, but it should be combined with real-world validation where lawful and proportionate.

What should an SME approve before using synthetic data?

Approve the use case, source data, generation method, privacy claim, access controls, validation metrics, reuse limits, retention date and named owner for the decision.

Which synthetic data tools are worth considering?

Common options include Gretel, Mostly AI, Tonic.ai, Syntho and the open source Synthetic Data Vault. The tool matters less than the review of configuration, quality metrics and privacy evidence.

What is the biggest evaluation mistake with synthetic data?

Using synthetic test data that shares the same assumptions as synthetic training data. That can make a model look strong in testing while leaving it fragile in production.

Do small businesses need a formal AI governance board?

Usually not. A lightweight approval gate with the product owner, data lead, risk owner and release approver is often enough for low and medium risk work.

When should legal or data protection review be mandatory?

Bring in legal or data protection review when personal data is used to generate synthetic data, when the AI affects people materially, or when the output will support a customer-facing release decision.

How should synthetic datasets be controlled after approval?

Version them, restrict access, keep generation configuration, log who used them, set a retention date and prevent reuse outside the approved scope without another review.