What Article 57 requires of AI regulatory sandboxes
Article 57 of Regulation (EU) 2024/1689 establishes AI regulatory sandboxes as controlled frameworks that help innovative AI systems move through development, training, testing, and validation for a limited period before they are placed on the market or put into service. Operation sits under direct supervision and guidance by competent authorities. Each Member State must establish at least one sandbox at national level, operational by 2 August 2026. Sandboxes may also be stood up regionally, locally, or jointly with other Member States. The European Data Protection Supervisor may establish a sandbox for Union institutions, bodies, offices, and agencies.
Competent authorities are expected to explain regulatory expectations during participation. On successful exit they may issue written proof of the activities carried out and related results, and an exit report is prepared. Sandbox authorities should cooperate, including through the European Artificial Intelligence Board and the AI Office, to share practices and support cross-border arrangements where relevant.
First, participation does not exempt providers from liability under Union or national law for damage caused to third parties as a result of experimentation in the sandbox. Second, sandbox guidance is not a conformity assessment approval or a compliance safe harbor. Personal data processing inside a sandbox for developing certain AI systems in the public interest is allowed only under the conditions and safeguards in Article 59. Chapter VI sandbox-related provisions apply from 2 August 2026, while prohibited-practice rules apply earlier and high-risk obligations apply later under the staged AI Act timeline.
For AI governance leaders, the operating model is regulatory engagement under supervision, not a lighter form of QA. Entry implies authority interaction, defined scope and duration, safeguards, progress visibility, and structured exit documentation that may later inform conformity, CE marking, or post-market monitoring work.
When an AI agent use case belongs in a sandbox
AI agents that plan, invoke tools, and act across enterprise systems are AI systems under the Act. That classification alone does not justify sandbox entry. Article 57 is aimed at innovative systems that benefit from supervised pre-market or pre-service experimentation. Conventional internal staging, red teaming, and pre-production QA remain the default path when requirements are sufficiently clear and residual uncertainty is manageable without competent-authority oversight.
Evaluate suitability along novelty, regulatory uncertainty, risk profile, and timing. Ask whether the intended purpose, autonomy level, tool reach, or data practices create genuine ambiguity about how obligations will apply, and whether authority guidance during a time-boxed test would materially reduce that ambiguity. Map the use case to the likely risk category and to any sector rules before drafting an application. If the main need is performance tuning, integration hardening, or standard safety regression, strengthen internal test environments instead of seeking sandbox admission.
Also assess jurisdiction and readiness. Identify which national or joint sandbox authority has competence for your placement or service model, what application materials and timelines it will use, and whether it will be operational when the program needs supervised testing. National operating rules, templates, and fees will vary and may still be maturing ahead of the 2026 deadline. Cross-border coordination exists in principle, but practical access paths and mutual recognition of exit documentation remain implementation-dependent.
Define entry criteria, test scope, success metrics, time box, and exit criteria with legal, security, privacy, governance, and business owners before applying. Budget for authority interaction overhead: progress reporting, remote or on-site supervision, and remediation of issues raised during the sandbox. Treat the decision as a go or no-go on regulatory engagement, not as an accelerated route to production.
| Decision factor | Favors sandbox | Favors internal testing |
|---|---|---|
| Regulatory clarity | Genuine ambiguity on how obligations apply to purpose, autonomy, tools, or data | Requirements are sufficiently clear for staged internal validation |
| Primary need | Supervised pre-market or pre-service experimentation with authority guidance | Performance tuning, integration hardening, or standard safety regression |
| Timing and access | Competent sandbox will be operational and aligned to program timeline | Sandbox access, templates, or fees are not ready when the program needs them |
| Program posture | Team can support reporting, supervision, scope control, and structured exit | Main gap is ordinary QA maturity rather than regulatory engagement |
Runtime controls for governed AI agent experimentation
Sandbox supervision does not relax the need for enforceable runtime boundaries. Liability and safety duties continue, so agent experimentation must remain reconstructible, permissioned, and isolatable from unmanaged production impact. The AI Act text does not prescribe agent-specific control catalogs. Enterprises should derive controls from risk management, data governance, transparency, human oversight, and logging duties, then align them to authority guidance for the specific sandbox.
Agent identity, least-privilege permissions, tool-call policy enforcement, human breakpoints, isolation from production credentials and data domains, monitoring, incident paths, and immutable, exportable logging remain essential even inside a sandbox.
Documentation and evidence for supervision and exit
Authorities supervising a sandbox need a clear picture of what is being tested, under which controls, with what residual risk, and with what outcomes. Enterprises should prepare an evidence pack before day one, then keep it current as the test evolves under change control.
Core materials typically include a system description and intended purpose, architecture and data-flow diagrams, risk assessment, data governance and retention statements, human oversight measures, logging and monitoring design, incident response runbooks, and a control mapping that shows how runtime enforcement implements the approved test boundaries. During operation, retain exportable logs and decision records sufficient to reconstruct agent behavior, tool-call allow and deny outcomes, human interventions, quality or drift findings, and any safety events.
At exit, organize results against the pre-agreed success and exit criteria. Capture residual-risk notes, remediation completed during the sandbox, and open issues. Written proof of activities and the exit report can support later conformity and post-market monitoring work. They do not replace required assessments or mark the system as approved for unrestricted deployment.
Assign ownership for evidence production and retention across AI governance, security, privacy, legal, and engineering. Establish a RACI, name an accountable owner for the regulatory engagement, and keep board- or risk-committee visibility where the agent program is material. Preserve all applicable Union and national obligations on fundamental rights, safety, data protection, and sector rules for the full duration of participation.
Practical governance practices during participation
- Separate sandbox from production risk: Keep credentials, networks, tools, and data domains distinct so experimentation cannot create unmanaged operational or legal exposure outside the approved boundary.
- Enforce policy at action time: Do not rely on prompt instructions alone. Mediate tool calls and outbound actions through enforceable allow and deny decisions that are logged.
- Measure what authorities will inspect: Align telemetry and test reports to system behavior, oversight effectiveness, incidents, and residual risk rather than model benchmarks alone.
- Close the loop into conformity work: Feed exit reports, written proof, and control lessons into later risk management, technical documentation, and post-market monitoring plans without treating them as a safe harbor.
- Plan for national variation: Expect differences in operating rules and templates across Member States, and keep architecture evidence portable for joint or cross-border arrangements where relevant.