Open-source AI models under the EU AI Act: what stays covered

Does the EU AI Act exempt open-source AI models?

The exemptions are partial. Article 2(12) excludes AI systems released under free and open-source licenses, but only if they are not placed on the market or put into service as high-risk systems and do not fall under Article 5 or Article 50. Article 53(2) relieves providers of free and open-source models with public weights, architecture and usage information from the two technical documentation duties in points (a) and (b), but it does not remove the copyright policy duty, and it does not apply where the model has systemic risk. If your team releases or uses open-weight models, the answer depends on four things: your role (provider, deployer or both), the license, whether the weights, architecture and usage information are public, and whether the model is classified as presenting systemic risk.

Work through those four questions in order and record each answer. Confirm the license terms with counsel, because a license that restricts commercial use or adds usage conditions may fall outside what the exemption assumes. Check whether any high-risk use case applies to your system, since the Article 2(12) carve-out disappears in that case. Then document the reasoning, so an assessor or market surveillance authority can see how you reached your position. Note that the AI Act's open-source relief is not a self-certification of compliance: the organization owns its compliance decisions, an implementation partner can prepare the inventory, license records and technical files that support them, and only an independent auditor, assessor or other competent body issues reports or certificates.

Do not assume that publishing weights removes your obligations. A provider that releases a model openly still needs a copyright policy, and a provider of a general-purpose model that is not covered by the exemption must still publish the training content summary required by Article 53(1)(d), which the open-source exemption does not reach. Ask your legal and compliance leads to confirm which of these duties apply to each model in your portfolio, and to confirm the current status of the systemic risk threshold with the AI Act consolidated text before you plan releases.

Where the open-source exemptions stop

The AI Act's open-source provisions are narrower than their headline suggests. Each exemption has explicit exceptions for high-risk use, prohibited practices, transparency duties, systemic risk and written supply-chain obligations. Read the four limits below together with counsel before assuming a model or component sits outside the Act.

Open-source AI systems stay in scope

Article 2(12) excludes AI systems released under free and open-source licenses, but only up to a point. The exclusion does not apply if the system is placed on the market or put into service as a high-risk system, if it falls under Article 5 (prohibited practices), or if it falls under Article 50 (transparency duties). A free license therefore does not settle the question. Map each deployment to its use case and confirm with counsel whether the use is high-risk, prohibited or subject to transparency rules.

Article 53(2) covers only two duties

The open-source exemption for general-purpose AI models in Article 53(2) relieves providers only from the technical documentation duties in points (a) and (b). It does not relieve them from the copyright policy, and it does not relieve them from publishing the training content summary under Article 53(1)(d). Teams that release open weights often assume the whole Article 53 set is waived. Check which documents you still owe and who maintains them after each release.

Systemic risk removes the exemption

Free and open-source models with public weights, architecture and usage information are exempt under Articles 53(2) and 54(6) only if they do not present systemic risk. A model that presents systemic risk loses the exemption entirely, including the authorised representative relief. Article 51(2) presumes high-impact capabilities above a cumulative training compute of 10^25 floating point operations, and the Commission has said that threshold is under review. Estimate your compute early and monitor the Commission's position.

Article 25(4) rarely reaches open-source tools

Article 25(4) requires providers and third parties supplying AI systems, models, tools, services, components or processes to agree in writing the information, technical access and assistance a high-risk deployment needs. The rule does not apply to free and open-source tools other than general-purpose AI models. Open-source components therefore often lack a contractual handover, so the deployer must gather the information itself. Confirm which components in your stack are covered and document what you obtained for each.

Which duties still apply to open-weight model providers

The open-source exemption for general-purpose AI models is narrower than it sounds. Under Article 53(2), a model released under a free and open-source license with public weights, architecture and usage information is exempt only from the technical documentation and downstream documentation duties in points (a) and (b). It is not exempt from the copyright policy in Article 53(1)(c) or the public training content summary in Article 53(1)(d). If your model presents systemic risk, the exemption falls away entirely. Confirm the model's license and whether its compute places it above the presumption threshold before you rely on any exemption.

