EU AI Act Obligations for Open-Source AI Models Used by Regulated Enterprises
The EU AI Act's open-source provisions are narrow and mostly protect upstream model providers, not the regulated enterprises that deploy, fine-tune or integrate their models. AI systems under free and open-source licences fall outside the Regulation unless they are high-risk, fall under Article 5 or 50, or are placed on the market as such. The exception for general-purpose AI model providers covers only two obligations and never applies to models with systemic risk. Your obligations depend on your role and your use case's risk tier, not on the model's licence.
Building the scope analysis
- The model's licence, and whether weights, architecture information and usage information are public.
- Whether the model is a general-purpose model with systemic risk, which removes the provider's exception.
- The use case's risk tier: prohibited, high-risk, transparency-triggering or other.
- Your role: deployer, provider or other third party, and whether fine-tuning or integration changes it.
- The oversight measures indicated by the provider, and how your organisation implements them.
- Controller and processor roles for any personal data, plus a named owner for date and text changes.
Two scoping routes, two sets of conditions
The Regulation contains two distinct open-source provisions, and they should be analysed separately.
The first is an exclusion for AI systems. The Regulation does not apply to AI systems released under free and open-source licences, unless they are placed on the market or put into service as high-risk AI systems, or as an AI system that falls under Article 5 or 50. Open-source licensing of a system therefore gives no relief for prohibited practices, high-risk uses or transparency-triggering uses.
The second is an exception for general-purpose AI model providers. The obligations in paragraph 1, points (a) and (b), do not apply to providers of models released under a free and open-source licence that allows access, usage, modification and distribution, and whose parameters (including weights), model architecture information and model usage information are publicly available. The exception does not apply to general-purpose AI models with systemic risk.
The qualifying conditions are cumulative. A licence that does not meet them, or a model with non-public parameters, does not qualify. The Commission's FAQ also notes that documentation duties apply unless a provider qualifies for the open-source exemption, while the duty to respect EU copyright law is listed without that qualifier. The Commission has issued guidelines on the scope of general-purpose AI provider obligations, including the conditions under which open-source model providers are exempt from certain obligations. They are the right reference when an upstream provider claims the exemption.
What remains by role and use case
The table summarises how the open-source provisions interact with the enterprise's position. It is a starting point for a documented scope analysis, not a substitute for one.
- Provider of an open-source general-purpose model, no systemic risk: May qualify for the exception on points (a) and (b) if the licence and public-availability conditions are met. Copyright measures are not carved out in the Commission's FAQ.
- Provider of a general-purpose model with systemic risk: The exception is unavailable. The Commission's FAQ lists risk assessment and mitigation, state-of-the-art model evaluations, serious incident reporting and cybersecurity.
- Open-source AI system, use case outside Articles 5 and 50 and not high-risk: Outside the Regulation under the system-level exclusion, unless placed on the market as a system in one of the excluded categories.
- Open-source AI system in a high-risk, Article 5 or Article 50 use: The exclusion is lost. The Regulation applies as it would to any other system in that category.
- Enterprise as deployer of a high-risk system: Deployer obligations remain, including human oversight. Data protection obligations as controller or processor continue in parallel.
- Enterprise that modifies or integrates a model: May be treated as a provider of a high-risk system, with Article 16 provider obligations, in certain listed circumstances.
When the enterprise stops being only a deployer
Any distributor, importer, deployer or other third party is considered a provider of a high-risk AI system, and is subject to the provider obligations under Article 16, in certain circumstances listed in the Regulation. Fine-tuning, integration into a product, or putting your own name on a system are the situations compliance teams should test against that provision. The answer depends on the legal text, not on whether the underlying model is open-source.
Recital 89 is often read too broadly. It says third parties making publicly accessible tools, services, processes or AI components under a free and open-source licence should not be mandated to comply with value-chain requirements, in particular towards the provider that used or integrated them. That relief protects the open-source contributor. It excludes general-purpose AI models, and it does not reduce what the integrating enterprise owes.
Deployer duties are separate from model-provider duties. The human oversight obligations are without prejudice to other deployer obligations under Union or national law, and to the deployer's freedom to organise its own resources and activities to implement the oversight measures the provider indicates. In practice, you need to know which measures the provider has indicated, decide how your organisation implements them, and be able to show that implementation. The Regulation also does not displace data protection law, so controller and processor roles stay in force wherever personal data is processed.
Dates to track as of November 2026
As of November 2026, the timing of high-risk obligations is subject to the Digital Omnibus on AI, which the Commission proposed on 19 November 2025. It is described as setting fixed deadlines of 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk AI systems embedded in products.
Council and Parliament reached a provisional agreement on 7 May 2026. It postpones national AI regulatory sandboxes to 2 August 2027 and shortens the grace period for providers to implement transparency solutions for artificially generated content from six months to three, with a new deadline of 2 December 2026. A consolidated version of the Regulation dated 27 July 2026 is published on EUR-Lex.
Because these dates can change as the amendments progress, the register of obligations should name an owner and a review date. Transparency-triggering use cases involving generated content are the nearest planning item.
Evidence and runtime enforcement at Trussed
A policy document states intent. A regulator assessing a deployer is better served by evidence of what the system was permitted to do and what happened in production, particularly where oversight measures are meant to operate on individual interactions and tool calls. This is a general architectural point: controls enforced in the execution path produce evidence as a by-product, while controls reviewed after the fact depend on reconstruction.
Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Each interaction or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval, enforced at runtime rather than reviewed after the fact. That enforcement generates continuous audit-ready evidence mapped to the EU AI Act, among other frameworks. Deployment is self-managed in the customer cloud, with configurable retention and data residency.
This addresses the deployer side: how open-source models were permitted to behave in production. It does not replace the scope analysis above, and it does not address model-provider obligations.
Obligations follow role and risk tier
1. Classify the use case
Prohibited, high-risk, transparency-triggering or other.
2. Identify the model's role
General-purpose AI model or AI system, and whether it carries systemic risk.
3. Fix your own role
Deployer, provider or other third party.
4. Map and evidence duties
Separate provider-side controls from deployer-side controls.
Show regulators how your models were permitted to behave
Talk to an expert about enforcing policy in the execution path and producing audit-ready evidence for EU AI Act reviews.
Talk to an Expert