Who is the provider? The question that decides your obligations
Most organisations describe themselves as users of AI systems and assume the heavy obligations sit with whoever built the model. Several ordinary engineering decisions move that line, and none of them looks like a legal decision when it is made.
The readiness assessment usually opens with a sentence that settles everything after it: we are a deployer, not a provider. It is said with confidence, it is frequently correct, and it is almost never checked against what the engineering teams are actually doing.
The distinction is not decorative. Under the EU AI Act the obligations that attach to placing a system on the market are substantially heavier than the ones that attach to using it, and the line between the two roles moves for reasons that look like ordinary product decisions. Article 25 of the Act sets out when a party along the value chain takes on provider obligations, and the triggers are worth reading in the original because they are shorter and clearer than most summaries of them.
The claim: role is determined by what you do to a system, not by what you call yourself, and three common engineering choices change it.
The three that move the line
Have you done any of these to a system somebody else built?
- You may hold provider obligations for it. White-labelling an assistant into your own product is the most common route, and it is a marketing decision.
- You may hold provider obligations for the modified system. Fine-tuning, adaptation, or changing what it does in a way its original documentation does not cover.
- A general-purpose system pointed at a high-risk use is a different system. The single most common route, and it is usually taken by a product manager rather than by anybody in governance.
The third branch is the one to look at first, because it requires no engineering at all. A general-purpose assistant procured for internal drafting is one thing. The same assistant, configured to screen applications or triage cases, is being put to a purpose its supplier did not specify, and the obligations that attach to that purpose do not attach to the supplier who never contemplated it.
That change is typically made in a sprint. Nobody involved is thinking about value chains. The system is the same system, the contract is the same contract, and the role has moved.
Why organisations get this wrong in a consistent direction
| The assumption | What actually decides it |
|---|---|
| We did not build the model, so we are not the provider | Provider status attaches to placing a system on the market or into service under your name |
| We bought it, so the obligations are the vendor’s | The vendor’s obligations cover the system as they specified it |
| Our contract says the supplier is responsible | A contract allocates risk between the parties. It does not reassign a statutory role |
| It is only internal, so it is out of scope | Scope turns on use and effect, including on your own employees |
The third row is the one that surprises commercial teams. Indemnities are worth having and they do a real job — they decide who pays. They do not decide who a regulator writes to, and an organisation whose entire position is an indemnity has arranged its finances rather than its obligations.
The check that takes a morning
For each AI system in the inventory, three questions and a written answer.
Whose name is on it, as the user encounters it? Not who built it — who does the person interacting with it believe they are dealing with.
What have we changed? Configuration, prompts, retrieval, fine-tuning, and anything that alters behaviour beyond what the supplier documented.
What is it being used for, and did the supplier specify that use? Compare against the actual documentation, not against the sales conversation.
The last line matters more than it looks. Role is not a permanent attribute. A system that was a deployment last year becomes a provision when the product team extends it, and nothing in a normal change process asks the question. Reviewing it on a cycle, or as a gate on material change, is the only way the answer stays true.
What this does not tell you
Determining a role under the Act is a legal question about your specific facts, and this piece does not answer it for anyone. The categories are more nuanced than three branches, there are further roles in the value chain — importers, distributors, authorised representatives — and the interaction with the deferred high-risk timelines matters to what follows from the answer. That analysis belongs with your counsel.
What is not a legal question is whether anybody in your organisation has looked. The engineering record of what has been modified and what a system is used for is a factual record, it is assembled internally, and it is the input any legal analysis will require. Most organisations we see have not assembled it, which means their stated role is an assumption rather than a conclusion.
The person who should act is whoever signed the readiness assessment that opens with “we are a deployer”. Test the sentence. Three questions per system, one morning, and the answer will either confirm the assessment or find the two systems where it was never true.