EU AI Act
AI-generated Under the EU AI Act, companies that use AI mainly have two roles: deployer and provider. Almost all are deployers, and permanently so. Only a few become providers, some even without consciously deciding to. Those who know the difference make that decision with open eyes, instead of discovering it afterwards.
Deployer is the rule, provider the exception
The deployer uses finished AI in their own operation. You buy a tool, you use it, done. Your obligations are manageable and depend on how risky the use is. Nine out of ten companies are exactly that in everything they do with AI: deployers.
The provider, by contrast, builds the AI and places it on the market under its own name. It bears the heavy load, for high-risk all the way to conformity assessment and CE marking. These are normally the manufacturers, from OpenAI to the specialised software house, not you.
So provider is the rare role. That’s precisely why many overlook that you can grow into it even without developing anything yourself.
Three things shift the role
Article 25 names three situations in which a deployer becomes a provider.
You substantially retrain a third-party model with your own data. You place third-party AI on the market under your own name or label. Or you use a system for a purpose other than the intended one, and this new purpose lifts it into a higher risk class.
Mere configuration doesn’t trigger this. Anyone who adjusts default settings stays a deployer. The threshold is deliberately high: it’s about a real change in the nature or purpose of a system, not a checkbox in the options.
What can happen when the role flips
The role change in itself is not a problem. What matters is the risk class of the new use.
If the purpose stays harmless, the provider role stays light too. Anyone who builds a small automation that suggests product texts, or an email sorter, is a provider, but without the heavy program. No conformity assessment, no CE. What remains is transparency: if the system talks to people or generates content, you label it as AI.
It looks different when the new purpose falls into high-risk. Then the full program applies: conformity assessment, technical documentation, CE marking. And here it becomes practically unsolvable. You simply cannot produce these proofs for a third-party general-purpose tool, you didn’t build it and don’t know its internals. You would be the provider of a system you can never make conformant.
An example makes the jump tangible. An AI assistant that writes meeting minutes is fed with job interviews and is supposed to rate candidates. Minutes were intended; it’s used for a hiring decision, so high-risk under Annex III. With this change of purpose, the company becomes the provider of a high-risk system for which it cannot supply conformity. Not out of negligence, but because nobody was aware of the difference between “using” and “being responsible for”.
Why agencies and software houses should look more closely
Anyone who builds or adapts AI for others switches roles faster than a mere user. If an agency builds its client a solution that filters job applications instead of a harmless email sorter, it is the provider of a high-risk system, and the client becomes a high-risk deployer. This responsibility is rarely in the project contract, but in an emergency it is very real. For anyone who develops AI solutions for clients, this view is part of the craft.
Decide deliberately instead of noticing after the fact
The role isn’t a matter of chance, but of attention. Three habits are enough.
Before any change of purpose, check the instructions for use. What’s stated there as the intended purpose is the line. Anyone who goes beyond it should want to know.
For genuine high-risk tasks, take a system built and tested for that, instead of a repurposed general-purpose tool. Then the manufacturer stays the provider, and you are cleanly just the deployer.
And for every AI system, record what it is used for and which role follows from that. This combination of tool and purpose is the AI process. It’s exactly this mapping that the NADOVO platform makes visible. How to build the overview is shown in our 4-week plan, and where the role question gets tricky, we clarify it in our AI compliance consulting.
One question to close. For every AI use in your company, do you know whether you merely use it or already bear responsibility for it? Those who can answer that decide deliberately. Where you stand is shown by our quick check.
About the author
Jochen Stier is a co-founder of NADOVO with over 20 years of experience in process management and IT service management. He helps German SMEs implement the requirements of the EU AI Act systematically and pragmatically. His 5-phase NADOVO framework combines regulatory requirements with practical feasibility, without enterprise budgets or complex tools.
Further reading: