The EU AI Act creates a layered obligation structure where your position in the supply chain determines what you must do. A company that develops and places an AI system on the market is a provider; a company that uses that system in its business operations is a deployer; a company that does both for different AI systems carries both sets of obligations simultaneously. The definitions in Article 3 are not technical legal formality. They are the analytical entry point for every practical compliance question that follows.

Key takeaways

  • Article 3(1) of Regulation (EU) 2024/1689 defines an AI system as a machine-based system that infers how to generate outputs influencing real or virtual environments. The definition was narrowed from the Commission's original proposal specifically to exclude conventional rule-based software. The inference requirement and the degree of autonomy are the two elements that distinguish AI systems from standard software for compliance purposes.
  • A provider (Article 3(3)) is the party that develops an AI system and places it on the market or puts it into service under their own name. A deployer (Article 3(4)) is any organisation that uses an AI system under its own authority in a commercial context. An enterprise that accesses a third-party AI model via API and integrates it into its business processes is almost always a deployer, not a provider.
  • Article 25 creates four specific circumstances in which a deployer assumes the full obligations of a provider, including where the deployer places a high-risk AI system on the market under its own name or makes a substantial modification to such a system. This is the most common source of unexpected provider obligations for enterprise deployers.
  • Article 3(63) defines a general-purpose AI model (GPAI model) as a model capable of competently performing a wide range of tasks regardless of how it is placed on the market. Frontier language models qualify. GPAI model providers face specific obligations under Articles 53 and 55, including transparency measures, copyright compliance policies, and for systemic risk models, adversarial testing and cybersecurity obligations.
  • The threshold for GPAI models with systemic risk (Article 3(65)) is set by Article 51 at a training compute threshold of 10 to the power of 25 FLOPs. Models meeting this threshold face the most stringent obligations under the Regulation, including incident reporting and cooperation with the AI Office.

Why definitions determine obligations

The EU AI Act is a risk-based regulatory framework. The obligations imposed on any given organisation depend entirely on two factors: the risk tier of the AI system it is involved with, and its position in the supply chain for that system. The risk tier is determined by the classification rules in Article 6 and Annex III. The supply chain position is determined by the definitions in Article 3.

An error in categorisation at either step produces incorrect compliance analysis. A compliance team that classifies their organisation as a deployer when it actually meets the provider definition will underestimate its obligations. A team that treats its AI system as not within the Article 3(1) definition will treat the Regulation as inapplicable when it is. The definitions are the first analytical step in any EU AI Act compliance programme, and they repay careful attention.

The following analysis covers the seven definitions with the most practical impact for enterprises deploying AI in the EU market. Article 3 contains 65 definitions in total; the remaining definitions are addressed in context in the specific articles to which they relate.

Article 3(1): AI system

The EU AI Act applies to AI systems, defined in Article 3(1) as "a machine-based system that, for a given set of human-defined objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions influencing real or virtual environments. AI systems are designed to operate with varying levels of autonomy and may exhibit adaptiveness after deployment, and they produce outputs such as physical, virtual, or hybrid impacts on their environment."[1]

The definition evolved significantly through the legislative process. The Commission's original 2021 proposal used a broad, Annex I approach listing specific techniques: machine learning, logic-based systems, and statistical approaches. The European Parliament and Council replaced this with a single principles-based definition, with the deliberate intention of narrowing scope to exclude conventional software systems that merely follow explicit rules without any inference element.

Two elements of the definition carry most of the practical weight. First, inference: the system must infer from input how to generate output. This distinguishes AI systems from rule-based automation where the output is entirely determined by the programmer's explicit instructions. A spreadsheet formula is not an AI system. A machine learning model that calculates credit risk from applicant data is. The borderline cases, where a system combines rule-based and learned components, require case-by-case analysis.

Second, autonomy: the system must operate with some degree of autonomy. The definition does not require full autonomy. A system that operates under human supervision but makes intermediate inferences without human input at each step likely qualifies. The recitals confirm that the degree of autonomy is relevant to risk classification rather than to whether the system falls within the definition at all.

Article 3(3): provider

Article 3(3) defines a provider as "a natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model and places it on the market or puts the system into service under its own name or trademark, whether for payment or free of charge."[1]

Three elements of the provider definition require attention.

First, development. A provider is a party that develops an AI system. This covers companies that build AI systems from scratch using their own training pipelines, but also companies that fine-tune a third-party foundation model on their own data and place the resulting system on the market. The key question is whether the party exercised control over the development of the system, including its training, configuration, and the definition of its purpose and capabilities. A company that merely re-brands a third-party AI system without modification does not develop it; it is likely an importer or distributor under Articles 3(6) and 3(7).

