EU AI Act Regulatory Sandbox: CISO Guide to Articles 57-60

EU AI Act regulatory sandboxes under Articles 57-60 are the formal mechanism for pre-market validation of high-risk AI systems under live regulatory supervision. For CISOs preparing AI deployments in the EU, sandbox participation is not just a compliance checkbox: it is the fastest path to a defensible conformity assessment and CE marking, with a regulator acting as your security review partner rather than your adversary.

This guide covers what Articles 57-60 actually require, the updated deadlines following the Digital Omnibus, which Annex III systems qualify, and the technical security documentation package your team needs to prepare before submitting an application.

What EU AI Act Regulatory Sandboxes Actually Are

The EU AI Act uses the term "regulatory sandbox" but the Article 57-60 mechanism is not the kind of experimentation environment the phrase usually implies. These are state-administered supervised testing programs with specific legal consequences.

Article 57 requires every Member State to ensure its national competent authority establishes at least one sandbox. The authority provides "guidance, supervision and support" throughout the testing period. At the end, it issues a written exit report with documented outcomes that carry formal evidentiary weight in any subsequent conformity assessment.

The critical protection Article 57 provides: no administrative fines for violations occurring in the sandbox when the provider followed the approved sandbox plan and the competent authority's guidance in good faith. For an Annex III high-risk AI system, that protection is significant given potential fines of up to 3% of global turnover for non-compliance with Articles 9-15.

Applications may be submitted individually, or jointly with deployers and third parties. The competent authority must notify applicants of its decision within three months. Once approved, participation carries EU-wide legal recognition: testing in Spain's AESIA sandbox is treated as sandbox participation across all Member States.

Article 60 extends the sandbox concept to real-world testing outside the sandbox itself. With market surveillance authority approval and a written testing plan, providers can test Annex III high-risk AI systems in actual operational conditions with real users, subject to informed consent requirements and rights of withdrawal.

The Deadline Update: Digital Omnibus Changes Everything

The brief for this post was drafted with August 2, 2026 as the sandbox establishment deadline. That date has changed.

On May 7, 2026, the Council of the EU and European Parliament reached a provisional agreement on the Digital Omnibus simplification package for the EU AI Act. The Council gave its final confirmation June 29, 2026. Key deadline shifts:

| Obligation | Original Deadline | Revised Deadline | |---|---|---| | Member State sandbox establishment | August 2, 2026 | August 2, 2027 | | Annex III standalone high-risk AI compliance (Articles 9-15) | August 2, 2026 | December 2, 2027 | | Annex I embedded product AI compliance | August 2, 2027 | August 2, 2028 | | Article 50 watermarking obligations | August 2, 2026 | December 2, 2026 (4-month grace) |

The one-year sandbox extension reflects the fragmented state of Member State readiness: as of April 2026, only Spain had an operational sandbox, with five others actively implementing and 16 Member States having communicated no plans.

However, the deadline extension does not change the calculus for CISOs who want to use the sandbox strategically. Building the Article 9 risk management documentation, Article 15 cybersecurity evidence package, and Article 11 technical dossier takes 6-12 months for complex AI systems. Organizations that start now will reach the December 2027 compliance gate with documented evidence and a regulator-endorsed sandbox exit report. Organizations that wait until late 2027 will face a compressed timeline with limited sandbox capacity.

Spain's AESIA accepted its first cohort of 12 high-risk AI systems from Spanish companies in April 2025 and published 16 practical compliance guides in December 2025 derived from that experience. Non-Spanish EU enterprises can apply to AESIA under the cross-border legal recognition provisions.

Who Qualifies: Annex III High-Risk AI Categories

Sandbox participation is available to providers of Annex III high-risk AI systems and, following the Omnibus, Annex I systems embedded in regulated products. The eight Annex III categories are:

Category 1: Biometrics. Remote biometric identification systems (excluding verification-only), biometric categorization based on sensitive attributes, and emotion recognition systems.

Category 2: Critical Infrastructure. Safety components in managing or operating critical digital infrastructure, road traffic, water, gas, heating, or electricity supply.

Category 3: Education. Systems determining access to educational institutions, evaluating learning outcomes, assessing appropriate educational levels, or monitoring student behavior during tests.

Category 4: Employment. Recruitment, candidate evaluation, and ranking systems. Systems affecting promotions, terminations, task allocation, and performance monitoring.

Category 5: Essential Services. Eligibility assessment for public assistance and healthcare benefits. Credit scoring (excluding fraud detection). Risk assessment and pricing for life and health insurance. Emergency call classification and first response dispatch.

Category 6: Law Enforcement. Risk assessment for criminal victimization, polygraph-type tools, evidence reliability evaluation, recidivism prediction, and profiling during criminal investigations.

