What is an AI regulatory sandbox?

How it works

<strong>What makes it a regulatory sandbox</strong>

A genuine AI regulatory sandbox has five core features. First, it is run or directly supervised by a competent authority, not only by a private testing provider or a trade group. Second, it is time limited. Third, it is bounded by a defined project, legal questions and safeguards. Fourth, it produces a formal record of what was learned. Fifth, it exists to clarify compliance, not only to improve technical performance.

That is why a regulatory sandbox is different from a normal staging environment, a red team exercise, or a generic AI test programme. A digital sandbox may provide data, computing tools or synthetic environments. An innovation hub may provide informal guidance. A conformant regulatory sandbox adds regulator oversight, an agreed testing framework and a route for turning experimentation into compliance evidence.

The European Union's AI Act gives the clearest current statutory model. It treats the sandbox as a controlled framework set up by a competent authority so innovative AI systems can be developed, trained, tested and validated for a limited period before being placed on the market or put into service. The law also makes clear that the sandbox is meant to improve legal certainty, support compliance and generate regulatory learning, not suspend supervision.

<strong>Who runs one and who gets in</strong>

The institution depends on the legal system and the sector. In the EU model, national competent authorities are responsible, and the European Data Protection Supervisor may establish a sandbox for Union institutions, bodies and agencies. In the UK, sector regulators can run their own sandboxes, which is why the FCA has a financial services model and the ICO has a data protection model. In Brazil, the ANPD is piloting a sandbox for AI and personal data. In Utah, the Office of Artificial Intelligence Policy works with the relevant sector regulator to negotiate regulatory mitigation agreements.

Admission is usually by application. A serious application does not just say "we use AI". It explains the use case, why the technology is novel, what legal uncertainty exists, who may be affected, what data is being used, what public interest or consumer benefit is claimed, what guardrails already exist, and why a standard approval route is not enough. In the EU, the common rules are designed to make eligibility and selection criteria transparent and fair, with decisions communicated within three months. Brazil's ANPD pilot is voluntary and free, but participants must bring their own technical and financial capacity. The ANPD also gives extra scoring weight to some projects, including generative AI, public sector proposals and start-ups.

A regulatory sandbox is therefore not just for start-ups. Many regimes prioritise smaller actors because they face the highest legal and administrative burden, but larger firms, public bodies and existing regulated entities can also be admitted where the criteria fit. The key question is usually not size. It is whether the project raises a genuine supervisory question that can be productively explored in a bounded trial.

<strong>What is agreed before testing starts</strong>

Before live testing begins, the regulator and participant usually define a sandbox plan or an equivalent mitigation agreement. This is where the project becomes governable. The plan should describe the system, intended purpose, testing period, populations affected, legal issues in scope, datasets or data flows, human oversight arrangements, stop conditions, incident handling, communications to users, reporting cycle and exit conditions.

This design step is where many of the practical gains arise. If the project cannot be clearly scoped, it is often a sign that the deployment is too broad, too mature or too unclear to belong in a sandbox. Regulators typically prefer small scale, limited duration trials, because that makes supervision real rather than symbolic.

The exact paperwork differs. Under the EU AI Act, the implementing rules for sandboxes must cover application, participation, monitoring, exit and termination, including the sandbox plan and the exit report. Brazil's ANPD requires an operational chronology, transparency measures, a discontinuity plan, communication mechanisms for data subjects and a simplified analysis of key data protection risks as part of the sandbox plan. Utah's regulatory relief process is built around a tailored mitigation agreement that sets safeguards, reporting duties and operating conditions for the pilot.

If the trial reaches real people or real environments, the requirements harden. The EU model requires agreed safeguards for any testing in real world conditions carried out within the sandbox. In sectoral settings, this usually means stronger human oversight, tighter inclusion criteria, narrower use of the tool, clear user notices, direct escalation routes and a credible power to stop the pilot if risk appears.

