Does the open-source exemption cover Llama, Mistral, or Qwen?

The license controls the starting point. Llama 3 uses the Llama 3 Community License, with commercial restrictions that keep it outside the Open Source Definition. Mistral 7B and Mixtral 8x7B use Apache 2.0. Qwen 2.5 licensing varies by release. The component-level exemption under Article 2(12) depends on that license analysis, while Article 26 still governs a high-risk-system deployer.

What about open-weight models with custom non-OSI licenses?

Custom licenses such as the Llama Community License and Falcon Community License commonly restrict commercial use, redistribution, or downstream training. Those restrictions can keep a model outside the Open Source Definition, so the Article 2(12) component exemption may not apply. A high-risk-system deployer remains responsible under Article 26 in either case.

Does hosting an open-source model on our own infrastructure change anything?

Self-hosting gives the deployer direct control over the inference path, the access logging, and the inspection layer. It does not change the obligation set under Article 26. The deployer still has to produce the Article 12 records, conduct the conformity assessment, and meet the transparency and human oversight obligations. Self-hosting often improves the deployer's ability to discharge those obligations because the deployer controls the full request path.

What if our open-source model is a GPAI under Article 51?

When the open-source model crosses the systemic-risk threshold (10^25 FLOPs cumulative training compute or Commission designation), the broader Article 55 obligations apply to the provider regardless of the license. The deployer obligations are separate from the provider obligations and apply when the deployer puts the model into operational use for a high-risk system.

How do we document the open-source model in our conformity assessment?

The technical documentation under Annex IV requires a description of the system including the model architecture, training data sources to the extent the deployer has them, intended purpose, and known limitations. An open-weight deployment can cite its public model card and published training-data summary, then attach the deployer's validation results against the intended purpose. Keep the version identifier, deployment configuration, test evidence, monitoring procedure, and the accountable owner with that documentation.

EU AI Act Open Source: The Open-Weight Exemption

Article 2's open-source carve-out releases some model-provider duties, while Article 26 keeps the high-risk-system deployer's operational work in place. The carve-out lives in Recital 89 and the substantive treatment is in Article 2 on scope and in Article 53 on GPAI provider obligations. A high-risk system using an open-weight model retains the same deployer obligations as one using a proprietary model. Licensing does not alter the deployer's record keeping, transparency, human-oversight, or conformity-assessment duties.

I want to walk through what the open-source exemption actually covers, where it stops, and what the operational stack has to produce on the deployer side regardless of whether the underlying model is Llama, Mistral, Qwen, GPT-4, or Claude.

TL;DR

Open-source status is a licensing and provider-scope question. The high-risk system remains the deployer's operational responsibility after that question is answered. Keep the release license and version with the system file. Then retain the Article 12 logs produced by the system, the Article 26 monitoring evidence, and the human-oversight procedure that staff can use when an output affects a person. A model card helps explain a component. It does not replace the deployer's evidence for the deployed system.

What Recital 89 actually says

Recital 89 frames free and open-source AI components as software where source code, model weights, and information about the model architecture are made publicly available under a free and open-source license. The recital says these components should not be subject to the full provider obligations under the Act, on the reasoning that the components themselves are research-and-development infrastructure rather than products placed on the market.

The recital carries two important limitations. The first is that the carve-out applies to the components, not to the systems that incorporate them. A high-risk AI system built on top of an open-weight model is still a high-risk AI system. The second is that the carve-out does not apply when the open-source model is itself a GPAI model with systemic risk under Article 51.

What Article 2 says about scope

Article 2(12) excludes free and open-source AI components from the Act's scope when those components are released under a free and open-source license. The exclusion is for the components, not for the AI systems that put the components into operational use. The exclusion stops when the open-source AI is placed on the market or put into service for a high-risk use case or as a GPAI model with systemic risk.

In practical terms, a model published on Hugging Face under Apache 2.0 is an open-source AI component. A bank using it for credit scoring is a deployer of a high-risk AI system. Its obligations under Articles 26, 9-15, and 12-19 remain. The EU AI Act credit-scoring guide sets out that deployment context.

Where the GPAI obligations land

Article 53 sets the obligations for providers of GPAI models. Open-source GPAI providers get a narrower obligation set: they are excluded from some technical documentation requirements (53(2)) when the model is released under a free and open-source license, but they still have to comply with the copyright policy obligation (53(1)(c)) and the training-content summary obligation (53(1)(d)). When the open-source GPAI model crosses into systemic-risk territory under Article 51, the broader obligations under Article 55 apply regardless of the license.

The threshold for systemic risk is 10^25 floating-point operations of cumulative compute used for training under Article 51(1)(a), or a designation by the Commission. Most open-weight models in production use today (Llama 3, Mistral, Qwen, Mixtral) sit under the threshold. The largest open-weight models the field has produced approach but do not cross the threshold as of mid-2026.

Deployer obligations that do not change

The deployer of a high-risk AI system that uses an open-weight model carries the same obligation set as the deployer that uses a proprietary model. The obligation set under Article 26 includes:

Using the system in accordance with instructions for use (Article 26(1))
Ensuring relevant input data is appropriate for the intended purpose (26(4))
Monitoring operation and notifying the provider of serious incidents (26(5))
Keeping the automatically generated logs for at least 6 months (26(6))
Conducting a data protection impact assessment when required (26(9))

Article 26(6) specifically requires the deployer to keep the logs the high-risk system generates under Article 12. The deployer's record-keeping obligation persists regardless of whether the underlying model is open-source or proprietary. The deployer's stack has to produce and retain the records.

What the operational stack has to produce

The operational stack for a high-risk deployer running an open-weight model has to produce:

The per-decision record series under Article 12 + Article 19

(identity, prompt, classification, decision, policy, timestamp, integrity)

The data governance documentation under Article 10 for the input data
The technical documentation for the system, including which open-weight

model is in use and how it integrates with the policy surface

The human oversight procedures under Article 14
The transparency information for the system user under Article 13
The DPIA when the system processes personal data at scale

The record series sits on the request path between the deployer's users and the open-weight model's inference endpoint, regardless of where that endpoint runs. The deployer hosting the model on their own infrastructure has full control over the inspection layer. The deployer using a managed inference service for the open-weight model (Hugging Face Inference Endpoints, AWS SageMaker, GCP Vertex AI) needs the inspection layer in front of that service.

What the open-source nature does change

The open-source license does affect a few practical things. Public weights and architecture give a deployer fuller visibility into model behavior. That access supports a deeper review of bias, security properties, and alignment with the intended use case. Self-hosting can also bring inference inside the corporate boundary, simplifying the GDPR data-residency analysis.

The same Article 26 operating duties remain: retained records, transparency material, human-oversight procedures, conformity assessment, post-market monitoring, and Article 99 penalty exposure. EU AI Act logging requirements covers the record series separately.

DeepInspect

DeepInspect sits inline between authenticated users or agents and any LLM, including open-weight models hosted on the corporate infrastructure or on managed inference services. The proxy terminates TLS at the inspection layer, authenticates against the corporate IdP, classifies the prompt content, evaluates policy against identity and classification, and commits a per-decision audit record before the model receives the request. The records carry the fields Article 12 and Article 19 expect on a tamper-evident series the deployer's conformity assessment evidence package references.

For organizations running open-weight models on infrastructure they control, the proxy placement gives the deployer the same Article 12 record series they would carry against a proprietary model API. The model licensing decision and the audit record series sit on independent axes.

If you are facing the August deadline, let's talk.