Chapter VI of the EU AI Act is where Brussels attempts something unusual for a regulatory text — it tries to be helpful. What it reveals about the law’s architecture, its blind spots, and its real-world friction is worth examining carefully.
The EU AI Act is, by design, a demanding piece of legislation. It classifies AI systems by risk, imposes substantial compliance obligations on developers and deployers, and carries significant penalties for non-compliance. But embedded within its twelve chapters is a section that reads differently from the rest — Chapter VI, titled “Measures in Support of Innovation,” covering Articles 57 through 63.
This is where the regulation acknowledges what its critics have been saying all along: that compliance obligations, if poorly designed, can crush the innovation they’re meant to govern. Chapter VI is the EU’s answer to that critique. Whether the answer is adequate is a different question.
What Chapter VI Actually Does
At its core, Chapter VI creates two things: a framework for regulatory sandboxes, and a set of accommodations for smaller operators. Neither is revolutionary, but both matter practically.
Regulatory sandboxes
Regulatory sandboxes (Articles 57 and 58) are controlled environments established by national authorities where AI developers can build, train, test, and validate innovative systems under regulatory supervision, before those systems are placed on the market. The key word is *before* — sandboxes exist precisely to lower the compliance barrier at the most vulnerable stage of development, when a product is still being formed and full regulatory compliance would be either premature or prohibitively expensive.
Every EU Member State is required to establish at least one national AI regulatory sandbox by 2 August 2026. The Act sets minimum standards for how they must operate — they must be time-limited, accessible to SMEs, free of charge for smaller operators, and governed by a sandbox plan agreed between the participant and the authority. Within those parameters, Member States have considerable discretion over the specifics: application procedures, selection criteria, duration, sectoral priorities, and the depth of regulatory engagement.
SMEs and startups
For SMEs and startups (Articles 62 and 63), the chapter provides priority access to sandboxes, proportionally reduced conformity assessment fees, simplified documentation requirements for microenterprises, dedicated guidance channels, and an explicit requirement that participation procedures be designed with simplicity in mind. The word “SME” appears 38 times in the full AI Act text — more than “industry” and “civil society” combined — which signals genuine legislative intent, whatever the implementation reality turns out to be.
Download your free AI Act Compliance Tracker for SMEs.
See the AI Act Compliance Tracker for SMEs here to learn what it does.
The Decentralization Question
Because sandboxes are established and operated nationally, a natural question arises: do the 27 Member States simply create 27 different regulatory environments, turning the single market into a patchwork?
The answer is nuanced. The AI Act sets a non-negotiable floor — baseline protections, minimum standards, and accessibility requirements that apply uniformly. The Commission retains the power to issue implementing acts setting more detailed common rules, specifically to prevent excessive fragmentation.
But within that floor, meaningful variation is inevitable and arguably intentional. Member States have an incentive to design attractive, well-resourced sandboxes to draw AI companies to establish their EU presence in their jurisdiction. It is not difficult to anticipate that Ireland — already the EU home of Google, Meta, and Apple, partly through favorable GDPR jurisdiction — will emerge as a competitive sandbox destination. The Netherlands, Germany, and the Nordic countries each have their own advantages to offer.
This is, in effect, regulated competition between Member States — an attempt to capture the efficiency benefits of competitive pressure while containing the risks through minimum standards and Commission oversight. Whether the balance holds in practice depends heavily on enforcement appetite, which varies considerably across the EU.
A Cross-Border Complication
The decentralized model creates a practical complication that the Act doesn’t fully resolve. A company that develops and tests an AI system through an Irish regulatory sandbox, then deploys that system commercially in Germany, transitions from Irish supervision to German market surveillance. The German authority had no involvement in the sandbox process and is not bound by any guidance or informal assurances the Irish authority may have given.
This matters because enforcement culture, interpretive priorities, and regulatory resources vary significantly across Member States. A system that achieved de facto compliance approval through an Irish sandbox process may encounter different expectations when German authorities conduct market surveillance. The Commission’s common implementing rules are meant to create enough mutual recognition to make sandbox outcomes transferable — but how well this works in practice is genuinely uncertain, and will likely remain so until the first cross-border enforcement disputes clarify the landscape.
The Open Source Exemption and Its Complications
Adjacent to Chapter VI, though technically located in Article 2, is a provision closely connected to the innovation agenda: the open-source exemption. Article 2(12) states that the AI Act does not apply to AI systems released under free and open-source licences — unless they are deployed as high-risk systems or fall under the prohibited practices of Article 5 or the transparency obligations of Article 50.
The logic is straightforward: open-source AI is freely available, not commercially deployed in a structured way, and the traditional concept of a “provider” placing something “on the market” doesn’t map cleanly onto a model released for anyone to download and use.
The complication is that the exemption was designed for a version of “open source” that doesn’t quite exist at the frontier of AI development. True open-source software means code, weights, training methodology, and training data are all freely available under a permissive license. In practice, none of the major frontier AI systems meets that standard fully.
Meta’s Llama models release weights and much of the code but do not disclose training data, and carry a license that restricts use by companies with over 700 million monthly active users. DeepSeek’s R1 model, released under the MIT license, comes closest to being one of the more open releases, particularly with respect to its permissive license and published weights, and has been one of the most widely discussed open‑weight releases of 2025 — but its training data remains undisclosed. Mistral, the French AI company most vocal about open-source principles, operates similarly. Google’s Gemma releases weights but not training data. OpenAI, despite its name, maintains a predominantly closed model, limiting public access to both weights and training data.
The distinction between “open weights” and “open source” is more than technical pedantry. In the restaurant analogy: open weights gives you the finished dish to take home and adapt; open source gives you the full recipe including where every ingredient came from. Regulators care about the recipe because training data is where bias, copyright infringement, and privacy violations are embedded. A model that only shares its weights but not its training process is harder to audit at root level — which sits uneasily with the transparency rationale that supposedly justifies the open-source exemption in the first place.
The Act’s definitional vagueness on what qualifies as a “free and open-source licence” for AI purposes — the traditional OSI definition wasn’t designed with AI in mind — means that companies can plausibly claim the exemption while maintaining meaningful opacity. The AI Office will need to address this as guidance develops.
One important clarification: the exemption protects the *developer who releases openly*, not the *deployer who uses the model commercially*. A company that picks up an open-source model and integrates it into a hiring process, a credit scoring tool, or a medical diagnostic system faces the full weight of the Act’s high-risk provisions. The exemption is not a compliance pass for business users of open-source AI — a distinction that is not yet widely understood among the SMEs and startups who might assume otherwise.
The SME Reality Gap
The accommodations in Chapter VI exist because legislators recognized that compliance obligations fall disproportionately on smaller operators. The recognition is accurate. The question is whether the accommodations are sufficient.
The evidence so far suggests a significant gap between intent and reality. A survey by the European Digital SME Alliance found that more than 60% of small and medium-sized tech companies feel unprepared for the AI Act’s requirements. The reasons are structural: extensive testing, documentation, and certification requirements demand financial and legal resources that startups and small firms typically don’t have. Compliance costs — including technical upgrades, staff training, and legal consultation — disproportionately burden organizations operating with limited budgets.
Download your free AI Act Compliance Tracker for SMEs.
See the AI Act Compliance Tracker for SMEs here to learn what it does.
The guidance problem has compounded this. The Act’s GPAI obligations were outlined in 2024 but the Code of Practice arrived only in July 2025, weeks before certain obligations became enforceable. For companies that need to plan hiring, data acquisition, and technical roadmaps months in advance, that gap has had real operational consequences. Open letters signed by founders of companies including Mistral and Synthesia urged the Commission to extend timelines, citing unclear rules and insufficient preparation time.
There have been partial responses. Proposed amendments under the Digital Omnibus package would extend certain SME regulatory privileges to small-mid cap companies and shift AI literacy obligations from a hard requirement on individual providers to a softer encouragement framework. Implementation timelines for some high-risk provisions have been pushed back. But the underlying tension — between a regulation designed for a world of identifiable providers deploying structured AI systems, and a reality of fast-moving startups integrating AI tools in complex ways across multiple jurisdictions — has not been resolved.
What Chapter VI Tells Us About the Act’s Architecture
Reading Chapter VI against the rest of the AI Act reveals something important about the regulation’s fundamental design tension. The bulk of the Act treats AI as a product safety problem — it applies the logic of CE marking, conformity assessments, and market surveillance to AI systems, borrowing heavily from the established EU product regulation playbook.
Chapter VI acknowledges that AI development doesn’t quite fit that playbook. Products are relatively stable things that can be tested and certified before market entry. AI systems are iterative, context-dependent, and often difficult to classify until they’re actually deployed. Sandboxes are an attempt to create a space where that iterative reality can coexist with regulatory requirements — but they remain an add-on to a framework that is still fundamentally structured around the product safety model.
Whether that tension produces good outcomes will depend on implementation quality at Member State level, on the Commission’s willingness to develop flexible guidance, and on enforcement authorities developing the technical sophistication to distinguish genuine compliance from box-ticking. None of these are guaranteed.
The AI Act Enforcement Tracker monitors:
• EU-level institutions responsible for AI governance
• national supervisory authorities
• enforcement actions and guidance
• publicly available implementation developments.
Download your free AI Act Compliance Tracker for SMEs.
See the AI Act Compliance Tracker for SMEs here to learn what it does.
The Bottom Line for Operators
For an SME or startup navigating the AI Act, Chapter VI offers real but limited relief. Sandboxes are a genuine opportunity if you’re developing something innovative and can engage with the national authority early — but they require proactive effort and a credible development plan. The SME accommodations are meaningful at the margins but don’t change the fundamental compliance picture for high-risk applications.
For non-EU companies planning EU market entry, the sandbox framework offers an interesting possibility: a supervised development process that builds regulatory relationships and compliance understanding before full market exposure. Combined with the authorized representative requirement, there is a coherent path to EU deployment — but it requires early engagement rather than treating compliance as a post-development step.
And for anyone tempted by the open-source exemption as a compliance shortcut: the exemption lives at the development and release level, not the deployment level. What matters for compliance purposes is not how a model was released but what it does, where, and with what consequences for the people affected by it.
This article draws on the text of Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024. Implementation details and guidance continue to develop — readers are encouraged to monitor the EU AI Office’s publications for the most current position on specific provisions.