<strong>What is tested, and what evidence is created</strong>

A good sandbox tests both the AI system and the controls around it. That can include data governance, model behaviour, error handling, transparency notices, explainability material, complaint routes, identity checks, escalation logic, incident reporting and the way humans stay in the loop. The question is not only "does the model work". It is also "can this organisation operate it lawfully and safely in the context claimed".

That produces evidence that can be reused outside the sandbox. Typical records include risk analyses, testing logs, benchmark results, explainability artefacts, user disclosures, meeting notes, incident reports, monthly monitoring reports and final or exit reports. In the EU model, exit reports and written proof of successful sandbox activities are meant to be taken positively into account by market surveillance authorities and notified bodies when later conformity work is assessed. Brazil's ANPD expects a final results report with technical and regulatory indicators, lessons learnt and possible improvements to the regulatory framework. Utah's pilots include monthly reporting to the Office and continuing review of safety signals.

This is where standards and risk management frameworks become useful. NIST's AI RMF is not a sandbox law, but it gives a practical structure for the evidence a sandbox should produce. "Govern" asks who is accountable and how the organisation makes decisions. "Map" asks what the system does, in what context, and for whom. "Measure" asks what is being tested and how risk is being observed. "Manage" asks what mitigations are required, when release should stop, and how issues are tracked over time. For generative AI, NIST's GenAI Profile adds a technology specific companion that can sharpen the testing agenda for systems using large language or multimodal models.

The practical value is simple: a sandbox that only yields regulator correspondence is weak. A sandbox that yields reusable governance evidence is strong.

<strong>What legal flex can exist, and what does not change</strong>

The legal flex inside a sandbox is usually narrower than people expect. Some regimes mainly provide guidance and supervisory support. Others can add restricted authorisation, waivers, individual guidance, no enforcement letters or temporary mitigation agreements. The FCA is explicit that its sandbox is not regulatory exempt, and that it cannot waive national or international law. Utah is explicit that its agreements are temporary and conditional. Brazil's ANPD presents its sandbox as a controlled environment that may temporarily suspend certain requirements to enable small scale experimentation, but it also says that participation is not legal certification and that the data protection regime continues to apply within the experimental setting.

The EU AI Act is more legally structured than most sandbox programmes. It says regulators must provide guidance, supervision and support inside the sandbox, including around risks to fundamental rights, health and safety. It also says data protection authorities and other competent authorities must be involved where their remit is affected. At the same time, it says sandbox participation does not affect supervisory or corrective powers. If significant risk appears and cannot be effectively mitigated, authorities can suspend or stop the testing. Liability to third parties remains.

That means a sandbox is not a zone outside the law. It is law applied through supervised discretion. In some circumstances the law itself may create a narrow additional basis for experimentation. The EU framework, for example, provides a limited route for further processing certain lawfully collected personal data in sandboxes for some public interest systems, subject to strict conditions and safeguards. But the broader structure of data protection and other applicable law still remains in place.

<strong>How sandboxes fit into wider AI governance</strong>

A sandbox should sit inside an organisation's wider governance system, not beside it. Senior accountability should already be clear. Legal, product, engineering, security, data protection, compliance and the relevant domain team should all know who can approve changes, who can stop testing, who signs external disclosures and who owns reporting to the authority.

In practice, the best use of a sandbox is to answer high value questions before broad launch. Do user notices make sense in context. Does the human reviewer have enough authority and time to override the system. Is the data flow defensible. Are edge cases handled safely. Are incidents escalated quickly enough. Does the organisation understand what evidence it will need later for procurement, audit, internal sign off or conformity work.

That is also why sandboxing links closely to assurance and audit, even though it does not replace either. Assurance can review whether the testing plan was credible and whether the evidence supports the claimed level of trust. Audit can review whether commitments were met and whether lessons were actually folded back into policy, controls and operating practice. A well run sandbox becomes a disciplined bridge between experimentation and formal governance.