Back to Insights

AI & Tech

Who Is Caught by the EU AI Act? Provider, Deployer, Importer and Distributor Roles Explained

The EU AI Act does not apply only to companies that develop AI systems. Its obligations are distributed across several roles, including providers, deployers, importers and distributors. Correct role mapping is therefore the first step in understanding legal exposure.

Published
26 May 2026

The EU Artificial Intelligence Act is not directed only at companies that develop AI models or build AI systems from scratch. Its personal scope is structured around functional roles in the AI value chain. A company may be a provider in one scenario, a deployer in another, and an importer or distributor in a third. The correct legal analysis therefore starts with a simple but important question: what role does the organisation play in relation to the AI system?

This role-based structure matters because obligations under Regulation (EU) 2024/1689 are not allocated only by contract, marketing description or technical authorship. They follow the function performed by the relevant actor: placing an AI system on the market, putting it into service, making it available on the Union market, using it under one's authority, or modifying it in a way that changes the legal position of the actor. Article 2 expressly covers, among others, providers, deployers, importers, distributors, product manufacturers and authorised representatives, including certain non-EU actors where the AI system or its output is connected to the Union.

Provider: the central compliance role

The provider is the central role in the AI Act framework. The Act defines a provider as a person or body that develops an AI system or a general-purpose AI model, or has one developed, and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge.

This means that the provider is not necessarily the original technical developer. A company may become a provider if it commissions a system from a third party and launches it under its own brand. A white-label arrangement, OEM model, integration into a branded product, or commercial relabelling exercise may therefore create provider exposure even where another party performed the core technical development.

For high-risk AI systems, provider status is particularly important because the main compliance architecture of the AI Act is built around the provider. The provider is normally responsible for ensuring that the system complies with the requirements applicable to high-risk AI systems, including risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness and cybersecurity requirements.

In practice, the provider analysis should not stop at the software development contract. It should consider who controls the intended purpose, who presents the system to the market, whose name or trademark is attached to the system, and who is positioned as the legally responsible actor in the Union market.

Deployer: using an AI system under one's authority

A deployer is a person or body using an AI system under its authority, except where the AI system is used in the course of a purely personal non-professional activity.

In business practice, this role will often cover companies using AI tools in internal processes, customer-facing workflows, employment-related assessments, compliance operations, credit-related workflows, fraud monitoring, document review, customer service, or other operational settings. The key point is not whether the deployer developed the AI system. The key point is that it uses the system under its authority.

Deployers of high-risk AI systems have their own obligations. These may include using the system in accordance with instructions, ensuring appropriate human oversight where required, monitoring operation, keeping logs where under their control, and complying with specific transparency or information duties in relevant scenarios.

The deployer role is sometimes underestimated because businesses may see themselves as "only users" of technology supplied by another party. Under the AI Act, that may be too simple. A company using AI in a regulated or sensitive context may have obligations even if it did not build the system.

Importer: bringing third-country AI systems into the Union market

An importer is an EU-established person or body that places on the market an AI system bearing the name or trademark of a person established in a third country.

This role is relevant where AI systems enter the Union market through an EU-based actor. The importer is not merely a commercial reseller in a general sense. It is the EU market entry point for an AI system associated with a third-country provider.

For high-risk AI systems, importers must verify key compliance elements before placing the system on the market. This includes checking that the relevant conformity assessment has been carried out, that technical documentation has been drawn up, that the system bears the required CE marking and is accompanied by the EU declaration of conformity and instructions for use, and that an authorised representative has been appointed where required.

The importer role is therefore a gatekeeping role. It does not usually carry the full original provider burden by default, but it is not passive. If an importer has sufficient reason to believe that a high-risk AI system is not compliant, it should not place it on the market until the issue is addressed.

Distributor: making AI systems available in the supply chain

A distributor is a person or body in the supply chain, other than the provider or importer, that makes an AI system available on the Union market.

Distributors are further down the supply chain, but the AI Act still gives them specific compliance responsibilities. Before making a high-risk AI system available on the market, distributors must verify, among other things, that the system bears the required CE marking, that it is accompanied by a copy of the EU declaration of conformity and instructions for use, and that the provider and importer have complied with certain obligations.

If a distributor considers, or has reason to consider, that a high-risk AI system is not in conformity, it must not simply continue distribution as usual. The Act requires corrective steps and cooperation with relevant authorities where appropriate.