The copyright policy is an internal document that you own. It should describe how you identify and respect rights reservations, including machine-readable opt-outs, and how you handle complaints from rights holders. An assessor or the AI Office will ask for the current version, its approval history, and records showing the processes it describes actually ran during training data collection. The training summary follows the template the AI Office published on 24 July 2025 and must be drawn up and published, not kept internal. Its purpose is to let rights holders and the public see the main data sources and categories used, so the document must be accurate, versioned, and posted where the public can reach it.

Your evidence file should hold the approved copyright policy, the data source register that feeds the summary, the crawler and opt-out handling logs for any web-scraped data, and the published summary with its date and version. For self-hosted training pipelines, confirm which team owns each data source and who signs off the summary before publication. Ask your counsel whether the summary must be updated when you retrain or fine-tune, because that decision determines how often the document and its evidence must be refreshed.

When systemic risk removes the open-source relief

The open-source relief in Articles 53(2) and 54(6) does not survive systemic risk. A free and open-source model with public weights, architecture and usage information is exempt from the technical documentation duties and the authorised representative duty only while it does not present systemic risk. Once a model is designated as carrying systemic risk, the full set of general-purpose AI model obligations applies to its provider, whatever the licence says. The practical first step is to decide whether any model you release or fine-tune could reach that status, because the answer changes your documentation, staffing and budget.

Article 51(2) presumes that a model has high-impact capabilities, and therefore systemic risk, when its cumulative training compute exceeds 10^25 floating point operations. That figure is the number the reader should check first. The Commission's general-purpose AI factpage states that the threshold is under review, and Article 51(3) allows the Commission to amend it by delegated act. Before planning, confirm the current value and any amendment on the Commission's pages, and record the compute you used for each training run, including continued pre-training and large fine-tunes, so you can show which side of the line each model falls on.

The threshold is a presumption, not the whole test. Annex XIII lists criteria the Commission considers when designating a model, such as the number of parameters, the quality or size of the dataset, the input and output modalities, benchmarks and the model's reach among business and consumer users. A provider below the compute figure can still be designated, and the Commission can act on its own assessment or a qualified alert. Ask counsel or your compliance lead to document a reasoned view on each criterion for every open-weight release, and watch the Commission's general-purpose AI obligations factpage for changes before each release date.

Open-source components in your value chain

If your organization publishes a general-purpose AI model with public weights, architecture and usage information, you are the provider of that model. Article 53(2) and Article 54(6) relieve free and open-source models from the technical documentation duties and the authorised representative requirement, but only if the model does not present systemic risk. The copyright policy and the public training content summary still apply, and the exemption does not reach them.

Exemption limits: The exemption covers the documentation duties in points (a) and (b) only. Check the presumption in Article 51(2) against your cumulative training compute, because a model above the threshold may be treated as having systemic risk.
Copyright policy: Maintain and publish a copyright policy that respects EU copyright law, including rights reservations.
Training summary: Publish a summary of training content using the template the AI Office provides, as Article 53(1)(d) requires.
Downstream information: Give integrators the information and assistance they need through the written arrangements described in Article 25(4), where applicable.
Systemic risk: If the model is designated as presenting systemic risk, the exemption falls away and the full obligations apply.

Confirm your model's compute figures and designation status with counsel before relying on the exemption.

How to plan open-source model compliance

This sequence takes an organization from confirming its AI Act role to a file of evidence that shows which open-source exemptions apply and which duties remain. Each step closes with a named output that the next step depends on.

