EU AI Act and Open-Source AI Models: How the Regulation Treats Open-Source AI

The EU AI Act does not treat open-source AI as a single, uniform category. It carves out two distinct regimes — one for open-source AI systems under Article 2, and one for open-source GPAI models under Article 53(2) — and each has hard limits that open-source status cannot cross. Releasing your model or system under an open-source licence reduces your paperwork. It does not exempt you from the prohibitions, does not rewrite the high-risk rules when your system lands in Annex III, and does not lift the systemic-risk obligations for GPAI models that breach the compute threshold.

This article explains both carve-outs in full, draws the limits precisely, and covers the live debate over what "free and open-source" actually means under the Act.

Two Separate Carve-Outs: AI Systems vs. GPAI Models

The Act distinguishes between an AI system (a product with a specific output — a prediction, a recommendation, a decision) and a GPAI model (a general-purpose model trained on large volumes of data, capable of a wide range of tasks, placed on the market for integration by others). The open-source rules for each are different, and conflating them is the most common error in this area.

Carve-out 1: Open-Source AI Systems (Article 2)

Article 2 defines the scope of the Regulation. Under Article 2(12), AI systems released under free and open-source licences are generally excluded from the main body of obligations — with three explicit exceptions:

1. Prohibited practices (Article 5) — the prohibitions apply regardless of licence. A system designed for real-time remote biometric identification in public spaces, or for subliminal manipulation, or for social scoring, is prohibited whether its weights are public or not.
2. High-risk systems (Article 6 + Annex III) — if a system is used in an Annex III context (recruitment, creditworthiness, biometric identification, law enforcement, and the other six areas), the full high-risk obligation stack applies: risk management under Article 9, data governance under Article 10, technical documentation under Article 11, logging under Article 12, transparency to deployers under Article 13, human oversight under Article 14, accuracy and robustness under Article 15, and conformity assessment under Article 43 before the system goes to market.
3. Transparency obligations (Article 50) — limited-risk transparency duties (disclosing AI interaction for chatbots, labelling synthetic content, and similar) apply from 2 August 2026 regardless of licence.

In short: open-source removes most of the regulatory overhead for systems that are minimal-risk. The moment the system operates in a prohibited or high-risk context, the licence is irrelevant.

Carve-out 2: Open-Source GPAI Models (Article 53(2))

Article 53(1) imposes four baseline obligations on all GPAI model providers: (a) prepare and maintain technical documentation under Annex XI; (b) provide downstream AI system providers with information under Annex XII; (c) maintain a copyright compliance policy for training data; and (d) publish a sufficiently detailed summary of training data used.

Article 53(2) grants providers of GPAI models released under a free and open-source licence an exemption from obligations (a) and (b) — the technical documentation and downstream-information duties — subject to two conditions being met:

• The weights, architecture, model specifications, and usage information are all publicly available.
• The licence under which the model is released genuinely permits public access, use, modification, and distribution.

What the Article 53(2) exemption does NOT remove:

• The copyright compliance policy obligation (Article 53(1)(c)) remains. Every GPAI model provider, including open-source ones, must have and implement a documented policy for complying with EU copyright law, including the opt-out mechanism under the Copyright in the Digital Single Market Directive.
• The training-data summary obligation (Article 53(1)(d)) remains. Open-source providers must still publish a sufficiently detailed summary of what the model was trained on.
• If the model is designated as a systemic-risk model under Article 51 — based on a training compute threshold exceeding 10²⁵ FLOPs, or by Commission decision — the full Article 55 obligations apply in addition: model evaluation and adversarial testing, systemic-risk assessment, incident reporting to the European Commission, and cybersecurity measures. Open-source status does not change this. The societal risk posed by a highly capable model is not reduced by making its weights public.

The GPAI obligations under Chapter V have applied since 2 August 2025.

What "Free and Open-Source" Actually Means Here

The Act does not adopt a formal definition of "free and open-source licence" and does not reference the Open Source Initiative definition. The operative requirement in Article 53(2) is that the weights, architecture, and usage information are publicly available under a licence permitting use, modification, and distribution.

