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

The license matters. Llama 3 is released under the Llama 3 Community License, which has commercial restrictions and is not a recognized free and open-source license under the Open Source Definition. Mistral 7B Apache 2.0 and Mixtral 8x7B Apache 2.0 are released under Apache 2.0, which is a free and open-source license. Qwen 2.5 versions vary by release. The component-level exemption under Article 2(12) depends on the license meeting the FOSS definition. Even when the license qualifies, the deployer obligations under Article 26 remain unchanged.

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

Models released under custom licenses (Llama Community License, Falcon Community License, several others) typically do not meet the Open Source Definition because the license restricts commercial use, redistribution, or downstream training. The Article 2(12) exemption may not apply at the component level. The deployer obligations under Article 26 apply regardless of the model license.

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. For open-weight models, the deployer can reference the public model card, the published training data summary, and the model's benchmarks. The deployer's own validation of the model against the intended purpose belongs in

EU AI Act and Open-Source AI: Where the Open-Weight Exemption Stops and the Deployer Obligation Starts

The EU AI Act treats open-source AI differently from proprietary AI in a narrow way. 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. What the carve-out actually says is narrower than the headline reads. The deployer of a high-risk system that uses an open-weight model carries the same obligations as the deployer of a high-risk system that uses a proprietary model. The model licensing does not change the deployer's record-keeping, transparency, human oversight, or conformity assessment obligations.

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.

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.

The mechanical reading: a model published on Hugging Face under Apache 2.0 is an open-source AI component. A bank that uses that model for credit scoring is a deployer of a high-risk AI system. The bank's obligations under Articles 26, 9-15, and 12-19 do not change because the model is open-source.

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:

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 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. The deployer often has fuller visibility into the model's behavior because the weights and the architecture are public. The deployer can audit the model for bias, security properties, and alignment with the intended use case more thoroughly than for a closed model. The deployer can host the model on their own infrastructure and bring the inference inside the corporate boundary, which simplifies the data residency story under GDPR.

What the open-source nature does not change: the record-keeping obligation, the transparency obligation, the human oversight obligation, the conformity assessment obligation, the post-market monitoring obligation, and the penalty exposure under Article 99.

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.