EU AI Act Article 25: Responsibilities Along the AI Value Chain

A systems integrator buys a compliant high-risk CV-screening engine, wraps it in its own brand, and resells it. It is now the legal provider of that system and owes the entire Article 16 stack it never budgeted for. That is Article 25 of Regulation (EU) 2024/1689 at work: it reallocates the heavy provider obligations when a downstream actor changes a high-risk system enough to be treated as its provider. This guide covers when that flip happens, what you inherit, and what the original provider still owes you — and it applies only to high-risk systems, not to general business AI.

Article 25 governs responsibilities along the AI value chain. Under Article 25(1), a distributor, importer, deployer or other third party is considered to be a provider of a high-risk AI system for the purposes of the Regulation, and assumes the Article 16 provider obligations, the moment any one of three triggers is met. When that happens, the original provider stops being considered the provider of that specific system (Article 25(1), final subparagraph) but must still cooperate under Article 25(2).

Get the role wrong and the wrong party files technical documentation under Article 11 and Annex IV, runs conformity assessment under Article 43, and registers the system in the EU database under Article 49. Read this alongside provider vs deployer roles and obligations and the Article 16 provider obligations for the full role map.

---

Scope first: Article 25 only bites for high-risk systems

Before anything else, confirm the system is high-risk. Article 25 only reallocates provider obligations, and provider obligations only exist for high-risk systems under Article 6 with Annex III (for example point 4(a), recruitment) or Annex I (the product route).

Most general business AI is not high-risk. Productivity assistants, coding tools, search and retrieval, marketing copy generators and ticket routing sit outside the high-risk list. For those systems no Article 25 flip is possible, and the realistic duties collapse to Article 4 AI literacy and, where AI output reaches third parties, Article 50 transparency. The flip only matters once a system is genuinely high-risk. If you are unsure, classify first — the rest of this article assumes you have established that.

---

The three triggers that flip a downstream actor into a provider

Article 25(1) sets out three independent triggers. Meeting any one is sufficient. The flip is automatic, by operation of law — a contract can allocate who does the practical work, but it cannot waive the legal status the Regulation assigns.

Trigger 1 — putting your name or trademark on it (Article 25(1)(a))

If you put your own name or trademark on a high-risk AI system that has already been placed on the market or put into service, you become its provider — subject to any contractual arrangement otherwise. This is the white-label and OEM resale trap. The underlying engine can be flawless and fully assessed by someone else; the act of branding it as yours moves provider status to you.

Trigger 2 — making a substantial modification (Article 25(1)(b))

Making a substantial modification to a high-risk AI system already on the market makes the modifier the provider. The defined term sits in Article 3(23): a change not foreseen in the system's initial conformity assessment that affects its compliance or alters its intended purpose. That threshold matters. Routine configuration, or fine-tuning within the documented intended purpose, does not by itself trip the trigger. A change outside what the original conformity assessment foresaw does. See what counts as a substantial modification for the change-after-placement test in detail.

Trigger 3 — modifying the intended purpose (Article 25(1)(c))

Changing the intended purpose of an AI system — including a non-high-risk or general-purpose system — so that it becomes high-risk under Article 6 makes you the provider of that newly high-risk system. This is the route by which a tool that was never high-risk becomes one: a general scoring engine repurposed for recruitment shortlisting lands in Annex III point 4(a), and the party that repurposed it owns the consequences.

The honest boundary across all three: normal use, documented configuration, and in-scope fine-tuning do not flip you. Only branding, out-of-scope modification, or a purpose change toward a high-risk use does.

---

Once you flip: which obligations you inherit

When you become the provider, you take on the full Article 16 obligation set. There is no partial version. That means the substantive high-risk requirements of Articles 9 to 15:

• risk management system (Article 9)
• data and data governance (Article 10)
• technical documentation (Article 11, Annex IV)
• record-keeping and logging (Article 12)
• transparency and instructions for use (Article 13)
• human oversight (Article 14)
• accuracy, robustness and cybersecurity (Article 15)

On top sits the procedural stack: a quality management system (Article 17), conformity assessment (Article 43), the EU declaration of conformity (Article 47), CE marking (Article 48) and registration in the EU database (Article 49). A non-EU actor that becomes a provider this way must also appoint an EU authorised representative under Article 22.

One carve-out matters. For Annex I product-route systems the flip interacts with Article 6(1), and you do not apply the stand-alone stack directly. Under Article 2(2), Annex I Section B products — motor vehicles under Regulation (EU) 2018/858, plus aviation, rail and marine equipment — reach the substantive requirements through their AI-Act-amended sectoral frameworks, not through direct application of Articles 8 to 15. For Annex I Section A products such as machinery and medical devices, Article 43(3) routes the conformity assessment through the relevant sectoral acts. Do not bolt the full stand-alone provider stack onto product-embedded AI.

