2026-06-09·5 min read·sota.io Team

EU AI Act Art.57 Regulatory Sandboxes: A Developer's Guide to Testing AI in a Compliance-Protected Environment (2026)

Post #1597 in the sota.io EU Compliance Series — EU AI Act Regulatory Sandbox 2026 #1/5

EU AI Act Art.57 Regulatory Sandbox Developer Guide 2026

The EU AI Act's August 2, 2026 deadline looms for high-risk AI providers — but buried in the regulation is a provision that most developers have overlooked: Article 57, which mandates that EU member states establish AI regulatory sandboxes by that same date.

These sandboxes are not a free pass. But for startups and SMEs building high-risk AI systems who cannot yet afford full Annex IV technical documentation, a completed quality management system (Art.17), or production-grade post-market monitoring (Art.72), a regulatory sandbox offers a supervised testing window where innovation can proceed under guidance rather than penalty.

This is the first post in our five-part series on EU AI Act Regulatory Sandboxes. We cover what sandboxes are, who gets priority access, what they protect you from, and crucially — what they do not protect you from.


What Is an AI Regulatory Sandbox Under Art.57?

Article 57 of the EU AI Act establishes AI regulatory sandboxes as controlled environments set up and operated by competent authorities (national market surveillance authorities or the AI Office) that allow providers of innovative AI systems to develop, train, test, and validate those systems under direct regulatory supervision.

The core concept is borrowed from financial services — where "fintech sandboxes" let startups pilot new payment products under regulator oversight before full authorization. The EU AI Act applies the same model to AI, with particular attention to high-risk AI systems under Annex III and general-purpose AI (GPAI) models with systemic risk.

Under Art.57, sandboxes must:

The sandbox does not make your AI system permanently exempt from the regulation. It buys you supervised development time — with a regulatory partner rather than a regulatory adversary.


The Art.62 SME and Startup Priority

Article 62 of the EU AI Act specifically addresses measures to support SMEs and startups. Read alongside Art.57, it creates a two-tier entry path:

Large providers can apply for sandbox access but receive no priority treatment. They must demonstrate specific innovation justification and are expected to have more compliance infrastructure already in place.

SMEs and startups (generally: fewer than 250 employees, under €50M annual turnover or €43M balance sheet) receive:

This matters because Art.99 penalties — up to €35M or 7% of global annual turnover for prohibited practices violations, up to €15M or 3% for other compliance failures — create existential risk for startups. The sandbox creates a temporary compliance buffer while you build toward full conformity.


What the Sandbox Protects You From

The sandbox's protections are real but precisely scoped. Understanding their limits is as important as understanding what they provide.

Protected: Enforcement During Development

While your AI system is in an approved sandbox, the supervising authority cannot initiate market surveillance enforcement action against that system for the specific compliance gaps covered by your sandbox plan. If your Art.9 risk management system is incomplete, or your Art.11 technical documentation (Annex IV) is in draft form, the sandbox authority can guide you toward completion rather than issuing a corrective action notice.

This is significant. Without sandbox status, an incomplete Art.11 technical documentation package in a deployed high-risk AI system is immediately actionable by market surveillance authorities under Art.74.

Protected: Graduated Compliance Timeline

Sandbox participants work under an agreed development timeline with the supervising authority. This means you can stage your compliance work:

Outside a sandbox, all of these are required simultaneously before market placement.

Protected: Iterative Testing

The EU AI Act's requirements for high-risk AI assume a largely static system architecture at the point of conformity assessment. Sandbox testing explicitly allows iterative development — training runs, model updates, parameter changes — that would otherwise require repeated conformity assessment cycles.


What the Sandbox Does NOT Protect You From

This is where many developers misread the sandbox. The following obligations apply in full, even inside an approved sandbox:

Not Protected: Art.5 Prohibited Practices

The six prohibited AI practices in Article 5 — subliminal manipulation, exploitation of vulnerabilities, social scoring, real-time biometric surveillance in public spaces (with narrow law enforcement exceptions), emotion recognition in workplace/education, and AI-generated CSAM — are absolute prohibitions. No sandbox can authorize testing of a prohibited system.

Not Protected: Data Protection Law

The GDPR applies in full during sandbox testing. Processing personal data under Art.22 automated decision-making, or any special categories data under Art.9 GDPR, requires full legal basis and data subject rights compliance regardless of sandbox status. The AI Act sandbox provisions do not create a GDPR exemption — they operate alongside data protection law, not above it.

Not Protected: Fundamental Infrastructure Obligations

This is the point most often missed. The sandbox protects you from enforcement around AI-specific compliance gaps. It does not change the legal framework governing:


Infrastructure and Sandbox Supervision: Why This Matters

Here is the practical infrastructure tension that no sandbox guidance document addresses directly:

Your sandbox supervisor — typically the national competent authority or its designee — needs direct, low-friction access to your AI system's development environment, training logs, validation datasets, and risk management documentation. This is how they supervise. This is how you demonstrate progress.