Second, placing on the market or putting into service. Placing on the market means making an AI system available on the Union market for the first time, whether for payment or free of charge. Putting into service means supplying an AI system for first use on the Union market for its intended purpose, directly to the deployer or for own use by the provider. An enterprise that develops an AI system for its own internal use without selling it to others is nevertheless a provider if it puts the system into service under its own name. This covers a company that builds and operates an internal HR screening AI: it is the provider of that system even though no sale occurs.

Third, own name or trademark. The provider is the party who presents the system to the market or to deployers under their own identity. This element creates the branding test: who takes responsibility for the system in the eyes of those using it? A company that uses a white-labelled AI system and presents it to customers under its own product name is likely the provider, even if it did not build the underlying technology.

Article 3(4): deployer

Article 3(4) defines a deployer as "a natural or legal person, public authority, agency or other body that uses an AI system under its own authority except where the AI system is used in the course of a personal non-professional activity."[1]

The deployer definition is intentionally broad. Any organisation that uses an AI system in a commercial context is a deployer. The personal non-professional exclusion is narrow: it covers individuals using AI tools for personal tasks, not enterprises using AI tools in any aspect of their business operations.

The practical implications are significant. A company that integrates a third-party AI system via API into its customer service operations is a deployer of that system. A firm that uses an AI writing assistant to generate marketing materials is a deployer. A hospital that uses an AI diagnostic system is a deployer. In each case, the organisation "uses" the AI system "under its own authority": it controls when and how the system is used and bears the operational responsibility for that use.

For AI systems that are not high-risk under Article 6 and Annex III, deployer obligations are relatively light. For high-risk AI systems, Article 26 imposes the full deployer obligation set: using the system in accordance with the provider's instructions for use; ensuring human oversight; monitoring operation; keeping logs if the system supports automated log-keeping; conducting a fundamental rights impact assessment where Article 27 requires it; and registering as a deployer of certain high-risk AI systems in the EU database.[2]

Deployers of AI systems that produce outputs affecting individuals must also comply with transparency obligations under Article 50: disclosing to individuals interacting with emotion recognition systems or biometric categorisation systems, disclosing when AI-generated content is produced, and watermarking synthetic content where required.

Article 3(8): operator

Article 3(8) defines an operator as the collective category covering "the provider, the product manufacturer, the deployer, the authorised representative, the importer and the distributor."[1]

The operator definition is primarily an administrative term. The Regulation uses it in provisions that apply to the full supply chain simultaneously, particularly in the context of market surveillance authority powers under Article 74 and the cooperation obligations under Article 98. When a compliance officer reads "operators" in the text, the provision is likely addressing all supply chain actors. When the text refers to "providers" or "deployers" specifically, only those categories are addressed.

Understanding the distinction matters for reading specific articles correctly. Article 97 on post-market monitoring obligations refers to providers. Article 26 on high-risk AI obligations refers to deployers. Article 62 on notification of serious incidents refers to providers and, in certain circumstances, deployers. Reading these provisions without tracking the specific subject of the obligation produces incorrect compliance analysis.

Article 3(5), (6), (7): authorised representative, importer, distributor

Article 3(5) defines an authorised representative as a natural or legal person in the EU who has received a written mandate from a provider established outside the EU to perform on the provider's behalf obligations established by the Regulation.[1] A non-EU AI system provider must appoint an authorised representative before placing high-risk AI systems on the EU market. The authorised representative registers the system in the EU database, cooperates with market surveillance authorities, and carries out a subset of provider obligations.

Article 3(6) defines an importer as a natural or legal person located or established in the EU that places on the EU market an AI system that bears the name or trademark of a person established outside the EU.[1] The importer function is relevant for the distribution layer: a European reseller who sources AI systems from a non-EU developer and sells them in Europe under the developer's branding is an importer, not a provider.

Article 3(7) defines a distributor as any other party in the supply chain who makes an AI system available on the EU market without being the provider or importer. Distributors have the lightest obligations: primarily verification that the provider or importer has met their obligations before the system was placed on the market.

Article 25: when a deployer becomes a provider

Article 25 is the provision that most frequently surprises enterprise compliance teams. It establishes four circumstances in which a party originally acting as a deployer assumes the full obligations of a provider.[3]

First: where the deployer places a high-risk AI system on the market or puts it into service under its own name or trademark. If an enterprise obtains a high-risk AI system from a third-party developer, customises it, and deploys it to customers or to the market under the enterprise's own branding, the enterprise becomes the provider for the purposes of the Regulation. This is one of the most common vectors through which enterprises inadvertently assume provider obligations.

Second: where the deployer modifies the intended purpose of a high-risk AI system already placed on the market in a way that results in a change in risk classification. If the original provider placed the system on the market as a medium-risk system for a particular use case, and the deployer reconfigures it for a use case that falls in Annex III high-risk categories, the deployer becomes the provider for that new configuration.