Most organisations that flip were never resourced as providers. That gap is the central risk Article 25 creates for integrators and resellers.

---

The duty that survives the flip: the original provider must cooperate

The flip moves provider status downstream, but it does not erase the upstream party's information obligations. Article 25(2) to (4) keeps the original provider and any model supplier in the picture.

Article 25(2). When the flip occurs, the original provider must cooperate closely with the new provider, make available the necessary information, and provide the reasonably expected technical access and other assistance the new provider needs to comply — unless the original provider has clearly specified that its system is not to be changed. That clause is why supplier contracts matter: the original provider is not silent simply because someone downstream became the legal provider.

Article 25(3). Where a high-risk system is built on or integrates a general-purpose AI model, the GPAI model provider must support compliance by supplying the necessary information and documentation. The GPAI obligation set in Articles 51 to 55 is partial and on the roadmap, not complete, but the support duty in Article 25(3) is the bridge between the model layer and the high-risk system layer.

Article 25(4). For high-risk AI systems that are safety components of products under Article 6(1), the product manufacturer is considered the provider and bears the corresponding obligations.

Where this bites on penalties: supplying incorrect, incomplete or misleading information to authorities sits in the lowest tier — up to €7.5 million or 1% of total worldwide annual turnover, whichever is higher (Article 99(5)). Most-obligation breaches by a provider sit a tier up at €15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). For SMEs and start-ups, Article 99(6) caps the fine at the lower of the percentage or the fixed amount.

---

The Article 25 trap for integrators, resellers and white-label vendors

Here is the trap stated plainly. A systems integrator or value-added reseller buys a compliant high-risk system, rebrands it (Trigger 1) or wires in custom logic that changes its behaviour beyond the original conformity scope (Trigger 2), and silently becomes the legal provider — inheriting the entire Article 16 stack it never planned for.

A second trap catches deployers. A team takes a non-high-risk tool and tunes it into a high-risk use (Trigger 3) — for instance, repurposing a general scoring tool for recruitment shortlisting, which falls under Annex III point 4(a). The tool was harmless on Monday and a high-risk system under your providership by Friday.

Contracts allocate work, not legal status. A clause reading "the vendor remains the provider" does not survive once you put your trademark on the system or substantially modify it. What contracts should do is lock down the Article 25(2) cooperation and information-access commitments you will need.

Mitigation is concrete:

• Keep changes inside the system's documented intended purpose.
• Pass through the original branding where you can, rather than rebadging.
• Secure written Article 25(2) cooperation and information-access commitments from upstream before launch.
• Re-run your role classification on every material change, not once at signing.

Watch the calendar, too. Stand-alone Annex III high-risk obligations originally read 2 August 2026 in the statute. The Digital Omnibus — adopted by the European Parliament on 16 June 2026 and by the Council on 29 June 2026 — defers the stand-alone high-risk date to 2 December 2027, pending Official Journal publication as a formality. Plan against 2 December 2027 for stand-alone high-risk Annex III. The deferral is a fixed-date change; the "stop the clock" variant was rejected, so not everything is delayed.

---

Article 25 triggers and consequences at a glance

The three triggers and what each one drags onto you:

---

Worked example: an integrator re-brands and re-purposes a screening tool

Consider TalentBridge, a 120-person EU HR-technology integrator. It licenses a compliant high-risk CV-screening engine from an upstream provider and resells it to corporate clients under its own brand.

The moment TalentBridge ships the engine under its own name, Trigger 1 fires (Article 25(1)(a)) — it is now the provider of the branded system. TalentBridge then adds a custom "culture-fit" ranking layer that the original conformity assessment never foresaw. That is a substantial modification under Article 25(1)(b) and Article 3(23), and it independently confirms the flip. Either trigger alone would have been enough; TalentBridge tripped two.

The consequence is the full stand-alone provider stack. TalentBridge must own the Annex IV technical documentation (Article 11), run conformity assessment (Article 43), issue the EU declaration of conformity (Article 47), CE-mark the system (Article 48) and register it in the EU database (Article 49). Because recruitment sits in Annex III point 4(a), the corporate clients deploying the tool downstream still carry their own deployer duties under Articles 26 and 27 — the flip does not relieve them. (See the Article 26 deployer obligations for that downstream side.)

The resolution TalentBridge should reach: negotiate Article 25(2) cooperation and documentation access from the upstream provider in writing, stop short of rebranding where the commercial case allows, and re-run its role classification before launch rather than after an enforcement query lands.

