EU AI Act Article 57: Build a Sandbox Participation Evidence Pack

Article 57 creates a supervised route for providers and prospective providers to develop and test an AI system, then validate it for a limited time under a specific plan agreed with a competent authority. It also defines the evidence that can leave the sandbox: written proof of successful activities and an exit report covering work performed plus results and learning outcomes.

I would treat that evidence as the main operational prize. A sandbox badge on a pitch deck proves very little. The useful artifact is a dated pack that connects the agreed plan to test runs and authority guidance. It should also preserve mitigations and changes, plus unresolved risks and decisions alongside the final exit documentation.

TL;DR

Article 57 requires at least one national AI regulatory sandbox to be operational in each Member State by 2 August 2027, subject to the consolidated text dated 27 July 2026.
Participation follows a specific, time-limited sandbox plan agreed with the competent authority and may include supervised real-world testing.
Keep authority guidance and test evidence beside risk decisions. Add plan changes and incidents, then preserve mitigation results plus authority responses and exit conditions in the same participation pack.
Sandbox participation leaves liability and supervisory powers in place. DeepInspect covers only routed HTTP LLM evidence, never sandbox administration.

Article 57 defines a supervised testing arrangement

The European Commission's Article 57 text is based on the consolidated AI Act as at 27 July 2026. It requires Member States to ensure that competent authorities establish at least one national sandbox that is operational by 2 August 2027. Joint participation can satisfy the obligation when it gives a Member State equivalent national coverage. The text also permits regional and local sandboxes, including cross-border arrangements.

The legal mechanism is specific. A sandbox provides a controlled environment for development and training, with testing plus validation before an AI system is placed on the market or put into service. Participation is limited in time and follows a plan agreed by the provider or prospective provider and the competent authority. Appropriate safeguards remain part of that plan. Supervised testing in real-world conditions may be included, with the relevant real-world testing plan incorporated where applicable.

Record the authority and legal basis in the project file, followed by system and version. Add intended market use and participation dates, then name contacts plus the plan version. Preserve supervised activities and safeguards in the same index, then add exit criteria plus approval status. Avoid a generic innovation-program folder with meeting notes scattered across email.

Guidance and supervision become evidence inputs

Article 57 directs competent authorities to provide guidance and supervision, with support as appropriate. The focus includes risks to fundamental rights and health, plus safety concerns. Authorities also examine testing and mitigation measures, including their effectiveness. Authorities also guide participants on regulatory expectations and compliance with AI Act obligations.

Capture every guidance item as a controlled record. Include the date and authority, followed by the question and system version. Add the response and affected requirement, followed by the resulting decision. Name the implementation owner and preserve verification evidence plus the closure date. If verbal guidance changes the test plan, issue a dated plan revision and link it to the meeting record. A line in someone's notebook cannot carry the weight of a conformity decision six months later.

Where the system processes personal data or falls under another authority's remit, Article 57 requires the relevant authorities to be associated with the sandbox and involved within their powers. Add those authorities to the evidence map. Record which issue each authority supervised and which part of the plan reflects its input.

The Commission's AI Act overview places sandboxes inside a broader risk-based framework. It also lists the high-risk obligations that buyers should expect to evidence, including risk mitigation and dataset quality. The list adds activity logging plus technical documentation, with deployer information and human oversight. The same list covers cybersecurity, accuracy and resilience. It also covers data governance and record keeping. Use the classification and applicable obligations for the system under test, rather than copying the full list into every plan.

Written proof and the exit report deserve advance design

Under Article 57, a provider or prospective provider can request written proof of activities successfully carried out in the sandbox. The competent authority must also provide an exit report that details activities and results, including learning outcomes. Providers may use that documentation in conformity assessment or market-surveillance work. The text says market surveillance authorities and notified bodies should take the exit report and written proof positively into account, with a view to speeding conformity assessment to a reasonable extent.

Design the participation pack around those outputs at the start. For each plan objective, keep the requirement and test method, followed by the input corpus and system version. Add the execution record and result, followed by reviewer and defect owner. Preserve mitigation, retest, authority interaction, and final disposition. Mark incomplete work in the objective's status field. The exit report should never be the first place where the team tries to reconstruct what happened.

The Article 12 logging guide explains event evidence for applicable high-risk systems. The Article 14 human oversight guide covers the reviewer and intervention record. Link those artifacts only where the sandbox plan tests those obligations.