Confirm your role along the value chain
Start by establishing whether you are a provider, a deployer, or both for the model or system in question. Check whether you placed the model on the EU market, built a system on top of it, or only use it internally, since Article 2 ties the Act's reach to the market placement and the EU use of AI output. Legal or compliance leads should own this decision, with engineering confirming how the model is hosted and modified. The output is a short written role statement for each model and system, signed off by the accountable owner.
Check the license and public disclosures
Read the license terms of the model and any accompanying weights, architecture and usage documentation. The exemptions in Articles 53(2) and 54(6) depend on a free and open-source license with public weights, architecture and usage information, so a license that restricts commercial use or omits usage information may remove the exemption entirely. Record exactly what the publisher makes public and where it is published. The output is a license and disclosure register entry for each model, with the version and retrieval date.
Test whether the model presents systemic risk
Determine whether the model could be designated as presenting systemic risk, because that status removes the open-source exemptions even when the license and disclosures are in order. Compare the training compute against the presumption threshold in Article 51(2), noting that the Commission has said this threshold is under review, and assess the model against the criteria in Annex XIII. Where the result is uncertain, confirm the current position with the AI Office and the Commission's general-purpose AI guidance rather than relying on an internal estimate. The output is a documented systemic risk assessment with the sources consulted.
Assemble the copyright policy
Prepare a copyright policy covering how the provider complies with EU copyright law, including the handling of text and data mining opt-outs, and keep it current as the model changes. The open-source exemption covers only the technical documentation points, so this duty applies even when the model is fully exempt from them. Legal counsel drafts the policy and the model team confirms the practices it describes are true. The output is a dated, published copyright policy linked to each model in the register.
Prepare the public training data summary
Draft the sufficiently detailed summary of the content used for training, using the template the AI Office provided, and do not treat the open-source exemption as covering it. Data engineers list the data sources, categories and processing steps from training records, and legal reviews the wording before publication. Ask the team to confirm whether any training data cannot be described in the template's categories, because gaps must be explained rather than omitted. The output is a published training summary matched to the exact model version it describes.
Record information from upstream suppliers
Where your system or model incorporates third-party components, datasets, or base models, agree in writing the information, technical access and assistance you need from each supplier, as Article 25(4) describes. Note that this requirement does not apply to free and open-source tools other than general-purpose AI models, so check the scope of each component. Procurement and legal teams own the written agreements, and engineering maintains the bill of materials. The output is a supplier register with the signed information terms and the component versions they cover.
Obtain an independent scope review
Where the role, the exemption or the systemic risk result is contested or high-stakes, ask an independent reviewer outside the project team to test the scope decisions against the register. An external lawyer or consultant can challenge the reasoning, but only the organization decides its obligations, and no reviewer issues a certificate under this Act for these duties. Ask for a written review that states its assumptions, the sources it relied on, and open questions. The output is a dated scope memo, filed with the evidence, that the accountable owner accepts or revises.

What to have in place before you rely on the exemption

The open-source exemptions only hold if the release facts are true and provable. Each card below is a record an assessor or the AI Office can ask for, and together they show that the license, the public information and the remaining duties line up before you publish or deploy a model.

License and release records

Keep the exact license text, the version or commit it applies to, and the date each model artifact was published. The exemption depends on a free and open-source license, so check that the license permits use, modification and redistribution without fees or field-of-use limits that would make it closed in practice. Confirm the license covers the weights, not only the code, and that any custom or restrictive terms are read against the model release itself.

Model card and usage information

The exemption requires public weights, architecture and usage information. Publish a model card that describes the architecture, the parameter layout, intended uses and known limits, and link it to the weights. Check that the card is public, versioned with the release, and matches the weights you actually distribute, because a card that describes a different checkpoint undermines the exemption.

Training data provenance notes

Record where each training dataset came from, under what terms it was obtained, and how it was filtered or deduplicated. These notes are the working source for the public training summary and for your copyright policy. Check that every source has a documented basis for use, and flag any dataset whose rights status you cannot establish so it is resolved before publication.

Copyright policy

The exemption does not remove the duty to maintain a copyright policy. The policy should explain how you respect text and data mining opt-outs, how rights holders can raise concerns, and how your crawling and collection practices are controlled. Check that the policy is written, published, approved by someone accountable, and reviewed each time you retrain or add a data source.