Category 7: Migration and Border Control. Security and health risk assessment for migrants, asylum application processing, and border identification systems.

Category 8: Justice and Democratic Processes. Legal research and fact application for judicial authorities. Systems influencing election or voting behavior.

The most common enterprise AI deployments that trigger Annex III qualification are credit scoring models (Category 5b), employment management and recruitment AI (Category 4), biometric workplace access systems (Category 1), and AI safety components in OT/ICS environments (Category 2). For more detail on classification, see our guide to EU AI Act high-risk AI system compliance checklists.

The Security Evidence Package: What Your CISO Must Own

The sandbox application is not a regulatory filing. It is a technical submission that must demonstrate pre-existing compliance foundations. The competent authority reviews whether your system is ready for supervised testing, not whether it is ready to start compliance from scratch.

Article 9: Risk Management Documentation

Article 9 requires a continuous, iterative risk management process spanning the full AI system lifecycle. The documentation your team must produce before submitting a sandbox application includes:

• A formal AI risk register covering "known and reasonably foreseeable risks" including misuse scenarios (not just intended use)
• Severity and likelihood scores for each identified risk
• A mitigation hierarchy: design-based elimination first, then technical controls, then deployer training and documentation
• Testing evidence against "prior defined metrics and probabilistic thresholds" conducted before market placement
• A post-market monitoring architecture showing how field data feeds back into risk identification
• Documented consideration of impacts on persons under 18 and other vulnerable groups
• A residual risk determination with rationale for accepting each remaining risk

The NIST AI Risk Management Framework's GOVERN-MAP-MEASURE-MANAGE functions map cleanly onto these requirements. NIST AI RMF MEASURE subcategories MS-2.5 through MS-2.7 (valid and reliable, safe, secure and resilient) correspond directly to the Article 15 accuracy, robustness, and cybersecurity requirements. If your organization already operates an NIST AI RMF program, the mapping exercise is a documentation task, not a new analytical one.

Article 15: Cybersecurity Technical Controls

Article 15 is the most technically demanding requirement in the high-risk AI stack. The statute mandates that systems be "resilient against attempts by unauthorized third parties to alter their use, outputs or performance by exploiting system vulnerabilities." The text enumerates five specific attack categories that require documented technical countermeasures:

Data poisoning: Attacks targeting the training dataset to embed backdoors or introduce systematic bias. Controls required: verified dataset provenance tracking, anomaly detection on training pipelines, data integrity checksums, and separation of training infrastructure from inference infrastructure.

Model poisoning: Attacks on pre-trained components, including supply chain attacks on foundation models and fine-tuning-time attacks. Controls required: model integrity verification (cryptographic checksums of model weights), provenance documentation for any pre-trained or fine-tuned components, and adversarial testing of fine-tuned variants.

Adversarial examples and model evasion: Inputs crafted to cause incorrect outputs, particularly relevant for classification systems. Controls required: adversarial robustness testing (FGSM, PGD, or equivalent methodologies), documented evaluation results with accuracy-under-attack metrics, and input validation and filtering at inference time.

Confidentiality attacks: Membership inference, model inversion, and sensitive information extraction. Controls required: differential privacy measures where applicable, output filtering for sensitive information, and monitoring for anomalous query patterns suggesting extraction attempts.

Model flaws: Architectural vulnerabilities including prompt injection in LLM-based systems and scope violations in agentic systems. Controls required: red team testing, scope containment for agent-based systems, and prompt injection defenses.

For LLM-based high-risk systems, the OWASP LLM Top 10 (2025 edition) provides a practical taxonomy: LLM01 (Prompt Injection) maps to model flaws, LLM03 (Supply Chain) maps to model poisoning, LLM04 (Data and Model Poisoning) maps to the first two categories, and LLM02 (Sensitive Information Disclosure) maps to confidentiality attacks. Structuring your Article 15 threat model around these categories makes the documentation readable to both regulatory reviewers and technical auditors.

ISO/IEC 27001 combined with ISO/IEC 42001 (AI Management System Standard) is the strongest current certification pathway for demonstrating Article 15 compliance. An active ISO 27001 certification provides the security management baseline; ISO 42001 extends it to AI-specific controls.

Real Failures That Define Article 15 Requirements

Article 15's attack categories are not hypothetical. These documented incidents represent the failure modes the regulation was written to prevent.

CVE-2025-53773: GitHub Copilot prompt injection enabling remote code execution (CVSS 9.6). Disclosed in August 2025, this attack embedded malicious instructions in source code comments, GitHub issues, and web content that the Copilot agent ingested. The instructions caused the agent to modify .vscode/settings.json to activate auto-approve mode, disabling all user confirmations for shell command execution. The attack was wormable: the modified configuration could propagate to other developers via shared repositories. This is a textbook Article 15 model flaw failure. See the NVD entry for CVE-2025-53773 for technical detail.

