AI System vs AI Model: Where the EU AI Act Draws the Line

Most people use “AI model” and “AI system” as if they meant the same thing. The EU AI Act does not. The two terms are defined separately in Article 3, sit in different parts of the regulation, and pull different obligations behind them. Where the line falls between them decides which obligations you carry and which belong to someone else.

This matters in a way most explainers miss. If you are a startup building on the OpenAI API, you are not in scope of the same chapter as OpenAI itself. They sit in Chapter V. You sit in Chapter III, plus Article 50. Confusing the two is how founders either under-build their compliance programme (assuming OpenAI’s documentation covers them) or over-build it (preparing for Annex XI paperwork that does not apply to them at all).

The text that resolves this is short and worth reading carefully.

The two definitions

Article 3(1) defines an AI system as “a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments.”

Article 3(63) defines a general-purpose AI model as one that “displays significant generality and is capable of competently performing a wide range of distinct tasks regardless of the way the model is placed on the market and that can be integrated into a variety of downstream systems or applications.” The same provision excludes models “used for research, development or prototyping activities before they are placed on the market” — so an internal experimental model is not yet a GPAI model in the Act’s sense.

Article 3(68) supplies the third term you actually need. A downstream provider is the provider of an AI system that integrates an AI model — whether that model came from a third party or from your own work. Almost every founder building on the OpenAI or Anthropic APIs is one.

Two things to notice. The AI system definition is about a machine that operates and produces outputs in an environment. The GPAI model definition is about a capability — the trained model itself, sitting on its own, regardless of how anyone gets at it.

A model is the trained component. A system is the operating product built around it. They are not synonyms, and the Act does not treat them as such.

Recital 97: where the line falls

Recital 97 is the bridge between the two definitions. It is the bit of the regulation that tells you when a model becomes a system. The key passage:

“Although AI models are essential components of AI systems, they do not constitute AI systems on their own. AI models require the addition of further components, such as for example a user interface, to become AI systems.”

So a model on its own is not an AI system under the Act. Add a user interface, a deployment pipeline, an API wrapper your customers call, anything that turns the trained weights into something a person or another piece of software actually interacts with, and you have created an AI system. The model is now an essential component of that system, but the system is its own legal object with its own provider.

The same recital also handles the case where the model provider builds and ships their own AI system on top of their own model — ChatGPT being the obvious example: “When the provider of a general-purpose AI model integrates an own model into its own AI system that is made available on the market or put into service, that model should be considered to be placed on the market and, therefore, the obligations in this Regulation for models should continue to apply in addition to those for AI systems.” Both sets of obligations bite. Embedding the model in your own system does not let you escape Chapter V.

For most products built on top of a foundation model, the layer that turns the model into a system is where the value of the product lives. It is also where most of the compliance work sits.

Why the line matters

The two definitions sit in different parts of the regulation, with different obligations attached to each.

Models are governed by Chapter V (Articles 51–56). Chapter V only applies to general-purpose AI models. Providers of those models must keep technical documentation under Annex XI, hand transparency information under Annex XII to the providers who build systems on top, run a copyright compliance policy, and publish a summary of training data. A GPAI model is presumed to be a systemic-risk model under Article 51(2) when the cumulative training compute exceeds 10²⁵ FLOP — and the Commission can designate models above or below that figure on the criteria in Annex XIII. Systemic-risk models pick up further obligations under Article 55: model evaluation, adversarial testing, serious-incident reporting, and cybersecurity for the model and its infrastructure.

Article 53(2) carves out models released under a free and open-source licence — with weights, architecture, and usage information made public — from the Annex XI technical documentation and Annex XII transparency obligations. Copyright policy and training data summary still apply. The carve-out falls away if the model has systemic risk. For small teams releasing fine-tunes openly on Hugging Face, that exemption can be the difference between a small compliance footprint and a substantial one.

The companies in scope here are the foundation-model builders: OpenAI, Anthropic, Google DeepMind, Meta, Mistral, and the like. Chapter V applied from 2 August 2025, with a transition period running to 2 August 2027 for models already on the market before that date.

Systems are governed by Chapters II and III, plus Article 50. Chapter II is a closed list of prohibited practices in Article 5 — eight categories of AI use that are simply not allowed in the EU, regardless of how the rest of the Act would otherwise classify the system. It is not a baseline requirement set that every system has to comply with. It is a bar you confirm you do not cross. Chapter III contains the high-risk requirements: risk management (Art. 9), data governance (Art. 10), technical documentation (Art. 11 and Annex IV), record-keeping (Art. 12), transparency and instructions for use (Art. 13), human oversight (Art. 14), accuracy and robustness (Art. 15), conformity assessment, registration, post-market monitoring.

Article 50 attaches four targeted transparency obligations to four specific kinds of system:

• Systems intended to interact directly with natural persons (Art. 50(1)) — users must be informed they are dealing with an AI, unless that is obvious from context.
• Systems generating synthetic audio, image, video, or text content (Art. 50(2)) — the outputs must be marked in a machine-readable format such as a watermark or provenance signal, not just a visible disclaimer.
• Emotion recognition and biometric categorisation systems (Art. 50(3)) — affected persons must be informed of the operation of the system.
• Deepfakes and certain AI-generated public-interest text (Art. 50(4)) — the content must be disclosed as artificially generated or manipulated.

