You're a deployer — until you're a provider.
Most organisations using AI are deployers: you run a system someone else built, and your duties are real but manageable. But the EU AI Act lets you cross — by accident — into being its provider, and inherit a maker's full obligations. Three everyday moves do it. Here's the line, where it bites hardest, and how to stay on the right side of it.
One word apart, a world of work apart.
The Act splits the world into roles. A provider builds an AI system or puts it on the market — the manufacturer. A deployer uses one in their own organisation — the operator. For a high-risk system, the gap between the two roles is the difference between running a project and running a policy. New to these terms? Start with the EU AI Act guide.
A project that runs for the life of the system
- Run a conformity assessment before launch
- Write the technical documentation
- Stand up a quality-management system
- CE-mark it and register it in the EU database
- Monitor it after launch and report incidents
A policy you run day to day
- Use it within the maker's instructions
- Keep a competent human genuinely in control
- Keep the logs it produces
- Inform the staff and people it affects
Most companies are deployers — and quietly assume they'll stay that way. That assumption is the trap: for a high-risk system, becoming the provider can mean months of conformity work, so whether you've become one matters long before you write a word of policy.
Three everyday moves flip the switch.
Article 25 of the Act names exactly three. None requires writing a model from scratch — each is something an ordinary buyer might do on a Tuesday afternoon.
You put your name on it
You take a high-risk system someone else built and put it on the market under your own brand or trademark. To everyone downstream it is your product now — so the Act treats you as its provider.
Art. 25(1)(a)
You change it substantially
You take a high-risk system that is already on the market and alter it beyond what its maker planned and assessed — effectively a different system, still high-risk. The maker's duties transfer to you.
Art. 25(1)(b)
You give it a new job
You take a system that was not high-risk — including a general-purpose model like the ones behind ChatGPT or Claude — and point it at a high-risk use. The use is what the Act regulates, so it is now a high-risk system, and you are its provider.
Art. 25(1)(c)
The original builder doesn't simply vanish — the Act requires them to give the new provider the information and access they'd need. But the obligations, and the liability, move to you.
What you call it doesn't matter. What it does, does.
The line isn't crossed by paperwork; it's crossed by behaviour. "We only configured it." "It's a light fine-tune." "It's just an internal wrapper." "It's only a pilot." None of those labels is a defence — the Act looks at what the system now does, not at the name on the change request.
The one thing that genuinely protects you is staying inside the intended purpose the maker set out in the instructions for use. Step outside that envelope and you may have repurposed the system — trip-wire three — without ever deciding to.
"Configuration", "fine-tune", "wrapper", "pilot" — none is a defence. Stay inside the maker's intended purpose, or you may have become the maker.
There is a narrow way out — a system used in a sensitive area but doing only genuinely preparatory, procedural work can escape the high-risk label. It is narrower than most vendors imply, and it collapses the moment the system starts to profile people. Which side of that line you sit on is exactly the kind of question worth getting read before you ship, not after.
Recruitment is the high-frequency trap.
The most common place to trip wire three is hiring — because it's where general tools meet a high-risk use the Act regulates hard (Annex III, employment). Each of these looks like a harmless tweak and each can turn a tool you bought as low-risk into a high-risk hiring system that you now provide:
- a general workforce-analytics tool, plus your own scoring weights;
- a general chatbot prompted to rank or sit in judgement on candidates;
- a CV parser, plus your own pass / fail thresholds;
- an assistant repurposed to produce a "key strengths" verdict on each applicant.
The danger is quiet. Nobody ever signs a note saying "we are now the provider of a high-risk AI system" — you simply discover, later and from the wrong side, that you are. For the full tiered picture of AI across HR, from easy wins to this exact line, see AI for HR & talent.
What you inherit the moment the role flips.
Cross the line and you take on the provider's full stack: a conformity assessment, technical documentation, a quality-management system, CE marking and EU-database registration, and post-market monitoring for the life of the system. None of it is impossible — but all of it is a programme of work, and it lands whether or not you meant to step into the role.
And the teeth: penalties are set as a share of worldwide annual turnover — and they stack with GDPR rather than replace it. For most companies, though, the sharper cost is commercial: the enterprise deal that stalls in due diligence when a buyer's lawyers ask "so who is the provider here?" and you don't have a clean answer.
Which role are you actually in?
Run each AI system you use through four questions. A "yes" to any of the first three means you may be a provider, not just a deployer — and it's worth confirming before someone else does it for you.
This places you on the map; it doesn't replace the real assessment. The edges — what counts as "substantial", whether a use is truly high-risk, whether the narrow carve-out applies — are where the judgement lives.
Know which role you're in — before a regulator or a buyer asks.
We place each of your AI systems on the right side of the line, tell you what the role you're actually in requires, and build the evidence to back it — through the AI Act Compliance Accelerator. And if you're still procuring, we help you get the contract and the intended-purpose envelope right before you sign, so you don't inherit a provider's duties by accident.
Deployer, or provider? Bring the system and find out.
An honest read of where you stand. No pitch.
Book a discovery call →Related guides
The EU AI Act, explained
Heard of it, hazy on the detail? Grasp it through two laws you may already know — GDPR and product-safety regulation.
Read the guide Local & sovereign AIRunning your own AI isn’t compliance
Running the model yourself — on-device, on-premise, on sovereign EU infrastructure — is a real win for data control. But where a model runs answers residency, not conformity: the EU AI Act regulates the use, wherever inference happens. The traps, and where sovereign AI genuinely pays off.
Read the guide