Module 3 — Obligations by Role: Provider, Deployer, and the Art. 25 Trap

Module 3 of the free EU AI Act Fundamentals course: what providers owe under Art. 8-17, what deployers owe under Art. 26, and the three ways a deployer silently becomes a provider.

The Act does not ask what industry you are in. It asks what you do with a system, and it hands you an obligation set accordingly. Getting your role wrong is the most expensive error available, because the two main roles differ by roughly an order of magnitude in work.

Provider obligations (high-risk)

A provider develops a high-risk system — or has one developed — and places it on the market under its own name or trademark. Articles 8 to 17 then apply in full:

That is a programme, not a checklist. It is why the provider/deployer determination is the first thing to settle and the last thing to guess at.

Deployer obligations (high-risk)

A deployer uses the system under its own authority in a professional capacity. Art. 26 is materially lighter but not trivial:

• Use it as instructed. Deviating from the instructions for use is where deployer liability starts — and can amount to a change of intended purpose.
• Assign human oversight to people who are competent, adequately trained, and — the part usually missing — have the authority to intervene. An overseer who cannot overrule the model is decoration.
• Ensure input data is relevant and sufficiently representative for the intended purpose, to the extent you control the input.
• Monitor operation, and suspend use and inform the provider if you identify a risk.
• Keep the automatically generated logs for at least six months.
• Inform workers' representatives before putting a high-risk system into service in the workplace — before, not after.
• Inform affected persons that they are subject to a high-risk system where it makes decisions about them.
• Report serious incidents to the provider and, where applicable, the authority.

Deployers that are public bodies, or private entities providing public services, additionally owe a fundamental rights impact assessment under Art. 27.

The Art. 25 trap

This is the article that reclassifies you without a meeting. A deployer becomes a provider — with the entire Art. 8–17 set — in three cases:

1. Your name on it. You put your own name or trademark on a high-risk system already on the market. White-labelling a vendor model into your own app is enough.

2. Substantial modification. You modify a high-risk system already on the market in a way that affects its compliance or changes its intended purpose. Retraining on your own data, changing the decision threshold in a way that alters the risk profile, or bolting on a new decision layer are all candidates.

3. Change of intended purpose. You use a system for something the provider did not describe — including taking a non-high-risk system and pointing it at a high-risk use. Buying a general text classifier and using it to screen CVs converts you into the provider of a high-risk system.

There is one lifeline: Art. 25(4) obliges the original provider to cooperate and supply the information and technical access you reasonably need. Put that in the contract before you need it, because a provider that has already been paid has little incentive to help you assume its obligations.

GPAI in the chain

If you build on a general-purpose AI model, the model provider carries its own Art. 53–55 duties. Those stay theirs. You do not inherit them by calling an API.

You only become the provider of a modified model when the compute used for your modification exceeds roughly one third of the original's — the indicative criterion in the Commission guidelines of 18 July 2025. A bank's LoRA fine-tune is nowhere near that line. This is covered properly in Module 4.

Getting the determination on paper

Whatever you conclude, write it down. Three questions, per system, dated and signed:

1. What is the intended purpose, in the provider's words? If you cannot quote it, you do not know whether you have changed it.
2. Have we rebranded, modified, or repurposed it? If yes to any, you are the provider.
3. Who owns this system? A named person, not a team.

That record is the first thing an authority asks for, and the cheapest artefact in the entire regime to produce.

Check yourself

1. You deploy a vendor CV-screening tool unchanged, under the vendor's brand. Your role? — Deployer. Art. 26 applies: oversight, input data, logs, worker information. The vendor remains the provider.
2. Same tool, retrained on five years of your own hiring decisions. Your role? — Almost certainly provider under Art. 25(1)(b): retraining on your own data is a substantial modification, and it changes the risk profile.
3. Your overseer reviews every rejection but has never overturned one and cannot. — Art. 26(2) is not met. Oversight requires competence, training and authority to intervene.
4. How long must a deployer keep the logs? — At least six months, unless other EU or national law says longer.

Previous: Module 2 — Risk classification · Next: Module 4 — GPAI models →