The system-side timing has moved. Under the Digital Omnibus — the provisional political agreement reached on 7 May 2026 — most Annex III high-risk obligations now apply from 2 December 2027 rather than 2 August 2026, and Article 50 transparency moves to 2 November 2026. The agreement still needs lawyer-linguist review, Parliament approval, Council adoption, and publication in the Official Journal. Article 5 prohibited practices have applied since February 2025 and were not delayed.

These obligations are owed by the provider of the AI system. The provider is whoever places the system on the market under their own name (Article 3(3)) and carries the duties listed in Article 16. When the provider has built the system by integrating someone else’s GPAI model, they are also a downstream provider under Article 3(68) — and Recital 97 confirms that this integration path is exactly how a new AI system, with a new provider, comes into being. Article 25 covers a different question: when a deployer, distributor, or other third party becomes the provider of a system that is already on the market.

So the line between model and system is also the line between two largely separate sets of obligations. Most companies are in one bucket; a few are in both.

A worked example

Take ContractClerk, a hypothetical Berlin SaaS building a contract-review assistant for small UK and EU law firms. They call Anthropic’s Claude API, retrieve over the firm’s document library, wrap everything in a web app, and sell the product per seat.

What is each party’s exposure?

• The Claude model itself is not ContractClerk’s responsibility. Anthropic carries the Chapter V obligations for Claude — training data summary, copyright policy, transparency to integrators like ContractClerk, the systemic-risk obligations if applicable.
• The contract-review assistant, as shipped to law firms, is an AI system. ContractClerk is its provider under Article 3(3), because the product is placed on the market under their name.
• Whether ContractClerk’s product is high-risk depends on its actual use. Most contract-review tools are not Annex III high-risk on their face, but a tool advising on employment decisions or credit terms could tip into the list. ContractClerk has to do that classification themselves — Anthropic cannot do it for them.
• ContractClerk’s assistant is “intended to interact directly with natural persons”, so Article 50(1) bites: lawyers using the tool have to be informed they are talking to an AI, unless that is obvious from context. If the assistant also generates substantive synthetic content (a draft clause, a summary memo), Article 50(2) lands on top — the output has to carry a machine-readable marker.

Anthropic and ContractClerk are both in scope of the Act. They are in scope of different parts of it, for different objects. Anthropic’s Chapter V documentation does not put a CE marking on ContractClerk’s product. ContractClerk’s Article 13 instructions for use do not relieve Anthropic of its training-data summary obligation. Each compliance workload runs in parallel.

The hard cases

The model/system line gets fuzzy in three places, and these are where most disputes will sit.

Fine-tuned models. If you fine-tune a base model and release the fine-tuned version as a separate model that others can integrate, you have become a model provider for that derived model and Chapter V starts to apply to you. If you fine-tune the model but keep it internal — using it only inside your own product — you remain a system provider only. The act of releasing the model for others to build on is what flips you across the line.

Agentic products. A model plus a loop that lets the model call tools, browse, write files, and act over multiple steps is still, under the Act, an AI system built on top of a model. The autonomy phrase in Article 3(1) — “designed to operate with varying levels of autonomy” — was drafted with this kind of product in mind. More autonomy does not change the model/system distinction. It tends to raise the risk classification of the system rather than its categorical type.

Substantial modification. Article 25(1) re-classifies a deployer, distributor, or other third party as a provider of a high-risk system in three situations:

• 25(1)(a) — putting their own name or trademark on a high-risk system already on the market.
• 25(1)(b) — substantially modifying a high-risk system in a way that keeps it high-risk.
• 25(1)(c) — modifying the intended purpose of a system so that a previously non-high-risk system becomes high-risk.

Heavy fine-tuning, swapping the model under a product, or repurposing a tool into a regulated domain can each trigger one of these — and shift you from deployer obligations to the full provider stack on that same system.

If you find yourself sliding into one of these cases, the question to ask is not “is this still the same product?” but “would a regulator say I have placed something materially different on the market?” That is the test the Act is reaching for.

What this means for you

A short, practical sequence.

1. Decide which side of the line you sit on. If you train models and place them on the market for others to build with, you are a model provider — Chapter V applies. If you wrap someone else’s model in a product you ship under your brand, you are a system provider — Chapter III and Article 50 apply. If you do both, both apply to the corresponding objects.

2. For each AI system you ship, name it. A list of distinct AI systems — products, features, modules — is the starting point of an AI inventory. The provider-or-deployer call, the high-risk classification, and everything that follows all hang off this list.

3. Document the boundary between model and system. For each system you provide, write down which model it uses, which version of that model, who provides it, and what documentation the model provider has supplied to you under Article 53(1)(b). This seam is where your obligations stop and the model provider’s begin. You will be asked to point to it — by your auditor, by enterprise customers running vendor diligence, by your authorised representative if you have appointed one.

4. Do not assume your model provider has covered you. OpenAI’s Annex XI documentation does not give your product a conformity assessment. Anthropic’s training data summary does not satisfy your Article 13 obligation to write instructions for use. The two compliance workloads run alongside each other and neither stands in for the other. This is also the trap the provider-side analysis catches startups on most often.

The instinct to use “model” and “system” interchangeably is harmless in conversation. In any document the Act might touch — a risk register, a technical file, a vendor contract, a deployer FRIA, a procurement questionnaire from an EU customer — the two terms have to be used the way the regulation uses them. Getting that habit right early is the cheapest piece of compliance work you will ever do.