Published training summary draft

Article 53(1)(d) requires a sufficiently detailed public summary of training content, prepared according to the template the AI Office provides. Open-source providers cannot skip it. Draft the summary alongside the dataset notes, map each data category to the template fields, and check that nothing in the draft contradicts the model card or the copyright policy before the first public release.

Systemic-risk compute record

Article 51(2) presumes high-impact capabilities when cumulative training compute exceeds 10^25 floating point operations, and a model with systemic risk loses the open-source exemption. Keep a per-run record of compute used across pretraining, fine-tuning and any other training stages. The Commission says this threshold is under review, so check the current factpage and the delegated act process before concluding that you are below it.

Supplier agreements

Where a third party supplied data, tooling, evaluation services or hosting, Article 25(4) requires written agreement on the information, technical access and assistance needed. Free and open-source tools are generally excluded, but commercial suppliers are not. Check that each supplier contract states what information they provide about their components, who keeps the records, and how you will obtain them if the supplier exits.

Who does what on open-source AI compliance

Your organization remains the provider or deployer in law, so the decisions stay with you. Legal and compliance decide which AI Act role you hold for each model and system, whether an exemption applies, what the copyright policy says, and whether a model presents systemic risk. These are judgments about your products, markets and contracts, and no outside party can take them on your behalf.

Role and scope determination: Confirm whether you are a provider, deployer or both, and whether Article 2 reaches your activity, including non-EU operations whose output is used in the EU.
Exemption analysis: Document whether an open-source exemption in Article 2(12), 53(2) or 54(6) applies, and record the public weights, architecture and usage information that support it.
Copyright policy and training summary: Own the written copyright policy and the published training content summary, which the open-source exemption does not remove.
Written positions and contracts: Approve the information and assistance terms you agree with upstream and downstream parties under Article 25(4) where it applies.
Records of decisions: Keep dated memos explaining each classification, since those memos are what an assessor or authority will ask to see first.

Before relying on any exemption, confirm the current wording of the consolidated text and the Commission's guidance with your counsel.

Questions buyers ask about open-source AI models and the AI Act

Is an open-source AI model exempt from the EU AI Act?

No. An open-source model gets a narrow exemption, not a blanket one. Under Article 53(2), a general-purpose model released under a free and open-source license with public weights, architecture and usage information is exempt from the technical documentation and downstream information duties in points (a) and (b). It is not exempt from the copyright policy or the public training summary, and the exemption falls away entirely if the model presents systemic risk. Open-source AI systems have a separate carve-out under Article 2(12), which does not apply where the system is high-risk or falls under Article 5 or Article 50. Confirm each condition against the license and the model card before you rely on it.

Does fine-tuning an open-weight model change my obligations?

It can. Whether you become a provider depends on how much you modify the model and on what you place on the market or put into service. Fine-tuning that makes you the provider of a general-purpose model can remove the open-source exemption, because you then carry the provider duties yourself. Your deployer or provider role also depends on whether you release the result under your own name. Work through the role analysis with counsel before training starts, and record the compute and data you used so the decision can be shown later.

Can we skip the public training summary if the model is open source?

No. Article 53(1)(d) requires providers of general-purpose models to draw up and publish a sufficiently detailed summary of the content used for training, following the template the AI Office published. The open-source exemption in Article 53(2) does not cover this duty. Your team needs to list the data sources, their categories and how they were gathered, and to keep the record that supports each statement. Ask counsel whether the summary must be updated when you retrain or fine-tune the model.

What drives the cost and effort of meeting these duties?

Cost depends on how many roles you hold and how much of the training record already exists. The main drivers are whether you are a provider or only a deployer, whether the model could carry systemic risk (the Article 51(2) presumption uses a training compute threshold of 10^25 floating point operations, which the Commission says is under review), how well documented your training data is, and how many models and versions you run. Legal review, data provenance work and evidence collection are recurring costs when you retrain. Ask any consultant to split the quote into one-time setup and ongoing work.