CVE-2025-32711: EchoLeak (Microsoft 365 Copilot). A zero-click prompt injection vulnerability allowed hidden instructions embedded in documents and emails to silently exfiltrate enterprise data from the model's context. No user action was required. This is an Article 15 Category 4 confidentiality attack realized in a commercial AI assistant with enterprise data access.

Samsung ChatGPT data leakage (2023). Three incidents in three weeks saw Samsung semiconductor engineers submit proprietary source code, meeting transcripts, and chip yield test sequences to ChatGPT. Once submitted, the data entered OpenAI's training pipeline with no recovery mechanism. This is an Article 10 data governance failure compounded by an Article 15 confidentiality exposure, triggered not by an external attacker but by inadequate deployment governance. Samsung responded by banning external generative AI tools company-wide.

Apple Card credit scoring algorithmic bias (2019). Goldman Sachs's credit assessment algorithm offered significantly higher credit limits to men than to women with equivalent credit profiles. The algorithm excluded gender as a direct input but used proxy variables that correlated with gender. The New York Department of Financial Services launched a formal investigation. Under the EU AI Act, this is a Category 5b Annex III high-risk system with Article 9 risk management failures (failure to identify proxy discrimination) and Article 10 data governance failures (failure to analyze protected-class correlates in training features).

These are the scenarios your Article 15 cybersecurity documentation must demonstrate you have tested for, not merely considered.

AESIA: The Reference Sandbox Implementation

Spain's Agencia Española de Supervisión de la Inteligencia Artificial (AESIA) is the only fully operational EU AI Act regulatory sandbox as of July 2026. It launched under a Royal Decree framework on November 10, 2023, predating the EU AI Act's own full applicability. Its first cohort of 12 high-risk AI systems across biometrics, employment, critical infrastructure, machinery, healthcare, and essential services concluded in 2025, and AESIA published 16 practical compliance guides in December 2025 derived directly from that supervised testing experience.

The AESIA guides are organized into two informative guides, 13 technical requirement guides (covering risk management, data governance, transparency, cybersecurity, robustness, demographic bias, error rates, and human oversight), and one conformity assessment compliance checklist. While non-binding, these guides represent the most concrete implementation precedent currently available in the EU and should be treated as de facto requirements for the first wave of sandbox submissions.

Non-Spanish EU enterprises can apply to AESIA under the cross-border legal recognition provisions in Article 58. The competent authority must respond within three months of application submission.

For context on how AI Act obligations interact with incident reporting, see our EU AI Act Article 73 incident reporting CISO guide.

The Parallel Compliance Stack: DORA, GDPR, and AI Act

Financial sector CISOs deploying Annex III high-risk AI systems face three overlapping regulatory frameworks that are each independently demanding. The efficient path is integration, not parallelization.

DORA (Digital Operational Resilience Act, in force January 17, 2025). For banks, insurers, investment firms, and payment institutions, any AI system is an ICT system under DORA. Relevant obligations: the ICT risk management framework (Articles 5-16) requires documented risk assessment of AI systems; threat-led penetration testing (Article 26) requires adversarial testing of significant financial entities at least every three years; and ICT third-party risk management applies if the AI system runs on cloud infrastructure or is procured from a model provider.

DORA's TLPT methodology and Article 15's adversarial testing requirements have substantial overlap. A TLPT engagement scoped explicitly to cover an AI system's Article 15 attack surface generates evidence satisfying both frameworks. The key is specifying the scope to include data poisoning scenarios, model evasion testing, and prompt injection for any LLM components. For more on DORA's AI compliance requirements, see our DORA AI compliance guide for financial services.

GDPR DPIA. High-risk AI processing of personal data at scale triggers a mandatory Data Protection Impact Assessment under GDPR Article 35. For credit scoring, employment, and biometric AI (the highest-volume Annex III categories), a DPIA is almost never optional. The Article 59 sandbox provision is the explicit GDPR bridge: it permits further processing of personal data collected for other purposes within the sandbox for AI development and testing, subject to conditions including data isolation, deletion after use, and a published summary of the project.

Integrated compliance architecture. Rather than running three parallel silos, the most defensible approach is a unified risk pipeline:

• One AI risk register covering Article 9 AI risks, DORA ICT risks, and GDPR personal data risks with explicit cross-references between frameworks
• One vendor record for third-party AI components mapping to the DORA ICT third-party register, Article 11 technical documentation, and GDPR data processor agreements
• One incident triage workflow triggering: DORA's 4-hour initial ICT incident report, GDPR's 72-hour DPA notification, and the Article 73 AI Act serious incident report to the market surveillance authority

