Almost every obligation in the AI Act depends on one question: what is your role? The Regulation distinguishes between two main roles:

• the provider, who develops an AI system and places it on the market or puts it into service;
• the deployer, who uses it.

Providers of high-risk systems carry the heaviest burden: risk management, data governance, technical documentation, conformity assessment, registration and post-market monitoring. Deployers have lighter, although still significant, obligations.

The distinction sounds simple, but it is easy to get wrong. Companies that believe they are merely using AI may in fact be providers, and the role can change during the life of a system. This article explains the test and applies it to common situations.

‍

The definitions

A provider is a natural or legal person, public authority or other body that develops an AI system or a general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge.

A deployer is a person or organisation that uses an AI system under its authority, except in the course of a personal, non-professional activity.

Three elements of the provider definition deserve attention:

• A provider does not need to write the code itself. Having the system developed by someone else is enough.
• “Putting into service” includes supplying a system for one’s own use. A company that builds an AI system for internal use is therefore its provider.
• The decisive factor is the name or trademark under which the system is offered.

The AI Act also defines importers, distributors and authorised representatives. In addition, it treats as providers the manufacturers of certain regulated products, such as medical devices, who place on the market under their own name products that incorporate high-risk AI systems as safety components.

‍

When a deployer becomes a provider

Article 25 addresses the situations in which a company that did not originally develop a high-risk system takes on the provider’s obligations. A distributor, importer, deployer or other third party is considered the provider of a high-risk system if it:

• puts its own name or trademark on a high-risk system already placed on the market;
• makes a substantial modification to a high-risk system in such a way that it remains high-risk;
• modifies the intended purpose of a system that was not high-risk, including a general-purpose AI system, in such a way that it becomes high-risk.

In these cases, the original provider is no longer considered the provider of that specific system. It must, however, cooperate with the new provider and supply the information and technical access needed to comply. This cooperation obligation does not apply where the original provider has clearly specified that its system is not to be changed into a high-risk system.

‍

Eight practical cases

‍1. Using a generative AI tool internally. A company gives its employees an enterprise subscription to a commercial AI assistant to draft emails and summarise documents. The company is a deployer, and the tool’s supplier is the provider.

2. A SaaS product built on a third-party model. A software company adds an AI feature to its product, using a large language model accessed through an API, and sells the product under its own brand.

• The company is the provider of the AI system it markets.
• It is also a “downstream provider” with respect to the general-purpose model it integrates.
• Its customers are deployers.

3. A custom-built chatbot. A retailer commissions a digital agency to build a customer-service chatbot and puts it into service on its website under its own brand.

• The retailer had the system developed and puts it into service under its own name, so it is both the provider and the deployer.
• The agency develops the chatbot on the retailer’s behalf, so it is not the provider, unless it also markets the chatbot to others under its own name.

4. Fine-tuning an open-weight model for internal use. A company fine-tunes an open-weight model on its own documents and uses it internally. It is the provider of the resulting AI system, which it puts into service for its own use. Whether it also becomes the provider of a new general-purpose AI model is a separate question. Under the Commission’s guidelines, this happens only if the modification is significant, with an indicative threshold of one third of the computational resources used to train the original model. Most fine-tuning falls well below that level.

5. A bank using a credit-scoring tool. A bank buys a credit-scoring system from a specialist supplier and uses it to assess applicants.

• The system is high-risk, and the bank is its deployer, with the obligations that come with that role.
• Because it uses the system to evaluate creditworthiness, the bank must also carry out a fundamental rights impact assessment. The same applies to insurers that use AI for risk assessment and pricing in life and health insurance. Systems used only to detect financial fraud are not high-risk.
• If the bank rebranded the tool and offered it to other lenders, it would become a provider.

6. Repurposing a general tool for recruitment. An HR department configures a general-purpose chatbot to screen and rank job applications. Using the system for a purpose listed as high-risk modifies its intended purpose so that it becomes high-risk. The company is therefore treated as the provider of that high-risk system, with all the corresponding obligations.

The AI Act allows a system used in a high-risk area not to be considered high-risk if it only performs a narrow procedural or preparatory task. That exception is never available, however, when the system profiles people, which ranking candidates usually does, and the assessment must be documented in any case. Repurposing is one of the most common and least recognised ways of becoming a provider.

7. Reselling a non-EU system. A European company sells an AI system developed by a company established outside the EU.

• If it is the first to place the system on the EU market, it is an importer.
• If it resells a system already placed on the market, it is a distributor.
• Both roles have specific verification obligations.
• If it sells the system under its own brand, it becomes the provider.

A non-EU provider of a high-risk system must also appoint an authorised representative in the EU.

8. A medical device with an AI safety component. A medical device manufacturer integrates an AI component that adjusts dosage in an infusion pump, and places the device on the market under its own name. As the product manufacturer, it is treated as the provider of the high-risk AI system.

After the Digital Omnibus, the same rule no longer applies directly to machinery. The Machinery Regulation has been moved to the part of Annex I where AI requirements apply through the sectoral legislation rather than through the AI Act itself.

‍

Why the role matters

For systems that are not high-risk, the difference between provider and deployer matters mainly for transparency:

• Providers must design chatbots so that people know they are talking to AI, and must mark synthetic content.
• Deployers must disclose deepfakes and certain AI-generated texts, and must inform the people exposed to emotion recognition or biometric categorisation systems.

For high-risk systems, the difference is fundamental:

• Providers must build and document compliance before the system reaches the market.
• Deployers must use the system correctly, ensure human oversight, monitor it and keep logs. In some cases they must also assess its impact on fundamental rights.

Following the Digital Omnibus, these obligations apply from 2 December 2027 for the systems listed in Annex III and from 2 August 2028 for those covered by Annex I. A company that builds a system now, or decides how to use one, is taking on the role that will define its obligations by then. A company that wrongly considers itself a deployer may find itself without the documentation and conformity assessment that the law requires of it.

‍

A five-question test

For each AI system in your inventory, ask:

1. Did we develop the system, or have it developed for us? If yes, and we use it or offer it under our name, we are likely the provider.
2. Under whose name or brand is the system offered or used? Our own name points to the provider role.
3. Have we modified the system? A substantial modification of a high-risk system can make us its provider.
4. Do we use the system for a different purpose from the one intended by its supplier? If the new purpose is high-risk, we may become the provider.
5. Did the system come from outside the EU? If so, check the importer and distributor obligations and whether there is an authorised representative.

Where to start

Add a “role” column to your AI inventory. Answer the five questions for each system and document the reasoning. Pay particular attention to:

• internally developed tools;
• white-label solutions;
• fine-tuned models;
• any use of general-purpose tools in high-risk areas such as HR, credit or education.

Where the answer is unclear, the safer assumption is that the company bears the provider’s obligations until the analysis shows otherwise.

If you are new to the AI Act, start with our summaries of AESIA Guide No. 1 and AESIA Guide No. 2: together they give a clear map of the Regulation before moving on to the analysis of roles.

The practical question is not “did we write the code?”. It is “whose name is on the system, what have we changed, and for what purpose do we use it?”.

‍