The practical distinction between importer and distributor is important. An importer is the EU actor placing a third-country AI system on the market. A distributor is another supply-chain actor making the system available in the Union market. These roles can carry different obligations and should not be treated as interchangeable.

Authorised representatives and product manufacturers

The AI Act also recognises other roles that may be relevant in cross-border or product-regulated scenarios.

An authorised representative is an EU-based person or body that has accepted a written mandate from a provider to perform obligations and procedures under the AI Act on the provider's behalf. This role is particularly relevant for providers established outside the Union. It is not the same as becoming the provider, but it creates a compliance interface in the EU.

Product manufacturers are relevant where high-risk AI systems are safety components of products covered by specified Union harmonisation legislation. In certain circumstances, the product manufacturer is considered to be the provider of the high-risk AI system, especially where the AI system is placed on the market or put into service together with the product under the manufacturer's name or trademark.

These roles are important because AI systems are often embedded into broader products, services or supply chains. A product company should not assume that AI Act responsibility sits only with the software vendor.

When another actor becomes the provider

One of the most important provisions for practical role mapping is Article 25 of the AI Act. It provides that a distributor, importer, deployer or other third party is considered to be the provider of a high-risk AI system, and becomes subject to provider obligations, in certain situations.

This can happen where the actor puts its own name or trademark on a high-risk AI system already placed on the market or put into service. It can also happen where the actor makes a substantial modification to a high-risk AI system, or modifies the intended purpose of a system that was not previously classified as high-risk in a way that makes it high-risk.

This is a critical point for business models involving rebranding, customisation, integration, fine-tuning or repurposing. Contractual allocation of responsibilities remains commercially important, but it cannot override the public-law qualification of the actor under the AI Act where the conditions for provider status are met.

In other words, an organisation should not rely only on the label used in the contract. It should assess what it actually does with the AI system and whether its actions change the legal classification of its role.

Role mapping as a practical first step

For businesses, the first AI Act compliance step should be role mapping. This should be done by product, system and use case, not only at group or department level.

The same organisation may be:

  • a provider for an AI tool it places on the market under its own brand;
  • a deployer for an AI system it uses internally;
  • an importer for a third-country system it places on the Union market;
  • a distributor for systems it makes available in the supply chain;
  • or a provider again if it substantially modifies or rebrands an existing high-risk AI system.

This exercise should also consider timing. The AI Act applies in phases: its general application date is 2 August 2026, while certain chapters and obligations apply earlier or later, including Chapters I and II from 2 February 2025 and the general-purpose AI model framework from 2 August 2025.

The result of the role mapping should not be a theoretical chart. It should feed into contract design, product documentation, internal governance, supplier due diligence, conformity assessment planning and operational controls.

Practical takeaway

The EU AI Act regulates more than AI developers. It allocates responsibility across the AI value chain, including providers, deployers, importers, distributors, authorised representatives and product manufacturers.

For companies developing, buying, integrating, distributing or using AI systems, the practical question is not simply whether they "use AI". The more precise question is: which AI Act role do they perform in relation to each system and use case?

That answer determines the next step. Only after the role is clear can the organisation assess whether the system is prohibited, high-risk, subject to transparency duties, linked to general-purpose AI obligations, or outside the more intensive parts of the AI Act framework.

Legal references

  • Regulation (EU) 2024/1689, in particular Articles 2, 3, 4, 16, 22-26 and 113.
  • European Commission materials on general-purpose AI models, where relevant for provider obligations linked to GPAI models.

Related commentary

More on related legal questions

AI & Tech

EU AI Act Scope and Key Definitions: Systems, Risk Categories and Core Concepts

Before applying the EU AI Act, businesses need to distinguish AI systems from general-purpose AI models, understand the main risk categories, and map the roles of providers, deployers and other actors in the AI value chain.

Read commentary

AI & Tech

Territorial Scope of the EU AI Act: When Non-EU Companies Are Caught

The EU AI Act can affect organisations outside the European Union, but not simply because they use AI. Territorial scope depends on market access, putting systems into service, and certain cases where AI outputs are used in the Union.

Read commentary

AI & Tech

General-Purpose AI Models Under the EU AI Act

General-purpose AI models are treated separately from many downstream AI systems under the EU AI Act. Providers need to understand the difference between a model, an AI system built on that model, and additional obligations for models with systemic risk.

Read commentary