Article 25(1) and the moment your client becomes the provider

The trap, in one sentence

A client buys a model from a vendor, fine-tunes it on its own data, points it at CV screening, and ships it under its own brand. In the client's head it is still the vendor's model. Under Article 25(1) of the EU AI Act it is the client's system, and the client is its provider.

The client is not being careless. Nothing in the buying process tells them the role can change: the invoice says software, the contract says customer, and the vendor's documentation says the vendor is the provider. The role shifts on a fact nobody in the room thinks of as legally interesting — somebody on the data team ran a fine-tune.

What the provision actually says

Article 25(1) is the hinge between the two roles the regime cares about. An organisation that substantially modifies a system, or puts an existing system to a high-risk purpose under its own name, becomes its provider — and the provider's obligations come with it.

Three details do the work in practice.

Role attaches per system, not per company. A forty-person recruitment agency can be a deployer of an off-the-shelf scheduling assistant, a provider of the scoring model it built in-house, and both at once for a vendor model it fine-tuned. One answer to "are you a provider or a deployer?" at company level is not an answer.

The high-risk purpose is what makes the change expensive. Modification on its own moves the role. Modification plus an Annex III use — recruitment and screening at point 4(a), workforce decisions and monitoring at point 4(b), education at point 3, credit scoring at point 5(b), life and health insurance pricing at point 5(c) — is what brings the full provider document set with it, under a 2 December 2027 date. The Annex I branch, an AI safety component of a regulated product under Article 6(1), carries a 2 August 2028 date.

"Under its own name" is a second, independent route. No fine-tuning is required. A client that takes a general-purpose vendor system, puts its own brand on it and offers it for a high-risk purpose has walked through the same door without touching a training script.

Three routes into it that SMEs take without noticing

Fine-tuning a vendor model on internal data. Often done by one engineer, framed internally as configuration rather than development, and recorded nowhere a consultant would find it. Ask directly or it will not surface.

Repurposing. The vendor documented an intended purpose. The client uses the system for something else. A summarisation tool pointed at applicant files, a general scoring feature pointed at promotion decisions, an assistant pointed at creditworthiness. The intended purpose has changed from what the vendor documented, and that change is the client's, not the vendor's.

White-labelling. The client resells or embeds someone else's system with its own name or trademark on it. This one shows up in software businesses that would describe themselves as integrators and would never claim to build models.

None of the three feels like becoming a manufacturer. All three can end there.

The questions that surface it

These belong in the interview per system, not once per client, and the answers belong in the register next to the system they describe.

• Did you build this system, buy it, or buy it and change it?
• Did you fine-tune, retrain or otherwise adapt a vendor model on your own data?
• Has the intended purpose changed from what the vendor documented?
• Do you put your own name or trademark on it when you offer it to others?
• What exactly was changed, by whom, and when?
• What does the system decide or influence, and about whom?
• Does the system reach users, or produce output used, in the EEA?

The last one is easy to skip and expensive to skip. The regime reaches systems whose output is used in the Union, so a UK or US client serving EEA users is in scope for the same conversation.

Note the shape of the sixth question. Role and category are settled by what the system decides, not by what model sits underneath it, and a client who answers "we use a large language model" has told you nothing that bears on either.

What changes in the file when the answer is yes

Quite a lot, and it is worth being able to show the client the delta rather than describing it.

The document set expands. Every client that uses AI at all gets the system register, the literacy policy and the supply-chain contract clauses. A high-risk system in the file, provider or deployer, adds the Article 14 human oversight procedure and the logging policy — six months is the retention floor to plan around for deployers. What is specific to the provider is the Annex IV technical documentation and the Article 9 risk assessment. Those two appear precisely when your client is the provider, including where it became one under Article 25(1).

The fundamental rights assessment follows a different rule. Article 27 lands on deployers, not providers, and in the SME book specifically on deployers of Annex III credit scoring and of life and health insurance pricing. Deployers providing public services are also caught, and whether your client is one is a call you make rather than one a questionnaire makes for you. A client that is both provider and deployer of the same system can be inside both sets at once.

Work outside the paperwork appears. Conformity assessment, registration and CE marking are the provider's, and they are not documentation exercises. This is the point at which the engagement stops being a drafting job, and the point where the client needs to understand what has landed on them.

The Article 6(3) off-ramp becomes worth checking properly. A system inside an Annex III area is not high risk if it performs a narrow procedural task or does not materially influence the outcome of decision-making — unless it profiles natural persons, which removes the exemption. A CV parser that only extracts fields into a form may genuinely sit there. This is also the provision clients lean on wishfully. If you rely on it, write the reasoning down and date it before the system is placed on the market, and name the human decision the system does not materially influence.

Incident handling gets a clock. Fifteen days to the market surveillance authority of the Member State where the incident occurred for a serious incident involving a high-risk system, two days for a widespread infringement or a serious and irreversible disruption of critical infrastructure, ten days where a person has died. For a client also in scope for GDPR and NIS2, those sit alongside a 72-hour and a 24-hour duty to different authorities, and what is said on the first day is available to all three investigations.

The confirmation goes stale when the facts move. If the use cases, the role or the modification flag change, the category confirmed against the old facts is no longer confirmed, and the documents built on it are out of date. Build that into how you keep the register, or it will be true without anybody noticing.

Who makes the call

Article 25(1) is a judgement, not a lookup. Whether a change amounts to substantial modification, whether a purpose has really shifted, whether Article 6(3) applies — those turn on facts a tool cannot see and on a reading that someone has to stand behind.

So the product rule is the same as the professional one. A tool suggests the role and the risk category, shows the trigger it matched and the article behind it, and stops there. The category is stored only once a person has confirmed it, in their own name, and a category different from the suggested one is recorded with a written reason. Until then the register carries a visible gap — "risk category of the AI system, confirmed by the consultant" — rather than a guess dressed up as a finding. That is how clausebench is built, and it is built that way because the alternative transfers a professional risk onto the person who signs the file.

A tool that appears to have decided the qualification for you is not a convenience. It is a liability with a nice interface.