Deployer or Provider: Your Role Under the EU AI Act

Am I a deployer or a provider under the EU AI Act? If you only use a finished AI system under your own authority, you are a deployer and carry few duties. If you pass it on under your own name or rebuild it substantially, you become a provider and take on the full obligation set. This single distinction decides how much the AI Act asks of you.

Updated: 2026-09-08

The question sounds like paperwork, but it is the most expensive fork in the whole regulation. Most SMBs either buy AI or run an open model in house, and in both cases they are deployers with a short list of duties. The trouble starts when the role flips without anyone noticing. There is no form to file and no switch to flip: the change happens through an action, and that is exactly why so many miss it.

The two roles in the legal text

The definitions sit in Article 3 of Regulation (EU) 2024/1689, the AI Act itself. A provider, under Article 3(3), is anyone who develops an AI system, or has one developed, in order to place it on the market or put it into service under its own name or trademark. A deployer, under Article 3(4), is anyone who uses an AI system under its own authority, unless that use is purely personal.

The difference is one of direction. The provider stands at the start of the chain and brings the system to market. The deployer stands at the end and uses it for a purpose. A software house that builds and sells a hiring tool is a provider. The HR department that runs it is a deployer. That holds even inside one group of companies, because the role attaches to the act, not to the letterhead.

The normal case for an SMB: you are a deployer

For the large majority of small and mid-sized firms, the role question ends here. If you run Microsoft Copilot, a bought-in chatbot, or an open-weight model such as Llama or Qwen on your own server, you are a deployer. Self-hosting does not turn you into a provider, as long as you use the system as intended. Where the model runs is irrelevant to the role: local AI on your own hardware and a cloud service are treated the same way.

The second fork matters more: the full deployer duties only apply to a high-risk system under Annex III. Those are narrowly drawn uses, in areas such as recruitment, credit scoring, or critical infrastructure. A model that searches internal documents or drafts emails almost never qualifies. For those systems, little of the deployer duty set remains, apart from the transparency rule we come to below.

When a deployer becomes a provider

Here is the trap. Article 25(1) names three cases in which a deployer or another third party counts as a provider and takes on the full obligation set:

• You put your name or trademark on a high-risk system that is already on the market. Reselling under your own label turns you into a provider.
• You make a substantial modification to a high-risk system, and it stays high-risk.
• You change the purpose of a system so that it becomes high-risk, even if it was not before.

All three cases require a link to high-risk. Running a harmless system and tinkering with it does not make you a provider. Article 25 only bites once the system falls under Annex III, or crosses into it because of your change. That is the main reassurance for everyday use, and also the point where you have to look closely.

What counts as a substantial modification

The term is defined in Article 3. It means a change made after the system was placed on the market that the original provider did not foresee, and that either affects the system's compliance or shifts its intended purpose. An update the maker planned for is not a substantial modification. A rebuild you undertake on your own can be one.

In practice, lawyers argue over three borderline cases with locally run models: fine-tuning on your own data, rebuilding a retrieval pipeline, and training on a domain-specific dataset. Whether that counts as a substantial modification depends, based on our reading, on whether the system is high-risk and whether the change touches its compliance or its purpose. Fine-tuning a language model for internal search is not, in itself, a change of role. Rebuilding that same model to prepare credit decisions may well be. The rule of thumb: the technology does not decide, what the changed system ends up doing does.

Which duties attach to which role

For high-risk systems, the AI Act splits the work cleanly. The provider carries the duties from the design stage, the deployer the ones from operation.

Under Article 16, the provider must, among other things, run a risk and quality management system, draw up the technical documentation, pass a conformity assessment, affix the CE marking, register the system, and supply instructions for use. That is the heavy part, and it arises on the drawing board, long before the first use.

Under Article 26, the deployer has a much shorter list: use the system according to the instructions, ensure competent human oversight, monitor operation, control the input data within its reach, keep the automatically generated logs for at least six months, and inform the provider or the authority of risks and incidents. Where the system is used in the workplace, the deployer must inform the affected workers and their representatives beforehand. Article 26 grants no general exemption for SMBs, though supportive measures for smaller firms sit elsewhere in the regulation.

Anyone who becomes a provider through Article 25 takes on the long list in full. That is why the role change is so costly: it shifts the burden from the short deployer part to the full provider part.

The duty that applies to everyone

One misunderstanding is stubborn: that the AI Act only concerns high-risk operations. That holds for the deployer and provider duties above, but not for Article 50. The transparency duty has applied since 2 August 2026 and depends neither on the high-risk classification nor on whether you are a deployer or a provider.

Run a chatbot, and you must disclose that users are talking to a machine. Publish AI-generated images or text on matters of public interest, and you must mark them as such. Providers of generative systems must make their output machine-readable. These duties reach almost every firm that uses AI outward-facing, and they are the most common point of contact with the law. The detail is in our piece on chatbot and AI-content transparency.

Local AI and the role question

Whether you run a model in the cloud or on your own server changes nothing about deployer or provider. What changes is your ability to prove the role. With a self-hosted system, you know which model runs, what data goes in, and what you have altered. That is exactly the traceability Article 26 demands, and the heart of data sovereignty.

The price is attention in the right place. Rebuild a local model far enough that it tips into a high-risk purpose, and you become a provider and have to carry that. The upside: because you hold the build yourself, you see the role change coming. With a bought-in black box, you often notice only in a dispute that an add-on feature shifted the system.

Concrete steps

Clearing up the role takes four questions per system. First: am I using it as the maker intended, or have I rebuilt it? Second: does the purpose fall under Annex III, into a high-risk area? Third: do I pass the system on under my own name? Fourth: do I run a chatbot or publish AI content, so that Article 50 applies? Answer the first three with no, and the fourth honestly, and you are a deployer with very little to do. Our guide on the high-risk timeline covers the second question in more depth.

This account is our reading of the current legal situation and does not replace a review of your specific case. If you want to know which role your systems sit in, and how an audit-ready local setup simplifies the role question, talk to us about a pilot project.