Module 5 — The Article 25 Trap: When a Deployer Becomes a Provider

Module 5 of the AI Act Deployer certification: the three Art. 25 triggers that reclassify a deployer as a provider, what lands on you when one fires, and how to catch them at procurement instead of at audit.

This is the module that changes procurement behaviour, because the consequence is disproportionate to the act that triggers it. Adding your logo to a screen is a marketing decision made in an afternoon. If the system behind that screen is high-risk, it can move the entire Chapter III obligation set onto your balance sheet.

The three triggers

Art. 25(1) provides that a distributor, importer, deployer or other third party shall be considered a provider of a high-risk AI system, and shall be subject to the provider's obligations under Art. 16, in any of these circumstances:

(a) You put your name or trademark on it. The system has already been placed on the market or put into service, and you affix your own name or trademark to it. There is a carve-out for contractual arrangements allocating obligations otherwise, but do not build a programme on it: the allocation has to be real, agreed, and it does not bind a supervisory authority's view of who is presenting the product to the market.

(b) You make a substantial modification to it. The system remains high-risk after the change. "Substantial modification" is defined in Art. 3 — a change not foreseen or planned in the provider's initial conformity assessment which affects compliance with the Chapter III requirements, or which results in a modification to the intended purpose.

(c) You change the intended purpose so that it becomes high-risk. This one explicitly includes taking a general-purpose AI system that the provider did not classify as high-risk and putting it to a high-risk use.

Why (c) is the one that catches people now

Triggers (a) and (b) are legible: someone decides to rebrand, someone decides to retrain. Trigger (c) fires through ordinary product evolution, usually without a decision that anybody would have escalated.

The pattern is always the same. An organisation licenses a general-purpose assistant for drafting and summarisation — plainly not high-risk. A team then points it at CV screening, or at drafting adverse decision letters for benefit claims, or at ranking employees for redundancy selection. Nobody rebranded anything and nobody retrained anything. But the intended purpose, as you now intend it, is an Annex III point 4 use, and under Art. 25(1)(c) you are the provider of a high-risk AI system.

The vendor's terms of service almost certainly say the product is not for such uses. That protects the vendor. It does not protect you — if anything it strengthens the case that the purpose change was yours.

What actually lands on you

Becoming the provider is not an administrative reclassification. Art. 16 brings the whole of Chapter III:

Consider what Art. 10 alone means for an organisation that did not train the model: you owe data governance for training data you have never seen and cannot obtain. That is why the cooperation duty matters.

The cooperation duty, and how to make it usable

Art. 25(2) requires the original provider, once someone else has become the provider, to cooperate closely and make available the information and technical access reasonably needed to fulfil the obligations — unless it has clearly specified that its system is not to be changed into a high-risk one.

Two practical readings.

First: that final clause is why vendor terms increasingly contain an explicit statement that the product must not be put to high-risk use. It is not boilerplate; it is the vendor discharging its cooperation duty in advance.

Second: relying on a statutory cooperation duty to obtain training data documentation from a supplier who does not want to give it to you is not a plan. Put it in the contract, with a definition of the deliverables and a remedy.

Catching it before it fires

The controls are procurement controls, not compliance controls, and they cost almost nothing if they exist before the contract.

Record the declared intended purpose at onboarding, quoted from the instructions for use, in the inventory field Module 1 asked you to create. Every later question about Art. 25(c) is answered by comparing current use against that quotation.

Gate purpose changes. Any new use case for an existing system goes through the same classification step as a new system. This is one form and five minutes; without it, purpose creep is invisible by construction.

Gate branding. A rule that the vendor's identity remains visible on any AI-driven output, unless legal has cleared removal, prevents trigger (a) at zero cost.

Gate modification. Fine-tuning, retraining on your data, and changes to decision thresholds all need a check against the definition of substantial modification. Note that the general-purpose model track has its own version of this question — fine-tuning can make you a provider of a model under Chapter V, which is a different regime from being the provider of a system.

Write the cooperation clause. Access to Annex IV documentation, training data descriptions, evaluation results, and log exports, with a service level. The moment to obtain this is before signature.

A worked example

A regional insurer licenses a document-understanding platform. Not high-risk: it reads PDFs and extracts fields.

A claims team configures it to score claims for likely fraud. Fraud detection is expressly carved out of Annex III point 5(b), so this remains outside high-risk. Good.

Eighteen months later, a pricing team reuses the same configured pipeline to inform risk assessment and pricing for health insurance policies. That is Annex III point 5(c). The intended purpose has changed and the system is now high-risk. Under Art. 25(1)(c) the insurer is its provider — and, being an insurer deploying a 5(c) system, is also one of the narrow set of deployers that owes a fundamental rights impact assessment under Art. 27.

No one rebranded anything. No one retrained anything. Two teams reused a pipeline, which is exactly what good engineering practice encourages.

Check yourself

1. We put our brand on a licensed high-risk system, but our contract says the vendor stays the provider. — Art. 25(1)(a) has a carve-out for contractual arrangements, but treat it as fragile. The allocation must be real, and it does not change who the market sees presenting the product.
2. We fine-tuned a vendor's high-risk system on our own data. — Check the definition of substantial modification. If the change was not foreseen in the provider's conformity assessment and affects Chapter III compliance, Art. 25(1)(b) fires.
3. We pointed a general-purpose assistant at CV screening. — Art. 25(1)(c). You have changed the intended purpose into an Annex III point 4 use; you are the provider.
4. If Art. 25 fires, is the original provider off the hook entirely? — It stops being the provider of that system, but owes a cooperation duty — unless it clearly specified the system was not to be changed into a high-risk one.

Previous: Module 4 — Logs, monitoring, suspension, incidents Next: Module 6 — Transparency you owe directly →