How long does preparation take, and what dates should we plan around?

The Act applies in stages, and the 2026 Digital Omnibus changed some of them. Chapters on general-purpose AI have applied since 2 August 2025, and the rest of the Act applies from 2 August 2026, with the high-risk rules for Annex III systems moved to 2 December 2027. Preparation time depends on your inventory, data records and existing documentation, and no reliable duration is supplied here. Ask a partner to state its assumptions about your starting point and to name the milestones it will deliver in writing.

Can our own team handle AI Act compliance for an open-source model?

Often yes for the parts that sit close to your engineering work, such as model inventories, configuration records, logging and access controls. Legal classification, the copyright policy and the training summary usually need legal input from people who know the Act. An implementation partner can build the systems and evidence trail, but it cannot issue a conformity or compliance statement. Decide which tasks you keep in-house, name an owner for each duty, and confirm the split in the scope document before work starts.

What should we ask a partner to include in a quote?

Ask for a written scope that lists each system and model covered, the roles you hold under the Act, and the deliverables for each duty, such as the copyright policy, the training summary, the technical records and the inventory. Ask which tasks are fixed scope, which are retainers, what you must provide, and what the partner assumes about your data and infrastructure. Confirm that the partner prepares evidence and does not issue certifications, and ask which independent body you would need for any assessment.

What a scoped engagement covers and what it does not

A DeployOpen engagement on open-source AI models is defined by a written, fixed scope agreed before work starts. Within that scope, DeployOpen plans and builds the self-hosted platform inside your own cloud account, data center or air-gapped network, documents the model stack (the weights you run, their license file and version, the serving framework, the inference gateway and any fine-tuning pipeline), and sets up the logging and evidence collection that record how the models are used. It also prepares the technical documentation and the internal records your team needs to hold. Before scoping, confirm with your counsel which Article 53 duties your model release triggers, since those duties drive which documents and log fields are worth building. The scope should name each model, each system that calls it and each environment in which it runs, so that the evidence list maps to real components rather than to a general promise.

DeployOpen does not give legal opinions. It cannot tell you whether a model release qualifies for the open-source exemptions in Article 53(2) or Article 54(6), whether a model presents systemic risk, or whether your organization is a provider or a deployer for a given use. Those determinations belong to your legal team and, where the Act requires it, to the AI Office or national authorities. DeployOpen also does not issue audit reports, attestations or certificates, and it does not guarantee a regulatory outcome. An independent auditor, assessor or certification body issues any report or certificate. Ask any partner, DeployOpen included, to put these limits in the statement of work, and ask your counsel to confirm the exemption analysis in writing before you rely on it.

How DeployOpen prepares open-source AI evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For open-source AI models under the EU AI Act, we prepare the systems, records and evidence that show which exemptions apply and which duties remain, while your organization keeps ownership of its compliance decisions.

How we scope

We confirm whether your model is released with public weights, architecture and usage information, and whether it could carry systemic risk.
We record which AI Act duties apply to your role as provider, deployer or both, in a written scope agreed before work starts.
Engagements are fixed-scope, with deliverables and timelines set out in writing, and ongoing support available as a retainer.

How we build

We set up the copyright policy, training data summary records and technical documentation that the scope requires, using your existing repositories and tooling.
We configure logging, version tracking and model card records so your team can show what was released, modified and deployed.
We test the controls we build and document the results, so your assessors can trace each duty to a concrete record.

How we hand over

We deliver the evidence pack in a structured form, with an index mapping each article to the artifact that supports it.
We train your engineering and compliance staff to maintain the records after handover, including how to update them when weights change.
We state clearly which items remain your decisions, such as legal interpretation and role classification, and which need an independent reviewer.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, aligned with the scope you agree in writing.
We help you prepare for reviews by regulators, customers or auditors, but we do not issue audit reports, attestations or certifications.
Where the AI Office or a national authority requests information, we help your team assemble the records and confirm the current guidance.

Open-source AI models under the EU AI Act