See our GDPR compliance guide for AI systems for detail on the data protection side of this stack.

How the Sandbox Connects to CE Marking

For CISOs focused on business outcomes, sandbox participation has a direct commercial payoff: faster, more defensible CE marking.

The conformity assessment pathway for most Annex III categories (points 2-8: employment, credit, biometrics excluding law enforcement, critical infrastructure, education, essential services) is an internal control procedure under Article 43 and Annex VI. No mandatory third-party notified body is required. But the Article 11 technical documentation must be complete and credible because the market surveillance authority can demand it at any time.

The competent authority's exit report from sandbox participation provides:

• Written proof of activities carried out and outcomes documented under direct regulatory supervision
• Tested evidence satisfying the "prior defined metrics and probabilistic thresholds" requirement under Article 9
• Documented regulatory interpretation of edge cases in your specific system's compliance status
• A reference document for the EU declaration of conformity

For Annex III point 1 biometric systems, Article 43 requires mandatory third-party notified body assessment. For law enforcement AI, the market surveillance authority itself acts as the notified body. The sandbox exit report accelerates both pathways by reducing the notified body's or authority's investigation scope.

SME Provisions: Free Testing With Priority Access

Article 58 is explicit: "Access to the AI regulatory sandboxes is free of charge for SMEs, including start-ups." National competent authorities may recover exceptional costs in a fair and proportionate manner, but the default is zero charge.

Beyond the fee waiver, the SME provisions include priority access consideration in application review, pre-deployment guidance on AI Act implementation, access to standardization documents and certification pathways, connections to European Digital Innovation Hubs, and facilitated access to notified bodies. For an SME developing a high-risk AI system, the regulatory sandbox is effectively a zero-cost conformity assessment rehearsal with the regulator as advisor. The commercial value of a regulator-endorsed test report for customer due diligence and procurement questionnaires is substantial.

Building Your Sandbox Submission: The CISO Checklist

Based on AESIA's published compliance guides and the Article 57-60 framework, these are the concrete actions to start now:

Classify all deployed and in-development AI systems against Annex III. The classification exercise itself surfaces risk management gaps.

Commission an Article 15 adversarial assessment. You need tested evidence, not threat model documentation alone. Red team results, adversarial robustness benchmarks, and prompt injection test outcomes are the minimum standard.

Build the Article 9 risk register. Identify risks, score them, document mitigations, and establish your residual risk rationale. Map to NIST AI RMF MEASURE subcategories.

Audit your logging architecture. Article 12 requires automated event logging built into the system. If you cannot produce a complete audit trail of model inputs, outputs, and decision events, you cannot enter the sandbox.

Contact your national competent authority or AESIA. Applications are open. A preliminary engagement call before formal submission is standard practice and not counted against the 3-month decision clock.

Align the DORA TLPT scope. If you are a financial entity subject to DORA, ensure your next TLPT engagement covers the Article 15 attack categories explicitly. The test results serve both frameworks.

Conclusion

EU AI Act regulatory sandboxes under Articles 57-60 are the most valuable compliance tool that most CISOs are not using yet. They provide supervised pre-market validation, protection from fines during testing, a regulator-endorsed exit report that accelerates conformity assessment, and free access for SMEs. The Digital Omnibus extended the Member State establishment deadline to August 2027, but Spain's AESIA is operational today and the December 2027 Annex III compliance deadline means the security evidence package needs to be built now.

The security work is not trivial. Article 15 requires tested, documented cybersecurity controls covering data poisoning, model poisoning, adversarial examples, confidentiality attacks, and model flaws including prompt injection. CVE-2025-53773, EchoLeak, and the Samsung incident are not cautionary tales from a distant threat landscape: they are the exact attack patterns regulators expect to see in your threat model and test evidence.

Start with the classification exercise, commission the adversarial assessment, and engage your national competent authority. The organizations that participate in the sandbox cohort actively being formed right now will reach the 2027 compliance deadline with documented evidence, regulatory relationships, and a CE marking pathway that competitors who waited will be scrambling to replicate.

Ready to build your Article 15 security evidence package? Book an AI security assessment to start the sandbox preparation process.

For related reading, see our full EU AI Act compliance guide for SMBs and the EU AI Act high-risk AI systems checklist.

References:

• EU AI Act Article 57: AI Regulatory Sandboxes
• EU AI Act Article 15: Accuracy, Robustness and Cybersecurity
• NIST AI Risk Management Framework 1.0
• OWASP Top 10 for LLM Applications 2025
• NVD: CVE-2025-53773