Third: where the deployer makes a substantial modification to a high-risk AI system already placed on the market or put into service. Substantial modification is defined in Article 3(23) as a modification that changes the system's intended purpose, risk classification, or performance in ways not foreseen by the original conformity assessment. Fine-tuning a model on a substantially different domain, retraining the model on new data that changes its capabilities, or integrating new modalities that change the system's behaviour all potentially qualify as substantial modifications.

Fourth: where the deployer modifies a GPAI model placed on the market in such a way that it becomes a high-risk AI system. This covers the case of an enterprise that takes an open-source GPAI model, fine-tunes it for a specific high-risk application (such as credit scoring or medical diagnosis), and deploys the result. The enterprise is the provider of the resulting high-risk AI system.

Article 3(63): general-purpose AI model (GPAI model)

Article 3(63) defines a general-purpose AI model as "an AI model, including where such a model is trained with a large amount of data using self-supervision at scale, 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."[1]

The definition explicitly excludes models used only for research, development, or prototyping before they are placed on the market. This exclusion is practical: it prevents the classification obligations from applying to models that are never deployed in commercial contexts.

GPAI models trigger the obligations in Chapter V of the Regulation (Articles 51 to 56). All GPAI model providers must maintain technical documentation, comply with copyright law in training data, and publish a summary of training content.[4] Providers of GPAI models with systemic risk face additional obligations including adversarial testing, incident reporting to the AI Office, and cybersecurity measures.

The GPAI model definition captures frontier language models including those developed by OpenAI, Anthropic, Google, Mistral, and Meta. Enterprise operators who access these models via API are deployers of GPAI-based systems, not providers of GPAI models. The provider obligations in Chapter V attach to the companies that developed the models, not to the enterprises using them downstream.

Article 3(65): GPAI model with systemic risk

Article 3(65) defines a general-purpose AI model with systemic risk as a GPAI model that has high-impact capabilities evaluated against the threshold in Article 51, or that is designated as a systemic risk model by the AI Office.[1]

Article 51 sets the quantitative threshold at a training compute of more than 10 to the power of 25 floating-point operations (FLOPs). This threshold captures the most capable frontier models as of mid-2026. The AI Office may designate additional models as systemic risk models on the basis of qualitative indicators, including the number of parameters, the range of capabilities, the number of downstream applications, and evidence of heightened risks identified through testing.

The systemic risk designation imposes the most stringent obligations in the entire Regulation on the affected model providers: mandatory adversarial testing including red-teaming; notification of the AI Office of serious incidents arising from the model; implementation of cybersecurity measures; and reporting annually to the AI Office on compliance measures and evaluation results.

For enterprise deployers accessing systemic risk GPAI models via API, the provider's obligations do not transfer to the deployer. The deployer's obligations remain those in Article 26 if the AI system built on the GPAI model qualifies as high-risk, or the general transparency obligations in Article 50 for other AI systems. The systemic risk threshold and its obligations are a matter for the model providers, not for the enterprises using those models in downstream applications.

Practical classification guide

The following sequence is the practical starting point for any EU AI Act compliance analysis. Work through it for each AI system your organisation is involved with.

Step 1: Is this an AI system under Article 3(1)? Does the system infer from input how to generate outputs, and does it operate with some degree of autonomy? If no, the Regulation does not apply. If yes, proceed.

Step 2: What is your supply chain role for this system? Did your organisation develop the system and place it on the market or put it into service under its own name? If yes, you are a provider. Does your organisation use a third-party AI system in a commercial context? If yes, you are a deployer. Could Article 25 apply to make you a provider because of modifications you have made or are making to a high-risk system?

Step 3: Is the system high-risk under Article 6 and Annex III? Is it in one of the eight categories in Annex III? Does it meet the classification rules in Article 6? If yes, the full provider or deployer obligation set applies, depending on Step 2. For deployers of high-risk systems, see the Article 26 deployer obligations guide for the detailed compliance requirements.

Step 4: Does the system involve a GPAI model? Is the system built on a foundation model developed by a third party (OpenAI, Anthropic, Google, Mistral, Meta, or others)? If yes, the GPAI model provider carries Chapter V obligations independently of your use of the model. Your obligations remain those relevant to your supply chain role as determined in Steps 1-3.

For the insurance implications of these classifications, including how provider versus deployer status affects your coverage options and underwriting position, see the AI liability insurance market map 2026 on agentinsured.eu.

Frequently asked questions

What is the difference between a provider and a deployer under the EU AI Act?

Under Article 3 of Regulation (EU) 2024/1689, a provider is the party that develops an AI system and places it on the market or puts it into service under its own name or trademark. A deployer is any party that uses an AI system under its own authority in a commercial context. Providers carry the full technical obligation set under Articles 9-17 including conformity assessment, technical documentation, and registration. Deployers carry operational obligations under Article 26 including human oversight, logging, and fundamental rights impact assessments. A single organisation can be provider for some AI systems and deployer for others.