Sandbox participation preserves liability and supervision

A sandbox is supervised experimentation. Article 57 keeps the competent authorities' supervisory and corrective powers in place. A significant risk to health or safety requires adequate mitigation. The same rule applies to fundamental-rights risk. The authority can suspend testing or participation temporarily or permanently when effective mitigation is unavailable.

Participants also remain liable under applicable Union and national liability law for damage to third parties caused by experimentation. The consolidated text provides a conditional administrative-fine protection for participants that follow the specific plan and participation terms and act in good faith on authority guidance. Preserve every dependency in the evidence pack. A short statement that the sandbox grants immunity would misstate the rule.

Create a suspension record before testing begins. Name the triggers and decision authority. Define the technical stop action and list affected environments, then specify evidence preservation. Run the procedure against a controlled test. Keep the initiating signal and authorization beside the stop time. Add blocked or halted activity and stakeholder notification. Name the investigation owner, then preserve restart approval plus the restored-service test.

For current timing and neighboring obligations, use the high-risk deadline update. The current Commission overview says high-risk obligations begin on 2 December 2027 for the listed standalone use cases following the 2026 changes. Do not reuse the older generic August 2026 date.

The sandbox participation evidence pack

Use one pack per system version and sandbox plan. Keep a signed index at the front so reviewers can see missing items. I would include these sections:

Participation record: Identify the competent authority and sandbox, followed by the legal basis and participant entity. Add named contacts and dates. Preserve confidentiality terms plus plan identifier and review cadence.
System boundary: Record intended purpose and users. Add affected persons, deployment setting, model and application components, data flows, external services, version baseline, and data owner.
Regulatory map: State the participant's role, risk classification, applicable obligations, other Union or national law, and the authority supervising each area.
Agreed plan: Preserve objectives and permitted activities, followed by safeguards and test environments. Add real-world testing terms where applicable plus success criteria. Name suspension triggers, exit conditions, accountable owners, and approvers.
Authority guidance: Keep questions and written responses beside meeting records. Add plan changes, owners, implementation evidence, validation results, and closure dates.
Test register: Link every test to a requirement and plan objective. Preserve corpus versions and execution identifiers, followed by results, defects, mitigations, retests, and acceptance status.
Risk and incident file: Record fundamental-rights and health findings, then safety and privacy concerns. Add cybersecurity, accuracy, resilience, incidents, authority notifications, suspension decisions, closure evidence, and risk acceptance.
Change history: Record model and prompt changes beside data updates. Add policy, application, infrastructure, supplier, and environment changes with approval and the tests repeated afterward.
Exit file: Reconcile completed and incomplete objectives with open risks. Add final system version, learning outcomes, requested written proof, exit report, follow-up conditions, and accountable owners.

The AI risk register template can supply the operating register, but the sandbox pack needs tighter joins to the agreed plan and authority guidance. One risk entry should point to the exact test and mitigation version. It should also name the retest plus exit-report section.

Runtime evidence has a narrow place in the pack

A sandbox may test an application that sends model requests over HTTP. For those calls, preserve the application request ID and user or agent identity. Add model route, policy version, data classification, decision, response linkage, and test objective. This evidence can support a specific plan objective around request authorization or traceability when the test architecture deliberately captures it.

State the scope directly in the signed index. Native sandbox applications and admission decisions sit outside DeepInspect. The same boundary covers meetings, regulator correspondence, legal interpretations, plan approval, real-world testing supervision, personal-data governance, and exit reports. The product cannot turn routed-call logs into proof that the competent authority accepted the full system or that every AI Act obligation was met.

Put each per-decision record beside application and model evidence. Add test-management, incident, authority, and change records. The signed index should identify which system owns each evidence class and how reviewers join them.

DeepInspect

DeepInspect can contribute evidence only for authenticated HTTP LLM traffic deliberately routed through its stateless proxy during the sandbox test. For each routed request, it evaluates the identity context supplied by the application and model destination. It applies data classification plus policy before forwarding. It then records permit, redact, deny, or error outside the application's write path.

Use the DeepInspect request identifier as a join key in tests that examine runtime authorization and policy behavior, including traceability. The competent authority still administers the sandbox. The participant owns the plan and test design, plus the risk file, mitigations, and exit pack. DeepInspect makes no decision about sandbox admission or legal compliance beyond the evidence generated for routed model calls.

Let's talk today.