This is where a live and unresolved debate sits. Licences that include use restrictions — for example, a licence that prohibits commercial use above a certain scale, restricts certain application categories, or requires the licensor's permission for specific deployments — may not satisfy the public availability test. The Llama licence family (versions 2 and 3) introduced provisions that restrict some forms of use; whether those provisions disqualify a model from the Article 53(2) exemption is not yet settled.

Providers releasing models under custom licences with carve-outs should not assume they qualify for the exemption without legal analysis of the specific licence terms. The AI Office will be central to developing guidance here, but as of mid-2026 that guidance is not yet published.

Permissive licences — Apache 2.0, MIT, and similar — present no obvious difficulty for the exemption test.

The Critical Downstream Point: Exemptions Don't Travel

The Article 53(2) exemption belongs to the entity releasing the model weights. It does not pass to companies that take those weights and build a product.

If you use an open-source GPAI model — Mistral, Falcon, a fine-tuned Llama derivative — to build an AI system, you are the provider of your own AI system under Article 3(3). Your system is classified by what it does, not by what model it runs on. If your system operates in an Annex III domain, you are the provider of a high-risk AI system and the obligations under Articles 9–15, 17, 43, 47, 48, 72, and 73 attach to you — regardless of what exemptions apply to the underlying model provider.

A concrete example: a company uses open-source model weights to build a CV-screening system that automates shortlisting for employment decisions. CV screening for employment falls under Annex III, point 4. The company is the provider of a high-risk AI system. The full high-risk stack applies: a risk management system (Article 9), documented data governance (Article 10), technical documentation per Annex IV (Article 11), human oversight measures (Article 14), and a conformity assessment under Article 43 before the product goes to market. The model provider's open-source status is immaterial to this company's obligations.

A practical consequence follows from this: the information that an open-source GPAI provider is not required to publish — the Annex XII downstream documentation — is information the downstream high-risk provider still needs. If the base model has no published capability specifications, known limitations, or performance disparities, you must obtain or reconstruct that information yourself to populate your Article 9 risk management system and Article 11 technical file. Model cards and research papers are the starting point; they are rarely sufficient on their own.

Fine-Tuning: Who Becomes What

Fine-tuning raises a classification question that depends on what the fine-tuning produces.

Fine-tuning that produces a specific-purpose AI system — LoRA adaptation, domain-specific instruction tuning, prompt-layer customisation — results in a system classified by its intended use. The fine-tuner is the provider of that system. If it operates in an Annex III context, the high-risk obligations attach. Article 3(23) defines substantial modification.

Fine-tuning at a scale that produces a new general-purpose model — broadly capable of a wide range of tasks — could make the fine-tuner a GPAI model provider in their own right. Standard fine-tuning involves orders of magnitude less compute than pre-training; crossing the 10²⁵ FLOP threshold through fine-tuning alone is unlikely for most organisations. For teams conducting large-scale post-training work, the question is worth a direct assessment.

Releasing a Model: What Remains After the Exemption

If you qualify for the Article 53(2) exemption, your residual obligations are:

Copyright compliance policy. Documented and implemented, covering the TDM opt-out mechanism. Not optional for any GPAI provider.

Training-data summary. A sufficiently detailed public summary of training data used. The Act does not specify the exact format; AI Office guidance will develop this further.

Self-assessment of systemic-risk status. If training compute exceeds 10²⁵ FLOPs, notify the AI Office and comply with Article 55 in full. Open-source status is no defence.

Article 5 compliance. The prohibitions apply. If your model, as released, is specifically designed to enable a prohibited practice, you carry liability regardless of who ultimately deploys it.

Licence design. A well-designed licence documents the model's intended purpose, identifies uses prohibited under Article 5, and sets expectations about what capability documentation the downstream provider must assemble (since you are not producing Annex XII material). None of this substitutes for regulatory compliance, but it reduces indirect contribution to prohibited downstream uses.

Practical Approach by Scenario

You are releasing open-source model weights. Verify your training compute and confirm whether the 10²⁵ FLOP systemic-risk threshold applies. Implement a copyright compliance policy before release. Publish a training-data summary. Review your licence terms to confirm they satisfy the Article 53(2) public-availability test. If your compute is below the threshold, the Annex XI and Annex XII documentation obligations are waived; everything else applies.

