
Provider vs Deployer Under the EU AI Act: Which Are You?
The One Question That Sets Your Obligations
Once you know your AI system's risk tier, the next question decides almost everything else: what is your role? The EU AI Act hands out duties by role, and the gap between the two main ones is wide. Pick wrong and you do the wrong work.
Two roles matter for most companies. Provider and deployer. And here is the twist that trips people up: plenty of small teams are both at the same time, on different systems. The fast way to find yours is the free risk check, which returns your role and your tier in about 90 seconds.
Find your role free (90 seconds)Provider: You Build It or Brand It
You are a provider if you develop an AI system, or have one developed for you, and put it on the market or into service under your own name or trademark. Article 3 is blunt about this. It does not matter whether you charge for it or give it away. If your name is on it, you are the provider.
Providers carry the heavy end of the Act. For a high-risk system, Article 16 expects you to:
- run a risk management system (Article 9) and govern your training data (Article 10),
- produce technical documentation (Article 11) and keep automatic logs (Article 12),
- build in human oversight (Article 14) and hit accuracy, robustness, and security targets (Article 15),
- pass a conformity assessment, apply the CE marking, and register the system before it goes live.
That is the price of being the one who put the system into the world.
Deployer: You Put It to Work
You are a deployer if you use an AI system under your own authority in the course of your business. The recruiter running a screening model, the support team behind an AI chatbot, the finance lead using an AI forecasting tool: all deployers.
Deployer duties (Article 26) are lighter, but they are not nothing:
- use the system the way its instructions tell you to,
- give a real person the authority and the competence to oversee it,
- make sure the input data you feed it is relevant,
- keep the logs, watch for serious incidents, and report them,
- tell your workers when an AI system is used on them, and tell affected people where the Act requires it.
Some deployers also owe a fundamental rights impact assessment under Article 27: public bodies and certain private operators.
Provider vs Deployer at a Glance
| Provider | Deployer | |
|---|---|---|
| You are this if | You build the AI system or put your name on it | You use someone else's AI system in your business |
| Core duties | Risk management, data governance, technical docs, conformity assessment, CE marking, registration | Use per instructions, human oversight, monitoring, incident reporting, worker notice |
| Typical example | A start-up shipping its own AI feature | A team using a third-party AI tool |
The Trap: When a Deployer Becomes a Provider
Here is the part that catches people. Under Article 25, a deployer can turn into the provider of a high-risk system without meaning to. It happens three ways:
- you put your own name or trademark on a high-risk system that is already on the market,
- you make a substantial modification to it,
- you change what it is used for in a way that makes it high-risk.
Fine-tune a model and ship it as your own? Rebrand a vendor's tool and sell it on? You may have just inherited the full provider obligations. This is exactly where small companies slip, because it feels like "just using a tool" right up until it is not. If any of this sounds like you, the risk check will flag it.
Check whether you are a providerA Quick Example: One Company, Two Roles
Picture a 30-person HR SaaS. It builds its own CV-ranking feature and sells it to clients. There, it is the provider, and because CV ranking is an Annex III employment use, that feature is high-risk with the full provider load. The same company runs an off-the-shelf AI chatbot for internal IT questions. There, it is the deployer, with the lighter Article 26 duties.
One company, two roles, two very different to-do lists. This is why "are we a provider or a deployer?" rarely has a single answer, and why mapping it system by system is the only way to get it right.
Most Small Companies Are Both
If you build your own AI feature and also use third-party AI inside your business, you are a provider of the first and a deployer of the second, at the same time. That is normal. The Act tracks roles per system, not per company. You do not pick one identity for the whole business. You map each system to its own role and its own set of duties.
Two more roles round out the picture. An importer places a third-country provider's system on the EU market. A distributor passes a system further down the chain. Both carry checks of their own, but for most SaaS companies the provider and deployer roles are the ones that bite.
Your Next 90 Seconds
- Find your role. The risk check returns your role and risk tier for each system in about 90 seconds.
- Map the duties. AI Comply HQ turns your role and tier into the exact obligations and drafts the documentation for you. A consultant charges €10,000 or more for the same scoping. Our plans start at $97 a month, and the check is free.
- Stay ready. One dashboard, every system, every deadline, no surprises.
Frequently Asked Questions
Can a company be both a provider and a deployer? Yes, and most are. You can be the provider of your own AI feature and the deployer of a third-party tool at the same time. The Act assigns roles per system, so you can hold both.
If I fine-tune GPT or Claude and ship it as my own product, am I a provider? Most likely yes. Putting your name on a system, or making a substantial modification to it, can make you the provider under Article 25, with the full provider obligations for high-risk systems.
Are deployer obligations really lighter than a provider's? Yes, but lighter is not zero. Human oversight, monitoring, incident reporting, and AI literacy all apply, and certain deployers owe a fundamental rights impact assessment under Article 27.
We only use AI internally. Are we a deployer? Yes. Using an AI system under your authority in your business makes you a deployer. The one carve-out is purely personal, non-professional use, which a business activity is not.
For more, see whether small companies have to comply at all, what your AI chatbot owes, the GPAI requirements that sit upstream of you, and our guide to risk classification.
Update: Where the Digital Omnibus Stands (June 12, 2026)
A quick note before you act on any date in this article. The Digital Omnibus is a simplification package the European Commission proposed on November 19, 2025. It would amend several EU digital laws at once, and for the AI Act it proposes two big changes: the high-risk obligations would apply later (December 2, 2027 for the stand-alone high-risk systems listed in Annex III, and August 2, 2028 for high-risk AI embedded in regulated products), and a number of requirements would be simplified along the way.
Here is the part that matters: none of this is law yet. The European Parliament and the Council reached a provisional agreement on May 7, 2026, and formal adoption is expected, but until the final text is adopted and published, nothing changes. The dates and obligations described in this article are the ones in force today. And the rules that already apply, like the prohibited practices and the AI literacy duty, stay exactly where they are no matter what happens to the Omnibus.
We are watching this closely. The moment the Omnibus is adopted, amended, or rejected, we will update this article to reflect the new EU AI compliance dates. Check back, or run the free 90-second risk check to see your obligations under the rules as they stand right now.