Are You a Deployer or a Provider? The AI Act Role Test That Decides Your Whole Obligation Set

Most firms assume they are a deployer of AI, not a provider, and most are right — until an ordinary engineering or procurement decision quietly moves them across the line and hands them a heavyweight obligation set nobody signed off on.

The provider/deployer distinction is the single most consequential classification in the EU AI Act, and it is the one firms think about least. It is treated as a fixed attribute — we buy AI, therefore we are a deployer — when in fact it is a status you can acquire through actions you take after the system is in your hands. Article 25 sets out exactly how a deployer becomes a provider. It reads like a footnote. It behaves like a trapdoor.

Why the gap between the two roles is so large

The Act defines a provider, in Article 3, as the party that develops an AI system — or has one developed — and places it on the market or puts it into service under its own name or trademark. A deployer is the party using an AI system under its own authority in a professional capacity. Those are different verbs doing very different work.

For a high-risk system, the deployer’s duties are real but bounded: use the system in line with the instructions, assign competent human oversight, monitor operation, keep the logs you generate, and inform the provider and authorities of serious incidents or risks. The provider’s duties are an entire regime. A provider of a high-risk system must run a quality management system, compile and maintain technical documentation, put the system through conformity assessment, draw up an EU declaration of conformity, affix the CE marking, register the system in the EU database before it goes into service, and operate post-market monitoring across its lifetime. Article 16 lists them; the surrounding articles fill each one out. The distance between “monitor and report” and “stand up a conformity and CE-marking programme” is the distance between a policy and a product line.

This is the same structural problem as the one I have written about in the AI Act and GDPR dual-obligation trap: a single deployment can pull in a much larger obligation set than the party running it realised it had accepted. The difference here is that you can walk into it entirely by your own hand.

The three ways you flip from deployer to provider

Article 25(1) names three triggers. Each is an action an ordinary business does without thinking of it as a regulatory event.

1. You put your name or trademark on it. Take a high-risk system already on the market and place it into service under your own brand, and you are its provider for AI Act purposes. Re-badging a supplier’s model as your own product is the cleanest example, and the one a marketing decision can trigger without any engineering involvement at all.
2. You substantially modify it. Make a substantial modification to a high-risk system that keeps it high-risk, and the modified system is treated as yours. This is the fine-tuning and integration case — the one engineering teams walk into.
3. You change its intended purpose. Take a system — including one that was not high-risk — and modify its intended purpose so that it now falls into a high-risk category, and you become the provider of a high-risk system. You can manufacture a high-risk system out of a general-purpose one purely by deciding to use it for something new.

When any of these fires, Article 25(2) says the original provider is no longer the provider of that system. They must cooperate and hand over the technical access and information you need — but the obligations, and the liability that rides with them, are now yours. You do not inherit their conformity work as a completed asset. You inherit the duty to have done it.

What “substantial modification” actually means

This is where the honest engineering judgement sits. Article 3 defines a substantial modification as a change made after the system is on the market that was not foreseen or planned in the provider’s initial conformity assessment, and that either affects the system’s compliance with the high-risk requirements or changes the intended purpose against which it was assessed.

Read that carefully, because it does two useful things. It tells you that changes the provider anticipated and covered in their assessment — configuration within documented bounds, updates the provider ships and controls — are not substantial modifications. And it tells you that the test is not “did we touch the model” but “did we move it outside what was assessed.” Retraining on your own data in a way that changes behaviour against the assessed requirements is a candidate. Bolting the system onto a decision it was never evaluated for is a candidate. A prompt change inside the documented envelope is not. The line is the conformity assessment’s scope, not the size of the code diff.

A decision procedure to run before procurement runs it for you

The failure mode is not malice or ignorance of the law. It is that the role-flipping decisions are distributed. Marketing decides the branding. A data science team decides to fine-tune. A product owner decides to point the tool at a new use case. None of them is looking at Article 25, and no single person sees that the sum of those choices has made the firm a provider. The fix is a lightweight classification gate that every material AI change passes through. For each system, ask and record:

• Is the underlying system high-risk, or would our intended use make it so under the Annex III categories?
• Are we placing it into service under our own name or trademark?
• Does our change fall within the purpose and bounds the provider documented and assessed — and can we point to where they said so?
• Does our change alter the intended purpose or the assessed high-risk compliance?

Answer those honestly and the role is usually obvious. The guardrails follow from it: contract terms that pin down what the provider will disclose and support if a modification is contemplated; a rule that re-branding a third-party high-risk system needs sign-off from whoever owns the compliance budget, not just the brand; and a fine-tuning policy that treats “stay inside the assessed envelope” as a design constraint, not an afterthought. If you conclude you are the provider, the work starts with the quality management system the Act expects a provider to run — the spine the rest of the obligations hang from.

Why this is worth doing now, not in 2027

The Digital Omnibus adopted in mid-2026 pushed the standalone high-risk obligations under Annex III to 2 December 2027, and high-risk systems embedded in regulated products under Annex I to 2 August 2028. That is more runway than the original timetable gave, and it will be read by some as permission to wait. It is the opposite. Provider status is not something you assess once, close to the deadline. It is accreted by decisions made continuously between now and then — every fine-tune, every re-badge, every new use case. A firm that reaches late 2027 having quietly become the provider of three high-risk systems it never meant to own has not bought time. It has spent it acquiring obligations in the dark.

Classify the role before you build, and it is a governance decision you control. Discover it in an audit, and it is a liability you already hold.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.