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.

Access should be fair, while capacity remains finite

Article 58 calls for transparent and fair criteria, broad and equal access and a decision generally within three months. Access should be free for SMEs and start-ups, although fair and proportionate exceptional costs may be recovered.

This is not automatic admission. A persuasive application demonstrates innovation, a regulatory learning question, suitable maturity and a feasible plan. It explains why normal advice, internal testing or existing guidance cannot resolve the issue alone.

Build a transferable evidence package

The value lies in reusable evidence, not attendance. A good package connects system and data maps with versions, the sandbox plan and change log, requirements and mapped evidence, test cases with metrics, results and residual uncertainty, a risk/incident/stop log, human-oversight decisions, open legal or standardisation questions, and the exit report with a handover to conformity and operations processes.

Without this transfer, the programme becomes an interesting demonstration whose lessons disappear at the next release.

The right outcome is a reasoned next step

A sandbox need not end in pass or fail. Outcomes may be sufficient evidence, more tests, reduced scope, a new control, involvement of another legal regime, postponement of real-world testing or termination.

An early stop can be success when it prevents harm and waste. Regulatory learning is productive when it enables a defensible decision, not when it manufactures a positive label.

Not every problem belongs in a sandbox

Before applying, compare alternatives. Clear requirements are often handled more efficiently through legal and domain advice, standards, internal evaluation or a conformity body. Technical performance questions should first enter reproducible testing. A sandbox adds most value where innovation and regulatory uncertainty are genuinely coupled and authorities can also derive reusable learning.

A portfolio gate can score novelty, unresolved regulatory question, impact, maturity, need for supervision, data risk and expected knowledge transfer. Projects without ownership or delivery capacity return to internal preparation. Scarce capacity then goes to cases with the highest shared learning value rather than the strongest marketing narrative.

Change must update the evidence scope

Systems change during experimentation. Every material change needs an identifier, rationale and impact assessment. A new model, source, tool permission, population, autonomy level or decision threshold can invalidate earlier results. The plan distinguishes changes inside the agreed scope from those requiring renewed authority coordination.

The same discipline continues after exit. A release register links sandbox evidence to the version actually shipped. Only valid evidence enters conformity documentation. Historical results remain available but are not presented as current assurance.

Advice should prepare learning capacity

Responsible advisers do not promise an authority badge. They map the system and data flows, refine the unresolved question, identify relevant disciplines, expose evidence gaps and prepare a realistic plan. Binding legal interpretation and official decisions remain with the responsible experts and authorities.

A useful readiness test asks whether the team can state what it will do after every plausible outcome. If only a positive result has a path, the exercise is marketing. Real regulatory experimentation includes change, restriction and stop routes.

Worksheet: Design a sandbox plan

1. Describe system, innovation, role and intended market.

2. State three concrete regulatory learning questions.

3. Define scope, version, duration and exit criteria.

4. Map tests, data, metrics and safeguards.

5. Separate simulation, shadow mode and real-world testing.

6. Assign authority, provider, deployer and privacy roles.

7. Define stop, incident and change processes.

8. Plan evidence for conformity assessment and operations.

All materials to download — the topic overview and the worksheet:

Scope: This article is implementation guidance, not legal advice. Legal effects depend on the system, role, sector, applicable law and final sandbox procedure. A sandbox is neither universally mandatory nor a certification or liability waiver. Editorial review date: 17 July 2026.