What EU AI Act regulatory sandboxes offer and whether your organization should use one
A regulatory sandbox is a controlled environment for developing, training, testing and validating innovative AI systems for a limited time before they are placed on the market, under a sandbox plan agreed with the competent authority. Under the AI Act as amended in 2026, each Member State must have at least one national AI regulatory sandbox operational by 2 August 2027, either alone, jointly with other Member States, or by joining an existing sandbox with equivalent national coverage. Whether your organization should apply depends on four things: your role as provider or deployer, your size, the type of system, and whether you need supervised real-world testing before launch. A sandbox is a route to supervised development, not a certificate. It does not certify, approve or declare conformity for your system. Your organization keeps ownership of the decision to apply, of the risk controls, and of the documentation that proves compliance.
Start by checking the system against the high-risk categories and the timeline that applies to it, since sandbox value is highest for systems you are still shaping. Confirm with your national competent authority which sandbox is open to you and what its eligibility criteria and application window are, because these details are set nationally and are not fixed by the Act alone. If you are an SME or start-up with an EU registered office or branch, ask whether priority access applies to your application and what advice channels are available. Ask the authority in writing what it will require in the sandbox plan, how it will handle your data, and what written proof of activities it provides on request. Also ask whether any costs are charged to you, since the Act says free access for SMEs and start-ups applies except for exceptional costs.
Plan for the limits as well as the benefits. Participants remain liable under Union and national law for damage caused to third parties, so a sandbox does not transfer liability. Administrative fines for AI Act infringements are not imposed where you follow the sandbox plan and the authority's guidance in good faith, but that protection depends on your documented adherence. Treat the sandbox as one input to your own compliance program, with your own risk assessment, testing records, and governance decisions, and make sure your legal and security teams agree on how sandbox outputs will feed later conformity assessment or market surveillance evidence.
How a sandbox application moves from request to exit report
The sequence runs from eligibility and application through a decision, an agreed sandbox plan, supervised development and testing, and finally written proof of activities and an exit report that the provider can use as compliance evidence. Each phase closes with a defined output that the next phase depends on.
Confirm eligibility and prepare the application
Before applying, check that your sandbox is run by a competent authority you can reach and that the system is an innovative AI system you intend to develop, train, test or validate before market placement. Gather a description of the system, its intended purpose, the testing questions you want answered, and the personal data or real-world testing you expect to need. Ask the authority for its published eligibility criteria and application format, because the Act requires these criteria to be transparent and fair. The output is a complete application that matches the published criteria.
Await the decision on the application
The competent authority reviews the application against its published criteria and returns a decision within three months of the application, as Article 58(2) requires for the Commission's implementing rules on sandboxes. Track the submission date and any information requests the authority sends during review, since answering them promptly is within your control. Confirm whether the authority accepts applications from SMEs and start-ups with priority, and whether your costs will be free of charge. The output is a written decision that accepts or refuses participation.
Agree the sandbox plan with the authority
Once admitted, work with the authority to write the sandbox plan, which sets the scope of development and testing, the objectives, the conditions of participation, the testing methods, the data handling rules and the activities the authority will supervise. Agree the plan in writing before any testing begins, because the sandbox protections depend on following it. Keep a record of each change the authority approves. The output is a signed or confirmed sandbox plan that defines what counts as in-scope activity.
Develop and validate the system under supervision
Build, train, test and validate the AI system within the limits of the sandbox plan, with the authority receiving the information it needs to supervise. Where the plan allows, supervised real-world testing may be included under Article 57(5), so confirm in advance which real-world conditions, users and data are covered and what safeguards apply. Record test results, defects, guidance received from the authority and any deviation from the plan, because these records become the core of the later exit report. The output is a documented body of development and test activity, with dated records of supervision.
Follow the authority's guidance and keep records
Participants who follow the sandbox plan and the authority's guidance in good faith are protected from administrative fines for AI Act infringements under Article 57(12), but they remain liable under Union and national law for damage to third parties. Treat each piece of guidance as a logged action with a date, an owner and a status. Keep evidence that you acted on it. The output is a guidance log that shows good-faith compliance and identifies any open items before exit.
Request written proof of activities and an exit report
When your activities are complete, request from the competent authority written proof of the activities you finished in the sandbox and an exit report, as Article 57(7) allows on request. Provide the authority with your development and test records so it can document what you did. The exit report is the document that authorities and notified bodies must take positively into account, and you can use it to demonstrate compliance in conformity assessment or market surveillance. Confirm with the authority what format the report takes and how long it will take to issue, since the Act sets no timeline for that step. The output is the written proof of activities and the exit report.
What sandbox participation changes for liability, fines and evidence
Joining an AI regulatory sandbox changes what a provider can show a regulator, what it may be fined for and what it pays for access. Each benefit below comes with a limit that the provider still carries, so read the card limits as carefully as the benefits.
Exit report as compliance evidence
On request, the competent authority gives written proof of the activities completed in the sandbox and an exit report. A provider can use it to demonstrate compliance in conformity assessment or market surveillance, and authorities and notified bodies must take it positively into account. The report reflects what the authority observed, not a certificate. Ask the authority early what it will record in the report and how it will document the plan you agreed.
No administrative fines in good faith
Authorities impose no administrative fines for AI Act infringements when participants follow the sandbox plan and the authority's guidance in good faith. This protection covers fines only. Participants remain liable under Union and national law for damage caused to third parties, so a sandbox does not shield you from claims by people harmed during testing. Keep records showing you followed the plan and each piece of guidance.
Free access for SMEs and start-ups
The Commission's implementing acts must provide free access to sandboxes for SMEs and start-ups, except for exceptional costs. Ask the authority which costs it treats as exceptional and whether they are fixed or recovered per project. Your own costs for engineers, test data, documentation and legal review still fall on you, so budget them separately from sandbox access.
Priority access and advice channels
Member States must give SMEs and start-ups with an EU registered office or branch priority access to AI regulatory sandboxes. They must also run tailored awareness and training and provide dedicated channels for advice on implementing the Act. Confirm your eligibility status before applying, since the priority depends on your registered office or branch. Priority speeds up admission but does not waive the sandbox plan or your duty to remain liable for third-party damage.
Using personal data inside a sandbox and the conditions that apply
Article 59(1) of the AI Act allows personal data that an organization lawfully collected for another purpose to be processed inside an AI regulatory sandbox to develop certain AI systems in the public interest, such as systems in health, environment, energy, transport and public services. The provision is narrow. It applies only where the processing is necessary to meet the sandbox objective, the data sits in an isolated processing environment, the data is deleted after participation ends, and the resulting system makes no decisions affecting the data subjects. If any one of those conditions cannot be shown, the sandbox route is not available for that data set.
The sandbox provision does not create a lawful basis for processing. Under the GDPR, the controller still needs a valid legal basis for any new purpose, must meet the purpose limitation and transparency duties, and must carry out a data protection impact assessment where the processing is likely to create high risk. Your data protection officer should decide whether the new purpose is compatible with the original collection before any data is copied into the sandbox. Confirm the treatment in writing with the DPO and with the national authority running the sandbox, including how the isolated environment is administered, who holds access, and how deletion will be evidenced.
For planning, treat the sandbox plan as the place where these conditions become testable. Ask the authority which records it expects for necessity, access control, isolation and deletion, and build those records into the environment from the start, such as access logs, data inventories, retention settings and a deletion certificate issued at exit. Keep the data set as small as the sandbox objective allows. Where the public-interest purpose is unclear or the data includes special categories, expect the authority and the DPO to ask for more justification before approval, and allow time for that review in the project plan.
Which organizations should consider a sandbox and what to prepare first
A small provider building a new high-risk system is the group the sandbox rules were written with most closely in mind. Under Article 62(1), Member States must give SMEs and start-ups with an EU registered office or branch priority access to sandboxes, along with tailored training and dedicated advice channels. Under Article 58(2), the Commission's implementing acts must keep access free for SMEs and start-ups except for exceptional costs. Applying is still a commitment of staff time, so the application should show that the team understands its own system before asking for supervision.
Prepare the following before applying:
- System description: the intended purpose, the users, the operating context and the Annex III category the system may fall under.
- Risk assessment: the foreseeable risks to health, safety and fundamental rights, and the measures you plan to test.
- Test metrics: the accuracy, robustness and bias measures you will report, with the thresholds you consider acceptable.
- Data inventory: the training, validation and test datasets, their sources and the lawful basis for any personal data.
- Governance owner: a named person accountable for the sandbox plan and for decisions about the system.
A sandbox will not issue a pass, certificate or CE marking. It will not exempt the system from conformity assessment, registration or any other requirement outside the terms of the sandbox plan. Ask the competent authority in writing which parts of the plan carry the protection under Article 57(12).
An established provider usually does not need a sandbox to build a system, but it may need one to test a novel system in conditions that cannot be reproduced in a lab. Article 57(5) allows a sandbox plan to include supervised real-world testing, which is the element most relevant to a provider with a new use case. Because the sandbox plan is agreed with the competent authority, the provider should expect the authority to examine the plan in detail, including who is affected and how the test will stop if something goes wrong.
Prepare the following before applying:
- System description: the novel functionality, how it differs from the product already on the market, and the decisions it influences.
- Risk assessment: the risks specific to the new use case, including risks to people outside the test group.
- Test metrics: pre-defined success and failure criteria that the authority can check against the exit report.
- Data inventory: the data used in testing, separated from production data, and any data reused from other purposes.
- Governance owner: an accountable executive who can stop the test and who holds the quality management records.
The exit report is evidence, not approval. Under Article 57(7), authorities and notified bodies must take it positively into account, but the provider still has to show conformity through the route that applies to the system. A sandbox also does not extend beyond the activities named in the plan, so changes to the system after testing may require new discussion with the authority.
A deployer or integrator that adapts a provider's model, such as by fine-tuning it, connecting it to internal data or changing its intended purpose, may take on provider obligations. The sandbox can be useful in that situation because the adapted system is effectively new. Before approaching an authority, confirm with the upstream provider what it has already documented and what it will allow you to change. Without that agreement, the sandbox plan will have gaps that the authority is likely to question.
Prepare the following before applying:
- System description: the upstream model, the modifications you have made, and the new intended purpose.
- Risk assessment: the risks created by the modification, which may differ from the risks the upstream provider assessed.
- Test metrics: measures for the adapted behavior, not only the base model's published benchmarks.
- Data inventory: the data used for adaptation and evaluation, with its source, rights and retention.
- Governance owner: a person who can speak for the deployment and who can obtain the upstream provider's documentation.
A sandbox will not transfer responsibility for the upstream model to you, and it will not settle contractual questions between you and the provider. It also does not cover deployments outside the plan. If the system is later used in a different context, the plan's protections may not apply, so confirm the scope in writing before any change.
A public sector body may be the national authority that runs a sandbox, a body that wants to develop an AI system for its own services, or a participant in a sandbox run by another body. The Act gives special treatment to public-interest uses. Under Article 59(1), personal data lawfully collected for other purposes may be processed inside a sandbox to develop certain public-interest systems, such as those in health, environment, energy, transport and public services, but only under strict conditions. Public bodies should check early whether their use case falls within those named areas.
Prepare the following before applying:
- System description: the public service affected, the population covered and the decisions the system would support.
- Risk assessment: impacts on fundamental rights and equal treatment, including for groups that have less ability to contest outcomes.
- Test metrics: outcome measures that the oversight body and the public can understand.
- Data inventory: the source of each dataset, the original collection purpose, and the plan for isolation and deletion.
- Governance owner: a senior official with authority over the service and a named data protection officer.
A sandbox will not authorize the processing of personal data beyond what Article 59 permits, and it will not waive obligations under data protection law. It will not make a public body exempt from its own procurement, accountability or record-keeping duties. Confirm with the relevant authority which conditions apply to your data before collecting or moving any dataset.
Questions buyers ask about EU AI Act sandboxes
Is an EU AI Act regulatory sandbox mandatory for my organization?
No. A sandbox is an option for providers developing innovative AI systems, not a legal requirement for a given system. The obligation sits with Member States: under Article 57(1) as amended in 2026, each Member State's competent authorities must have at least one national AI regulatory sandbox operational by 2 August 2027, either alone, jointly with other Member States, or by joining an existing sandbox with equivalent national coverage. Whether you apply is your decision. Confirm with your national competent authority which sandbox is available to you and whether it accepts applications from non-national providers.
Does joining an AI regulatory sandbox cost money?
For SMEs and start-ups, access is free except for exceptional costs. Article 58(2) requires the Commission's implementing acts to provide free access for SMEs and start-ups on that basis, and Article 62(1) gives SMEs and start-ups with an EU registered office or branch priority access. For other applicants, the Act does not set a fee in the sources used here, so ask the authority directly what it charges, what counts as an exceptional cost, and whether any internal staffing, testing infrastructure or external support is excluded from its fee. Your own costs for preparing the sandbox plan, test evidence and documentation are separate from any authority charge.
How long does a sandbox application decision take?
Article 58(2) requires the implementing acts to set a decision within three months of application. That is the statutory target for the decision, not the full time to finish a sandbox. The sandbox itself runs for a limited period under a sandbox plan agreed with the competent authority, and the duration depends on the system, the plan and the testing it requires. Ask the authority for its eligibility criteria, its application format, the expected length of the plan, and how supervised real-world testing is scheduled before you commit internal resources.
Does a sandbox exit report replace conformity assessment?
No. An exit report is evidence, not a conformity assessment. Under Article 57(7), on request, the competent authority provides written proof of the activities completed in the sandbox and an exit report. Providers can use that material to demonstrate compliance in conformity assessment or market surveillance, and authorities and notified bodies must take it positively into account. Where a conformity assessment is still required for your system, you must still complete it, using the route that applies to your system and, where relevant, a notified body. Treat the exit report as one input to the evidence file.
Can a consultant or implementation partner prepare our sandbox application?
Yes, a partner can help prepare the systems, documentation and test evidence that support the application and the sandbox plan. DeployOpen, for example, prepares systems, controls and evidence for compliance assessments, and can work on a fixed scope agreed in writing before work starts. However, the competent authority decides whether to admit a system and what the sandbox plan requires. Only an independent auditor, assessor or certification body issues reports or certificates. Your organization remains responsible for its controls, its declarations and the decisions it makes about the AI system.
What does a sandbox require from our staff?
A sandbox needs named owners who can answer for the AI system throughout the plan. In practice, the work falls to people who understand the system's purpose, training and test data, and the risks it presents, along with a person accountable for legal and regulatory questions and someone who can run the testing and record results. Expect to provide a clear test plan, a plan for handling personal data if any is processed, and a way to stop or adjust testing when the authority's guidance requires it. Confirm the roles the authority expects before you start, since participants must follow the plan and its guidance in good faith to keep the protections described in Article 57(12).
Does sandbox participation protect us from liability and fines?
Only partly, so read the rules carefully. Under Article 57(12), sandbox participants remain liable under Union and national law for damage caused to third parties. The protection is limited to administrative fines for AI Act infringements, and it applies where participants follow the sandbox plan and the authority's guidance in good faith. Any deviation from the plan, or failure to act on guidance, can remove that protection. Take legal advice on civil liability, contractual obligations to customers, and how your insurance responds before you rely on the sandbox for risk transfer.
Mistakes that delay a sandbox application or weaken its evidence
Most sandbox problems start before the application is filed or after the sandbox plan is signed. The cards below cover the decisions that slow admission, the assumptions that leave participants exposed, and the paperwork that determines whether sandbox activity later counts as compliance evidence.
Applying before the system is defined
A sandbox plan is agreed with the competent authority, so an application for a system whose purpose, intended users, data sources and test plan are still open is hard to scope. Authorities need to judge whether the testing is limited in time and controlled. Before applying, write down the intended purpose, the testing objectives, the metrics you will measure, the environment and the exit criteria. Ask the authority which information it expects in an application and whether it reviews eligibility on a rolling basis.
Assuming the sandbox shields from liability
Participation does not remove civil liability. Sandbox participants remain liable under Union and national law for damage caused to third parties. What the sandbox limits is administrative fines for AI Act infringements, and only under conditions. Confirm with counsel how insurance, contracts with test users and national tort rules apply to your participants before any real person is exposed to the system.
Departing from the agreed plan
Fine protection depends on following the sandbox plan and the authority's guidance in good faith. A team that changes the model, widens the user group, extends the testing period or adds a data source without telling the authority can lose that protection for the affected activity. Keep a change log tied to the plan, submit material changes to the authority before making them, and record each piece of guidance received with the date and the action taken in response.
Assuming personal data use is covered
Sandboxes allow personal data lawfully collected for other purposes to be processed for certain public-interest systems, but only under conditions including necessity, an isolated processing environment, deletion after participation and no decisions affecting data subjects. Those conditions sit on top of GDPR, not in place of it. Before any personal data enters the sandbox, confirm the lawful basis, complete a data protection impact assessment where required, and agree the isolation and deletion steps with your data protection officer and the authority.
Not requesting the exit report in writing
The exit report and written proof of completed activities are not issued automatically. The competent authority provides them on request, and providers can then use them to show compliance in conformity assessment or market surveillance. Make the request in writing at the close of the sandbox, name the documents you need, and store the response with your technical documentation. Without that record, the testing you paid for may be hard to show to a notified body or market surveillance authority later.
Missing the SME priority route
Priority access to national sandboxes is available to SMEs and start-ups with an EU registered office or branch. Organizations that assume they qualify, or that do not check the registration status of the legal entity that will hold the system, can lose their place in the queue or apply through a route that does not give priority. Confirm your registered office or branch status and your SME or start-up classification before filing, and ask the authority how it verifies eligibility.
Where an implementation partner helps and where the authority decides
The organization owns its AI system, its controls and every decision about what goes into the sandbox. An implementation partner such as DeployOpen can help prepare the parts that sit in the organization's own infrastructure: a self-hosted test environment, logging and monitoring for the sandbox, the technical documentation and version records, and an evidence pack organized around the sandbox plan. That work is preparation. It makes the organization's claims easier to check, but it does not replace the organization's own accountability for the system's design, data and outcomes. Only the competent authority decides whether a sandbox application is accepted, agrees the sandbox plan, supervises the activities, and issues the written proof and exit report described in Article 57(7). Under Article 58(2), the authority must reach a decision within three months of an application under the implementing rules, so the reader should confirm the current procedure with the authority they apply to. Independent conformity assessment bodies are a separate route. Where a system needs one, the assessor issues any certificate, and a sandbox exit report does not replace that assessment.
Before engaging a partner, decide what the partner will and will not touch. Ask for a written scope that lists the environments, logs, documents and test records to be produced, who signs off each deliverable, and which items remain with the organization's legal, compliance and product teams. Ask the partner to show how its evidence maps to the sandbox plan's objectives, and confirm with the authority which evidence it expects. A partner's work should never be presented as an authority approval, a conformity assessment result or a guarantee of acceptance, and a partner that offers one should be treated as a warning sign. Hiring a partner does not guarantee that the authority accepts the application, that the sandbox produces a favorable exit report, or that the system will pass any later assessment. Those outcomes depend on the system, the data, the quality of the plan and the authority's judgment. Plan for the case where the application is declined or the exit report identifies gaps, and budget time and staff to respond to either outcome.
How DeployOpen prepares sandbox evidence with your team
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and prepares the systems and evidence a sandbox plan needs. We do not issue exit reports or assessments, since the competent authority and independent assessors make those determinations. Work starts from a written, fixed scope agreed before any build begins.
How we scope
- The written scope names the AI system, its intended purpose and the sandbox your competent authority or the AI Office runs.
- Scope lists the sandbox plan items your team must prepare, such as testing goals, data sources and exit criteria.
- Engagements are fixed-scope, and ongoing support is available as a retainer once the work is agreed in writing.
How we build
- We stand up the test environment in your cloud account, data center or air-gapped network, isolated from production systems.
- We configure logging, access control and version records so each sandbox activity can be shown to the authority later.
- We build test and monitoring procedures that match the sandbox plan, with personal data handling limited to the agreed conditions.
How we hand over
- You receive documentation of the environment, configuration baselines, test records and data-handling controls for your files.
- We organize activity logs and evidence into a package your team can submit when the authority asks for proof of completed activities.
- Your team owns the controls, sandbox plan and submissions, and we walk through the handover with the people who will maintain them.
How we support
- Retainers cover upgrades, patching and continued evidence collection while the sandbox runs and after exit.
- We can run security testing of the AI system during the sandbox, with findings tracked against the sandbox plan.
- Support questions from the authority or a notified body go to your team first, and we help prepare the technical answers.
