Does the EU AI Act Apply to Open-Source AI? What's Exempt and What's Not

One of the most persistent myths in the EU AI Act discourse is that open-source AI is exempt. It is not — at least not in the way most developers assume. The Act does carve out limited exemptions for certain open-source activities, but the boundaries are much narrower than the headlines suggest.

The common misconception

The misconception goes like this: "I'm using an open-source model, so the EU AI Act doesn't apply to me." This is wrong for two reasons. First, the exemption applies to a very specific definition of open-source activity, not to every use of an open-source model. Second, even where exemptions exist, they cover the model provider's obligations — the deployer's obligations remain fully intact.

If you download Llama, Mistral, or any other open-source model and integrate it into a product that serves EU users, you are a deployer (and potentially a provider) under the Act. The model's license does not affect your regulatory status.

What's actually exempt

The EU AI Act exempts AI systems used exclusively for:

• Scientific research and development. AI used purely for research purposes, not deployed to end users or put on the market, is exempt. The moment it moves beyond research into a product, the exemption ends.
• Personal, non-professional use. If you run an AI model at home for personal use, the Act does not apply. This is similar to how GDPR exempts purely personal data processing.
• Pre-market development. AI systems being developed and tested before market placement are exempt during the development phase, though testing on real users may trigger obligations.

These exemptions apply to any AI system, not just open-source. There is no special "open-source exemption" category in the Act — the carve-outs are activity-based, not license-based.

Open-source GPAI models

The Act does create a lighter regime for open-source general-purpose AI (GPAI) models. Under Articles 52–55, GPAI model providers must normally comply with transparency obligations including technical documentation, training data summaries, and copyright compliance.

For GPAI models released under open-source licenses (as defined by the Act — model weights, architecture, and training methodology must be publicly available), providers get a reduced set of requirements:

• Still required: Publish a sufficiently detailed summary of training data content, following a template published by the AI Office. Comply with EU copyright law.
• Reduced: Lighter technical documentation requirements compared to proprietary GPAI providers.
• Exception to the exception: If the open-source GPAI model is classified as posing "systemic risk" (based on compute thresholds), the full GPAI provider obligations apply regardless of license. This captures models like the largest Llama variants.

Using open-source in high-risk systems

This is where most companies trip up. If you take an open-source model and deploy it in a high-risk context — HR screening, credit scoring, medical diagnostics, law enforcement — you are the provider of a high-risk AI system. All 11 high-risk obligations apply to you, in full.

The fact that the underlying model is open-source does not reduce your obligations. You must:

• Complete Annex IV technical documentation for the entire system, including the open-source model component
• Conduct risk management that covers the model's known limitations and failure modes
• Validate accuracy and bias across relevant demographic groups — even if the model provider didn't do this
• Build human oversight controls
• Complete a conformity assessment and register in the EU database

In practice, using an open-source model in a high-risk system can be harder to comply with than using a commercial model, because commercial providers often supply documentation, bias testing results, and technical specifications that you can build on. With open-source, you may need to produce all of this yourself.

Practical guidance

• Classify first. Determine whether your use case is high-risk, limited risk, or minimal risk. The model's license is irrelevant to this classification — it's about what the system does, not how it's built.
• Document the model. Even if the model provider hasn't published detailed documentation, you need to document the model's architecture, training data (to the extent known), performance characteristics, and known limitations in your Annex IV technical file.
• Own the compliance burden. Don't assume the model provider has handled compliance for you. Open-source model providers have minimal obligations. As the deployer and/or provider of the final system, the obligations fall on you.
• Test for your context. A model that performs well in general may have significant biases or accuracy gaps in your specific use case. Conduct validation testing tailored to your deployment context, user population, and data distribution.
• Track model updates. Open-source models evolve rapidly. If you update the underlying model, you may need to re-validate performance, update documentation, and potentially re-do conformity assessment. Build this into your post-market monitoring process.

The transparency deadline is 73 days away. If you are using open-source AI in a product that serves EU users, classify your system now to understand your obligations. The license on the model does not determine your compliance requirements — the use case does.