You are building a product on an open-source model. Classify your product under Article 6, not the base model. If the product operates in an Annex III domain, the full provider high-risk stack applies to you. Source what base-model documentation exists — model cards, published evaluations, benchmark results — and use it as the starting point for your Article 9 risk management system and Article 11 technical file. Do not assume the open-source provider's exemption extends to your product.

You are fine-tuning for internal deployment. You are the provider of the fine-tuned system. If the internal deployment falls into an Annex III domain, high-risk obligations apply — including to internal-use AI systems, which fall within the Act's scope under Article 3(3). Document the fine-tuning methodology, the changes from the base model, and the resulting system's capabilities and limitations.

You are offering hosted access to an open-source model. There is a relevant legal distinction between making weights available (the open-source release act, covered by the exemption) and operating the model as a service accessible to third parties. Hosted services — API wrappers, managed inference endpoints, Ollama-based services — may engage GPAI obligations for the service operator. The compliance analysis turns on whether the operator is acting as a GPAI model provider, a deployer of a GPAI model, or a provider of a specific AI system built on the model.

How Confir Helps

Confir's Article 6 classification engine applies to your system, not to the base model. You describe what your system does and where it operates; Confir's rule-based logic determines the risk tier and your role under the Act — and flags where the open-source exemption reaches and, critically, where it does not.

If your system is high-risk, the AIRC module walks you through the provider obligation stack: Article 9 risk management, Article 11 technical documentation, Article 14 human oversight, and Article 43 conformity assessment. The output is a structured technical file and a Declaration of Conformity under Article 47, tailored to your system's architecture and base-model context.

Related guides

• Open-source AI exemptions: where the limits are
• GPAI model compliance under Article 53
• Article 6: how high-risk classification works
• Provider obligations under Article 16

Frequently Asked Questions

Does releasing model weights under an open-source licence exempt an AI system from the EU AI Act?

Only partially, and only for minimal-risk use cases. Article 2(12) excludes open-source AI systems from most obligations, but not from the Article 5 prohibitions, not from the high-risk obligations when the system operates in an Annex III domain, and not from the Article 50 transparency duties (which apply from 2 August 2026). For systems that are not prohibited and not high-risk, open-source status effectively removes the regulatory overhead. For anything above that threshold, the licence is irrelevant to the obligation.

What obligations does an open-source GPAI model provider still carry after the Article 53(2) exemption?

Two remain: a copyright compliance policy covering training data (Article 53(1)(c)) and a sufficiently detailed summary of training data used (Article 53(1)(d)). The exemption waives technical documentation under Annex XI and downstream-information obligations under Annex XII. Separately, if the model exceeds the systemic-risk compute threshold (10²⁵ FLOPs), the full Article 55 obligations apply regardless of open-source status.

If I build a product on Mistral or Llama, do I inherit the open-source exemption?

No. The exemption belongs to the entity releasing the model weights. You are the provider of your own AI system, classified by what your system does. If your system operates in an Annex III domain, you face the full provider high-risk stack — Articles 9–15, 17, 43, 47, 48, 72, and 73 — irrespective of the base model's licence.

Does a licence with use restrictions qualify for the Article 53(2) open-source exemption?

This is not yet settled. The Act requires that the licence permit use, modification, and distribution without conditions. Licences that restrict commercial use above a certain scale, prohibit specific application categories, or require licensor permission for certain deployments may not satisfy the public-availability test. Legal analysis of the specific licence terms is required. Apache 2.0 and MIT present no obvious difficulty; custom licences with use carve-outs need scrutiny.

When do GPAI model obligations apply?

Chapter V obligations — covering all GPAI providers, including open-source ones for the duties that remain — have applied since 2 August 2025. The Digital Omnibus deferral (which pushed the high-risk Annex III deadline to 2 December 2027) does not affect Chapter V. GPAI providers whose models were on the market before 2 August 2025 have until 2 August 2027 to comply.

---

Last reviewed 1 June 2026.