A regulatory sandbox is not a seal of approval

A sandbox is a supervised learning environment. Treating it as a certification machine confuses the process of discovery with the outcome of conformity assessment.

The term regulatory sandbox creates a powerful image: a protected space where an AI system is tested until an authority gives a green light. The product then appears trustworthy, lawful and market-ready. That shortcut is dangerous.

An AI regulatory sandbox is a controlled, time-limited environment in which providers or prospective providers can develop, train, test and validate an innovative system with competent authorities. It aims to reduce legal uncertainty, expose risks, enable regulatory learning and facilitate compliance. It replaces neither applicable law nor conformity assessment, market surveillance or provider accountability.

The obligation applies to Member States, not every project

Article 57 requires each Member State to ensure that at least one national AI regulatory sandbox is operational by 2 August 2026. This is sometimes misread as a duty for every higher-risk system to participate. The legal text requires public infrastructure and procedures; it does not establish universal mandatory participation.

Participation may still be valuable where a novel system raises unresolved questions, crosses supervisory domains or lacks defensible evidence. The question is not „Must we enter?" but „Which uncertain requirement could supervised testing answer better than ordinary internal work?"

A sandbox is a joint investigation

Work follows a specific plan agreed with the authority. It limits time, scope, system version, objectives, tests, data, responsibilities and stop conditions. Authorities provide appropriate guidance, supervision and support concerning fundamental rights, health, safety, mitigation and applicable requirements.

This is not outsourced product development. The provider remains responsible for architecture, documentation, testing and decisions. The authority offers regulatory orientation, not an implementation team. A useful programme separates three levels:

1 · Product learning: does the system work under defined conditions?

2 · Risk learning: which harms, failure modes and control limits become visible?

3 · Regulatory learning: which requirements apply, how can they be evidenced and where is interpretation needed?

Maturity before entry saves supervised time

A project without purpose, ownership, data map or stable version consumes the programme with basic discovery. Germany's pilot work therefore highlights structured maturity. Maximum completion is unnecessary, but the starting point must be testable.

A strong application describes the problem, innovation, intended market, provider and deployer roles, system boundaries, data flows, preliminary classification, open legal questions, available tests and precise learning objectives. „Please check our product" is not a test plan.

Good questions are observable: Can human oversight actually stop an outcome? Does performance remain within limits for relevant groups? Which records prove reversal? How do the AI Act, data protection and sector law interact in this workflow?

The exit report is valuable, but not a badge

Activities, results and lessons are captured in an exit report, potentially accompanied by written proof of completed activities. These artifacts can improve technical documentation and accelerate later conformity assessment.

They are not a universal seal. Evidence applies to the tested scope, version, data and assumptions. A model change, added autonomy, new market or different population can reduce relevance. Successful participation does not prove that every later deployment is compliant.

Accurate wording is: „The system was tested under supervision within the agreed scope; the following activities and outcomes were documented." It is not „The authority certified the system" unless a separate certification actually occurred.

Supervision and liability do not disappear

Article 57 preserves authorities' supervisory and corrective powers. Significant risks require adequate mitigation, and testing may be suspended where mitigation fails. The controlled environment is not a legal vacuum.

Other laws remain relevant. Personal data, medical devices, finance, employment, product safety and cybersecurity can bring additional authorities and requirements. Regulatory cooperation is therefore part of system design, not administrative decoration.

Data protection is not automatically relaxed

Article 59 permits further processing of certain lawfully collected personal data only under narrow cumulative conditions for selected systems safeguarding substantial public interest. It is not a general exemption from data protection law.

Conditions include necessity, a functionally separate protected environment, authorised access, risk monitoring, deletion, logs and detailed documentation. Processing must not lead to measures or decisions affecting data subjects. Where anonymised, synthetic or other non-personal data suffice, the special route does not apply.

Sandbox and real-world testing are distinct

A sandbox may include supervised real-world testing. The AI Act separately regulates testing of certain high-risk systems outside a sandbox. Requirements include a plan, authority involvement, time limits, safeguards for vulnerable people, qualified oversight, consent where applicable and effective reversal or disregard of system decisions.

An isolated digital test and exposure of real people have different risk profiles. Every case should state whether it is synthetic, simulated, shadow-mode or real-world and which safeguards apply.