---

A practical role-reassessment workflow

Five steps, in order, every time the system or your role changes:

1. Confirm high-risk status. Test the system against Article 6 with Annex III or Annex I. If it is not high-risk, Article 25 does not apply and your duties collapse to Article 4 literacy and Article 50 transparency.
2. Test each Article 25(1) trigger against your actual actions: branding, modification scope versus the Article 3(23) threshold, and intended-purpose drift toward an Annex III use.
3. Scope the inherited stack. If any trigger fires, map the full Article 16 obligations and check whether you need an Article 22 authorised representative.
4. Secure upstream duties in writing. Pin down the Article 25(2) cooperation and the Article 25(3) GPAI support you are owed.
5. Re-test on every material change. The flip is event-driven, so re-evaluate role status whenever branding, function or purpose changes — not once at procurement.

---

How Confir helps

Confir maps each system in your inventory against the Article 25 triggers and assembles the resulting documentation set. The synthesis engine is deterministic and rule-based — no model inference, no hallucination. It applies the trigger logic to how you have actually configured, branded and modified each system, flags where a flip has occurred, and scopes the Article 16 obligations that follow. Where the original provider owes you Article 25(2) cooperation, Confir tracks the information-access commitments alongside the system record, so a role change never quietly leaves you holding an unbudgeted provider stack.

---

Frequently asked questions

What does Article 25 of the EU AI Act actually do?

Article 25 governs responsibilities along the AI value chain. Its core rule is the provider flip: under Article 25(1), a distributor, importer, deployer or other third party is treated as the provider of a high-risk AI system — and inherits the Article 16 obligations — if it puts its name or trademark on the system, makes a substantial modification, or changes the intended purpose so the system becomes high-risk. It also imposes cooperation and information duties on the original provider under Article 25(2) to (4).

When does a deployer or reseller become a provider under Article 25?

Whenever any one of three triggers in Article 25(1) is met: branding the system under your own name or trademark (Article 25(1)(a)); making a substantial modification as defined in Article 3(23) (Article 25(1)(b)); or modifying the intended purpose so a system becomes high-risk under Article 6 (Article 25(1)(c)). Meeting a single trigger is enough — the flip happens automatically by law, not by choice, though contracts can allocate the practical work.

Can a contract stop the Article 25 provider flip from happening?

No, not fully. Article 25(1) operates by law: if you put your trademark on a high-risk system or substantially modify it, you become its provider regardless of contract wording. Article 25(1)(a) references contractual arrangements for the branding case, but contracts mainly allocate who does the work, not who holds legal status. What contracts should secure is the original provider's Article 25(2) duty to cooperate and share the information and technical access you need to comply.

What obligations do I inherit if I become a provider under Article 25?

The full Article 16 set: risk management, data governance, technical documentation (Article 11, Annex IV), record-keeping, transparency, human oversight, and accuracy, robustness and cybersecurity (Articles 9 to 15). Plus a quality management system (Article 17), conformity assessment (Article 43), the EU declaration of conformity (Article 47), CE marking (Article 48) and EU database registration (Article 49). A non-EU actor must also appoint an authorised representative under Article 22.

Does the original provider have any duties after the flip?

Yes. Under Article 25(2), the original provider must cooperate closely with the new provider, make necessary information available, and provide reasonably expected technical access and assistance — unless it clearly specified its system is not to be changed. Where a general-purpose AI model is integrated, Article 25(3) obliges the GPAI model provider to supply supporting information and documentation. The flip moves provider status downstream but does not erase the upstream party's information obligations.

Does Article 25 apply to AI that is not high-risk?

No. The whole mechanism is keyed to high-risk systems under Article 6 with Annex III or Annex I. Most general business AI — productivity assistants, coding tools, search and retrieval, marketing tools — is not high-risk, so no Article 25 flip is possible. For those systems the realistic duties are Article 4 AI literacy and, where AI output reaches third parties, Article 50 transparency. The flip only matters once a system is genuinely high-risk.

How do product-embedded AI systems interact with Article 25?

Differently from stand-alone systems. For Annex I product-route AI, Article 25(4) treats the product manufacturer as the provider. Under Article 2(2), Section B products such as motor vehicles, aviation and rail reach requirements through their amended sectoral frameworks rather than direct application of Articles 8 to 16, and Section A products route conformity assessment through sectoral acts under Article 43(3). You should not apply the full stand-alone high-risk stack directly to product-embedded AI.

---

Related guides

• provider vs deployer roles and obligations
• Article 16 provider obligations
• Article 26 deployer obligations
• what counts as a substantial modification
• Article 23 importer obligations