A sandbox is supervised testing, not a compliance exemption

Article 57 of the EU AI Act requires Member States to provide AI regulatory sandboxes. These are controlled environments in which providers or prospective providers can develop, train, validate and test innovative AI systems for a limited period under regulatory supervision.

The official AI Act Service Desk explains that competent authorities can provide guidance on the AI Act and other relevant Union and national law. Participation can improve legal certainty and help identify risks, mitigations and evidence before a system reaches the market.

A sandbox does not remove the applicant's obligations or guarantee that a system is compliant. It creates a structured setting in which assumptions can be tested and documented with the relevant authority.

Who should consider applying

The Service Desk states that any provider with an AI system within the scope of the AI Act can apply. In practice, a sandbox is most valuable where the system is innovative, the legal or risk classification is genuinely uncertain, testing needs regulatory input, or the team needs to validate safeguards in a realistic environment.

Prospective providers, including startups and SMEs, may benefit when they need to demonstrate a disciplined approach to customers or investors but do not yet have a mature compliance function. Larger organisations may use a sandbox for a novel system with significant operational or fundamental-rights questions.

A routine low-risk tool with well-understood controls may gain less from the process. Applicants should be able to explain why supervised experimentation is proportionate and what specific uncertainty the sandbox will help resolve.

Prepare a clear intended-purpose statement

Begin with a concise description of the system, intended purpose, expected users, affected people, deployment context, inputs, outputs and known limitations. Separate the proposed sandbox test from future roadmap claims.

Intended purpose anchors the authority's understanding of scope and risk. If the application shifts between several possible uses, the testing plan and regulatory questions will be difficult to assess.

Bring a provisional role and risk assessment

Document the organisation's expected role under the AI Act and its provisional view of the system's classification. Identify any possible prohibited-practice, high-risk, transparency or general-purpose AI considerations, together with the assumptions and unresolved questions.

The point is not to present uncertainty as certainty. A useful application shows that the team has done enough analysis to ask focused questions and understands which deployment facts could change the outcome.

Define the test plan and evidence outputs

Set out what will be tested, the datasets or scenarios involved, success and stop criteria, expected risks, monitoring, human oversight and proposed mitigations. Include how participants or affected people will be protected during testing.

Name the evidence the exercise should produce: evaluation results, bias or robustness analysis, oversight records, transparency tests, incident logs, residual-risk decisions and a final control assessment. This turns sandbox participation into reusable assurance rather than a one-off conversation.

Build an applicant evidence pack

A practical pack should include the intended-purpose statement, system architecture summary, data and model dependency map, role and classification rationale, risk register, testing protocol, human oversight design, security and privacy controls, incident route, change log and named owners.

Keep the pack versioned throughout the sandbox. Record which assumptions changed, what evidence caused the change and how the final design differs from the system that entered the process.

AI Act Ready helps teams organise those artefacts into a living evidence pack that can support the sandbox, internal approval and later buyer due diligence. This article is practical guidance rather than legal advice; application processes and eligibility details should be confirmed with the relevant competent authority.