Are You a Provider or a Deployer?

Under the EU AI Act you are a provider if you develop an AI system, or have one developed, and place it on the market or put it into service under your own name or trade mark. You are a deployer if you use one under your own authority in a professional capacity. Everything else about your obligations follows from that one determination, and most organisations get it wrong in the same direction.

The short answer

Call a hosted model through an API and build an internal tool with it: you are a deployer of that tool, and quite possibly its provider too if the tool is itself an AI system you put into service. Sell that tool to customers under your own brand: you are unambiguously a provider. Buy a finished product and use it: deployer. Buy a finished product, put your logo on it and sell it on: provider, and the original developer drops out of the picture as far as your customers are concerned.

The direction organisations get it wrong is under-claiming. Teams assume that because they did not train a model they cannot be a provider. The definition says nothing about training. It says “develops an AI system or has an AI system developed and places it on the market or puts it into service under its own name or trade mark”. An application built on somebody else’s model, shipped under your name, is a system you had developed and placed on the market.

The definitions, precisely

Four words in those definitions do the work, and each has a technical meaning in EU product law:

• Placing on the market is the first making available of a system on the Union market. It happens once, for a given individual system.
• Putting into service is supply for first use directly to a deployer or for own use, for its intended purpose. “For own use” is the clause that catches internal tools: an organisation that builds a system and uses it itself has put it into service and is its provider.
• Under its own name or trade mark is what distinguishes provider from distributor. Rebranding is the act that transfers the role.
• Under its own authority is the deployer test. It means control over the decision to use the system and the purpose it is used for. An employee using a tool their employer bought is not a separate deployer; the employer is.

The personal non-professional carve-out in the deployer definition is narrow. It excludes an individual using a chatbot at home. It does not excuse an individual using one for their job, and it does not turn on whether the organisation is commercial — charities, hospitals and public authorities are all deployers.

How a deployer becomes a provider

Article 25 is the article to read if you take one thing from this page. It says that a distributor, importer, deployer or other third party is considered a provider of a high-risk system, and takes on the full provider obligations, in three situations:

1. They put their name or trade mark on a high-risk system already placed on the market or put into service. Contractual arrangements allocating obligations otherwise do not change this.
2. They make a substantial modification to a high-risk system already on the market, in a way that means it remains high-risk.
3. They modify the intended purpose of a system — including a general-purpose AI system — that was not classified as high-risk, in such a way that it becomes high-risk.

The third limb is the one that catches ordinary integration work. A general-purpose chat model is not high-risk. Point it at CV screening and you have modified the intended purpose in a way that lands the system in Annex III, and you are the provider of that high-risk system — not the model vendor.

The saving grace in Article 25 is that when this happens, the original provider ceases to be the provider of that particular system, and must cooperate: supply the information and technical access reasonably needed for the new provider to meet its obligations. If your vendor refuses to give you what you need, that refusal has a legal answer, and it belongs in the contract you sign with them.

A separate provision protects providers who explicitly exclude a high-risk use in their instructions: a general-purpose system provider who has excluded high-risk uses is not automatically dragged in when a customer ignores that. This is why vendor acceptable-use policies list prohibited use cases in the exact language of Annex III. Those lists are not lawyer decoration. They are the provider allocating the role to you.

What each role actually owes

For a high-risk system, the asymmetry is severe. Providers carry the engineering burden; deployers carry the operational one.

On top of that, some deployers must carry out a fundamental rights impact assessment under Article 27 before first use: bodies governed by public law, private entities providing public services, and deployers of systems used for creditworthiness assessment or for risk assessment and pricing in life and health insurance. It is not a duty on every deployer, and it is not the same document as a GDPR data protection impact assessment, though the two overlap enough that they should be written together.

Eight integration patterns, resolved

Holding both roles at once

Holding both is normal and is not a problem in itself. An organisation that builds a system and uses it internally is provider and deployer of the same system, and owes both sets of duties. The mistake is assuming that one role absorbs the other. It does not: the Article 26 duties are not implied by the Article 16 ones, and the workforce notification duty in particular has no provider-side equivalent.

There is one real economy. Where you are both, the “instructions for use” you must follow as deployer are the ones you wrote as provider. That sounds circular and it is exactly the point: the discipline it forces is that you have to write down how the system is meant to be used, in enough detail that a person could be found not to have followed it.

You cannot contract out of the role

Article 25 says explicitly that contractual arrangements do not change the position where a party puts its name on a high-risk system. The role attaches to conduct. A clause saying “Customer shall be the provider for the purposes of Regulation (EU) 2024/1689” does not make the customer the provider if the supplier’s brand is on the product.

What a contract can do is allocate cost and cooperation: indemnities, obligations to supply technical documentation, notice before a model changes, audit rights, and an agreed statement of the intended purpose. That last one is quietly the most valuable clause in an AI contract, because the intended purpose is the fact the whole classification hangs on, and having it in writing from the supplier is your evidence about what the system was for.

Write the determination down

The output of this analysis is a short memo per system, and it is the first document a supervisory authority will ask for. It needs six fields and nothing more:

system: cv-shortlister
intended purpose: rank inbound applications for recruiter review
role: provider AND deployer
  provider because: system built in-house, put into service for own use;
    Article 25 third limb also engaged (general model repurposed)
  deployer because: used under our own authority in HR
classification: high-risk, Annex III area 4 (employment)
  Article 6(3) derogation considered and rejected: system profiles
    natural persons, so the derogation is unavailable
decided: 2026-08-04  by: (name, role)  review: 2027-02-04

Keep one of these per system, dated and signed off by somebody with authority. It costs an hour and it is the difference between a defensible position and an argument you have to reconstruct from memory two years later. The same file feeds the evidence pack and your AI risk register.