AI Act provider vs deployer is the distinction that decides almost everything else about your obligations. A provider builds or brands an AI system and carries the heavy duties. A deployer uses one under its own authority and carries a much shorter list.
Get the role wrong and you either over-invest in compliance you do not owe, or you build an evidence trail that will not survive contact with a market surveillance authority.
The stakes are not theoretical. Under Article 99 of Regulation (EU) 2024/1689, breaching provider or deployer obligations carries administrative fines of up to €15 million or 3% of worldwide annual turnover, whichever is higher. Since 2 August 2026, the AI Office and national authorities have been actively enforcing the Act.
In this article, we’ll cover how to tell which role you hold, the two situations that quietly turn a deployer into a provider, and a side-by-side table of what each role actually has to do.
What Is the Difference Between a Provider and a Deployer Under the EU AI Act?
A provider develops an AI system, or has one developed, and places it on the EU market or puts it into service under its own name or trademark. A deployer uses an AI system under its own authority in a professional context. The provider is responsible for how the system is built; the deployer is responsible for how it is used.
Two more roles fill the gaps. An importer places a system from a third-country provider onto the EU market. A distributor makes a system available on the market without being the provider or importer.
Here’s how the four roles compare in practice:
| Provider | Builds or brands the system | Risk management, data governance, technical documentation, logging, human oversight design, accuracy and security, conformity assessment, CE marking, registration, post-market monitoring |
| Deployer | Uses the system professionally | Use per instructions, assign competent human oversight, ensure input data is relevant, monitor operation, retain logs, inform affected workers, report serious incidents |
| Importer | Brings a third-country system to the EU | Verify provider conformity, check documentation and CE marking, keep records, cooperate with authorities |
| Distributor | Makes it available on the market | Verify CE marking and documentation are present, act on non-conformity, cooperate with authorities |
Most organizations are deployers. That is the single most useful thing to know about this regulation, and it is also the thing most businesses discover late.
What Are the Obligations of a Deployer Under the EU AI Act?
Article 26 sets out deployer duties for high-risk AI systems. They are operational rather than engineering duties, which makes them achievable — but they do require evidence.
Let’s look at what Article 26 actually asks for:
- Use the system as instructed. Take appropriate technical and organizational measures to operate it in line with the provider’s instructions for use.
- Assign human oversight to the right people. Oversight must go to natural persons with the necessary competence, training, authority, and support. A name on an org chart is not enough.
- Control your input data. Where you control the input data, ensure it is relevant and sufficiently representative for the system’s intended purpose.
- Monitor and escalate. Watch how the system behaves in production and inform the provider without undue delay where you have reason to believe it presents a risk.
- Keep the logs. Retain automatically generated logs for at least six months, unless other Union or national law requires longer.
- Tell affected workers. Before putting a high-risk system into use in the workplace, inform workers and their representatives that they will be subject to it.
One timing note that matters for planning. These high-risk deployer duties apply from 2 December 2027 for Annex III systems, following the AI Omnibus that entered into force on 27 July 2026. Transparency duties under Article 50 apply now.
Does White-Labelling an AI System Make You a Provider?
Yes. If you put your own name or trademark on a high-risk AI system already placed on the market, you become the provider of that system for the purposes of the Act, and the original provider’s obligations transfer to you.
This is the clause that catches managed service providers, software resellers, and consultancies hardest. The commercial instinct to brand a partner’s tool as your own product is exactly the act that moves the regulatory weight onto your balance sheet.
Article 25 sets out the same outcome for two other situations: substantially modifying a high-risk system already on the market, and modifying the intended purpose of a system — including a general-purpose AI system — so that it becomes high risk.
If you are an IT provider weighing this up, three questions are worth answering before you sign anything:
- Are we branding or referring? Reselling under the vendor’s name keeps you a distributor. Rebranding makes you a provider.
- Does the contract match reality? The original provider must cooperate and hand over the documentation you would need. Confirm that in writing before the first customer, not after.
- Can we actually carry provider duties? Technical documentation, conformity assessment, and post-market monitoring are ongoing commitments, not a one-time exercise.
For service businesses building a compliance practice around this, our MSP partner program and partnership program exist to keep delivery capability behind you without the channel conflict.
Does Fine-Tuning a Model Make You a Provider?
It can. Fine-tuning a general-purpose AI model, or otherwise modifying a system substantially, can make you the provider of a new AI system — and where the modification changes the intended purpose so that the system becomes high risk, provider obligations follow.
The Act does not treat every adjustment as substantial. Prompt engineering, configuration within the vendor’s intended parameters, and normal use of documented features generally leave you as a deployer.
The line sits at whether you have changed what the system is for, or changed it so materially that the original provider’s assessment no longer describes it. Most product teams get this wrong in the same direction: they assume that because they did not train a model from scratch, none of it applies to them.
If you are shipping AI features, this question belongs in your design review alongside threat modeling and secure code review, not in a legal review six weeks before launch.
Who Is Liable if an AI Vendor Breaches the EU AI Act?
Liability follows the role, not the invoice. Each operator in the value chain is responsible for its own obligations, so a provider’s failure does not automatically become the deployer’s fine — but a deployer that keeps using a system it knows to be non-conforming has failed its own monitoring duty.
Article 25 requires third parties supplying components, tools, or services for high-risk AI systems to give the provider the information and technical access needed to meet its obligations. In practice, that language becomes a contract clause.
Here’s what to put in front of legal before your next AI purchase:
- Role clarity. Name who is provider, deployer, importer, and distributor for each system in the agreement.
- Documentation access. Commit the supplier to providing instructions for use, technical documentation, and conformity evidence on request.
- Change notification. Require notice of substantial modifications, because a modification can shift your role without you doing anything.
- Incident cooperation. Set out how serious incidents get reported between you and within what timeframe.
- Log availability. Confirm you can actually obtain and retain the logs your own obligations require.
This is ordinary third-party risk management work, applied to a new category of supplier. If you already run a vendor due diligence process, you are extending it rather than starting from nothing.
What Does My Company Actually Have to Do Once It Knows Its Role?
Establishing your role is step three of ten. The baseline work is the same for everyone: inventory every AI system, classify each one, check for prohibited practices, establish governance, write a use and approval policy, deliver AI literacy training, set up vendor governance, run a transparency check, and define an incident route.
What the role decides is everything that comes after that. The gap between deployer and provider is the difference between an operational program and an engineering one.
Here’s what lands on your desk in each role:
| Action | Deployer | Provider | AI Act reference |
| AI inventory and classification | Required | Required | Art. 3(1), 6, 51 |
| Prohibited practice check | Required | Required | Art. 5 |
| AI literacy program | Required | Required | Art. 4 |
| AI use and approval policy | Required | Required | Art. 4, 16, 17, 26 |
| Vendor and value chain governance | Required | Required, both directions | Art. 22–25 |
| Transparency disclosures | Where you interact or publish | Build the disclosure in | Art. 50 |
| Human oversight | Assign competent people | Design the oversight in | Art. 14, 26 |
| Log retention | Six months minimum | Enable automatic logging | Art. 12, 19, 26 |
| Input data quality | Where you control the input | Full data governance | Art. 10, 26 |
| Risk management system | Not required | Required | Art. 9 |
| Technical documentation | Not required | Required, Annex IV | Art. 11 |
| Quality management system | Not required | Required | Art. 17 |
| Conformity assessment and CE marking | Not required | Required | Art. 43, 48 |
| EU database registration | Not required | Required | Art. 49 |
| Post-market monitoring | Monitor and escalate | Full monitoring plan | Art. 26, 72 |
| Serious incident reporting | Inform the provider | Report to authorities | Art. 73 |
| Fundamental rights impact assessment | Certain deployers | Not applicable | Art. 27 |
Two readings worth taking from that table. First, the deployer column is genuinely achievable with existing operational functions. Second, the provider column is a program with a budget line, which is exactly why the white-labelling question above deserves a real answer before you sign anything.
For the full baseline that applies regardless of role, and the breakdown by classification rather than by role, see our guide to whether the EU AI Act applies to your company.
Frequently Asked Questions
What is the difference between a provider and a deployer under the EU AI Act?
A provider develops an AI system, or has one developed, and places it on the EU market or puts it into service under its own name or trademark. A deployer uses an AI system under its own authority in a professional context. The provider is responsible for how the system is built, and the deployer is responsible for how it is used.
What are the obligations of a deployer under the EU AI Act?
Under Article 26, deployers of high-risk AI systems must use the system in line with the provider’s instructions, assign human oversight to competent and properly supported people, ensure input data under their control is relevant and representative, monitor operation and escalate risks to the provider, retain automatically generated logs for at least six months, and inform workers before putting the system into use.
Does white-labelling an AI system make you a provider?
Yes. If you put your own name or trademark on a high-risk AI system already placed on the market, you become the provider for the purposes of the Act and take on the original provider’s obligations. The same applies if you substantially modify a high-risk system, or modify a system’s intended purpose so that it becomes high risk.
Does fine-tuning a model make you a provider?
It can. Fine-tuning a general-purpose AI model or substantially modifying a system can make you the provider of a new AI system, particularly where the change alters the intended purpose so that the system becomes high risk. Prompt engineering and configuration within the vendor’s documented parameters generally do not.
Who is liable if an AI vendor breaches the EU AI Act?
Liability follows the role each operator holds, so a provider’s failure does not automatically transfer to the deployer. However, a deployer that continues using a system it has reason to believe presents a risk breaches its own monitoring duty under Article 26. Article 25 requires suppliers of components and services to give providers the information needed to meet their obligations.
What does my company actually have to do once it knows its role?
Every organization does the same baseline work regardless of role: inventory every AI system, classify each one, check for prohibited practices, establish governance, write a use and approval policy, deliver AI literacy training, set up vendor governance, and define an incident route. Deployers then add human oversight, log retention, input data quality, and monitoring. Providers add risk management, technical documentation, a quality management system, conformity assessment, CE marking, registration, and post-market monitoring.
Strengthen Your AI Governance With CyberGlobal
Getting the role right is not paperwork. It decides your budget, your timeline, and which team owns the work for the next two years.
But with the right partner by your side, this is a question you answer once, properly, and then build on.
At CyberGlobal, our GRC team helps organizations map every AI system they run to a role and an obligation set, then close the gaps in a sequence that fits the business. For IT service providers weighing whether to take this on for their own clients, our MSP partner program puts delivery capability behind you without competing for the relationship.
We will also be straight with you about the cases where the honest answer is that you owe very little. That happens more often than the market suggests.
But behind our advanced technology, there are real people — local teams who stay on the project long after the first assessment lands.
Reach out to CyberGlobal and let us be your ally against today and tomorrow’s cybersecurity challenges.