If your sandbox environment runs on AWS, Azure, or Google Cloud, your infrastructure is nominally in an EU data center but legally reachable via US CLOUD Act Section 103 warrants. This creates a jurisdictional collision:

For a startup in a regulatory sandbox — where the supervising authority is building trust with you as a future market participant — this dual-jurisdiction risk is particularly acute. The authority is not just checking your documentation; they are assessing your trustworthiness as a future operator of high-risk AI in the EU market.

EU-sovereign infrastructure (no US parent company, no CLOUD Act exposure) eliminates this tension. Your sandbox supervisor gets clean access. Your training data, validation records, and risk management documentation are reachable only through EU legal process.


When Member States Must Have Sandboxes Ready

Article 57 of the EU AI Act requires competent authorities to establish sandbox frameworks by August 2, 2026 — the same date as the regulation's general application. This is not aspirational; it is a legal obligation.

The practical implication: from August 2, 2026, EU member states must accept sandbox applications from eligible providers. If you have not begun your sandbox application before that date, you are likely starting too late to benefit from the first sandbox cohorts.

Ahead of August 2026, several EU member states are establishing early sandbox frameworks building on existing fintech and general digital sandbox experience:

The European AI Office coordinates cross-border sandbox cases — particularly relevant for GPAI providers whose systems are deployed across multiple member states.


Step-by-Step: Applying for Sandbox Access

Step 1: Identify Your System's High-Risk Classification

Before applying, confirm that your AI system meets the Annex III high-risk classification criteria. Article 6 provides the two-step test:

  1. Is your system in one of the eight regulated domains (biometric ID, critical infrastructure, education, employment, essential services, law enforcement, migration, administration of justice)?
  2. Does it pose significant risk of harm to health, safety, or fundamental rights?

If yes to both, you are a high-risk AI provider and potentially eligible for sandbox access (or in need of it).

Step 2: Document Your Compliance Gap

Sandbox applications require you to articulate specifically what you cannot yet comply with and why. This is not an admission of fault — it is the evidence base for the sandbox's supervising plan.

Common sandbox-eligible gaps include:

Step 3: Choose Your Supervising Authority

For single-member-state systems, apply to your national competent authority (typically the designated market surveillance authority under Art.74). For systems deployed across multiple EU states, the European AI Office can coordinate a joint sandbox arrangement.

Step 4: Prepare Your Sandbox Development Plan

The application should include:

Step 5: Infrastructure Declaration

Increasingly, sandbox applications ask where your system is hosted and how your supervising authority will access development environments, test data, and logs during the sandbox period. Declaring EU-sovereign infrastructure (hosted on Hetzner, Scaleway, OVHcloud, or EU-native PaaS like sota.io) simplifies this step.

Step 6: Submit and Await Approval

Processing times vary by member state but are expected to target 30-90 day response cycles once frameworks are operational. Apply early — sandbox capacity is finite, and SME priority is competitive for the first cohorts.


What You Still Need to Build During the Sandbox

A sandbox is not a compliance holiday. The supervising authority will expect to see your compliance work advance on the agreed timeline. At minimum, use the sandbox period to build:

Art.9 Risk Management System — The foundation of everything. Document: hazard identification, risk estimation, risk evaluation, risk management measures, and residual risk verification. Even a minimal Art.9 RMS showing structured thinking is more sandbox-compliant than none.

Art.11 Technical Documentation (Annex IV) — Start with the elements you can complete: general description, intended purpose, training methodology, and testing data overview. The Annex IV list is 15+ items but some can be developed iteratively.

Art.12 Record-Keeping — Implement logging from day one of sandbox development. Your sandbox supervisor will likely want to review these logs at milestone checkpoints. EU-hosted logs are easier to share with an EU authority.

Art.17 Quality Management System — Even a lightweight QMS document demonstrating organizational accountability for AI development quality satisfies the spirit of the requirement for an early-stage startup.


Checklist: 10 Steps to Sandbox Readiness

☐ 1. Confirm Annex III high-risk classification applies to your system
☐ 2. Document current compliance gaps across Art.9/10/11/17/12
☐ 3. Identify which EU member state(s) your system will primarily operate in
☐ 4. Contact the national competent authority (or EU AI Office for multi-state)
☐ 5. Prepare sandbox development plan with milestone timeline
☐ 6. Declare infrastructure — EU-sovereign hosting simplifies supervisory access
☐ 7. Implement basic Art.9 risk management system before application
☐ 8. Start Art.11 Annex IV technical documentation (partial is sandbox-appropriate)
☐ 9. Implement Art.12 logging infrastructure before sandbox testing begins
☐ 10. Submit application by Q2 2026 to be in first sandbox cohort

What's Next in This Series

This post has covered the Art.57 sandbox framework and who it's for. The remaining posts in this series go deeper:


sota.io is EU-native managed PaaS — no US parent, no CLOUD Act exposure, deployed on Hetzner Germany. Sandbox-compliant infrastructure for EU AI Act developers: your logs, training data, and risk management documentation stay in EU jurisdiction where your sandbox supervisor can access them without legal complexity. Start deploying →

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.