When does a deployer become a provider under the EU AI Act?

Article 25 of Regulation (EU) 2024/1689 creates four circumstances where a deployer assumes provider obligations: placing a high-risk AI system on the market under their own name; modifying the intended purpose of a high-risk system in a way that changes its risk classification; making a substantial modification to a high-risk system as defined in Article 3(23); or modifying a GPAI model such that it becomes a high-risk AI system. This provision is the most common source of unexpected provider obligations for enterprise AI deployers who customise, fine-tune, or substantially modify third-party AI systems.

What is a general-purpose AI model under the EU AI Act?

Article 3(63) of Regulation (EU) 2024/1689 defines a GPAI model as a model displaying significant generality and capable of competently performing a wide range of tasks regardless of how it is placed on the market, that can be integrated into a variety of downstream systems or applications. Frontier language models including those from OpenAI, Anthropic, Google, and Mistral qualify. The Regulation excludes models used only for research, development, or prototyping before market placement. GPAI model providers carry specific obligations under Articles 53-55; enterprise users of these models via API are deployers, not GPAI model providers.

What is the EU AI Act definition of an AI system?

Article 3(1) defines an AI system as a machine-based system that infers from input how to generate outputs such as predictions, content, recommendations, or decisions influencing real or virtual environments, operating with varying levels of autonomy. The definition was deliberately narrowed from the Commission's original proposal to exclude conventional rule-based software. The inference and autonomy requirements are the functional tests: a system that merely executes programmer-defined rules without learning from input is not an AI system under the Regulation.

Who is an operator under the EU AI Act, and why does the term matter?

Article 3(8) defines operator as the collective term covering all supply chain actors: providers, product manufacturers, deployers, authorised representatives, importers, and distributors. The term matters because the Regulation uses it in provisions that apply to the full supply chain simultaneously, particularly market surveillance cooperation obligations. When reading specific obligations in the Regulation, it is essential to identify whether the provision refers to "operators" generally or to a specific category such as "providers" or "deployers," because the obligations differ substantially between categories.

Does a company that uses a third-party AI system via an API qualify as a deployer?

Yes, in almost all commercial contexts. Article 3(4) defines a deployer as any party using an AI system under its own authority other than in personal non-professional activity. A company integrating a third-party AI via API into its business operations is a deployer. For high-risk AI systems, deployer obligations under Article 26 include using the system in accordance with provider instructions, ensuring human oversight, monitoring operation, maintaining logs, and potentially conducting a fundamental rights impact assessment under Article 27.

References

  1. Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, L 2024/1689. Article 3 (definitions), in particular paragraphs (1) AI system, (3) provider, (4) deployer, (5) authorised representative, (6) importer, (7) distributor, (8) operator, (23) substantial modification, (63) general-purpose AI model, (65) general-purpose AI model with systemic risk. Entered into force 1 August 2024.
  2. Regulation (EU) 2024/1689, Article 26 (obligations of deployers of high-risk AI systems) and Article 27 (fundamental rights impact assessment for high-risk AI systems). Article 26 imposes seven operational obligations on deployers: adherence to instructions for use; human oversight assignment; monitoring; logging if system supports it; notification of serious incidents; fundamental rights impact assessment where Article 27 requires it; and registration in the EU database for certain categories.
  3. Regulation (EU) 2024/1689, Article 25 (responsibilities along the AI value chain). Article 25(1) establishes four circumstances in which a deployer assumes provider obligations. Recital 84 confirms that the purpose of Article 25 is to ensure that the obligations associated with placing a high-risk AI system on the market or putting it into service follow the party actually responsible for the system's design and intended purpose, regardless of how that party characterises its own role.
  4. Regulation (EU) 2024/1689, Chapter V (General-purpose AI models), Articles 51-56. Article 53 sets out obligations for all GPAI model providers: technical documentation, copyright compliance policy, training data summary. Article 55 sets additional obligations for providers of GPAI models with systemic risk: model evaluation, adversarial testing, incident reporting to the AI Office, cybersecurity measures, and energy consumption reporting. The AI Office is responsible for supervision of GPAI model providers under Article 88.
  5. The EU AI Act compliance timeline: the GPAI model obligations in Articles 53-55 applied from 2 August 2025 (12 months after entry into force). The prohibition provisions in Article 5 applied from 2 February 2025 (6 months after entry into force). The high-risk AI provisions in Articles 9-17 and Article 26 are scheduled to apply from 2 August 2026, subject to the Digital Omnibus proposal (COM(2026)145) which proposes extension to 2 December 2027 for certain high-risk AI in regulated products. As of June 2026, the original August 2026 date remains binding.