Downstream Provider — EU AI Act Definition, Article 25, and the GPAI Value Chain

A downstream provider is an organisation that takes an AI system or a general-purpose AI (GPAI) model someone else built and integrates, modifies, or rebrands it into a product it places on the market under its own name. The term matters because, under Regulation (EU) 2024/1689, becoming a downstream provider can pull you out of the comparatively light deployer role and into the full provider obligation stack of Article 16 — often without you intending to take on any of it.

The short version: integrating a third-party model or system does not automatically make you a provider, but doing certain specific things to it does. This page defines the concept, sets out the Article 25 triggers that flip the role, and explains the GPAI value chain — including the information the upstream model vendor owes you under Article 53.

Where the term comes from

"Downstream provider" is the practical label for an actor in the AI value chain who sits below an original system developer or a GPAI model provider but who, by their own actions, takes on provider status. The Act defines a provider at Article 3, point 3: anyone who develops an AI system or GPAI model — or has one developed — and places it on the market or puts it into service under their own name or trademark. The Act follows the name on the box, not the origin of the model weights.

The value chain itself is addressed in Article 25 (responsibilities along the value chain) and, for the model layer, in Chapter V's information-flow duties. A downstream provider is the entity that, somewhere along that chain, crosses from using to providing.

The Article 25 triggers: when integration makes you a provider

A deployer, importer, distributor, or integrator becomes a provider — a downstream provider — of a high-risk AI system in three situations set out in Article 25(1):

1. Rebranding. You put your own name or trademark on a high-risk AI system already on the market. From that moment you are its provider.
2. Substantial modification. You make a substantial modification — defined in Article 3(23) as a change to a system's performance or intended purpose that affects its compliance with the high-risk requirements — to a system already on the market, such that it remains high-risk. You become the provider of the modified system.
3. Change of intended purpose. You modify the intended purpose of a system (including a non-high-risk one) so that it becomes high-risk. You acquire provider status for that new purpose.

The note on Article 25(1)(c) is the one integrators miss: re-purposing or substantially modifying matters even where the upstream product was perfectly compliant. The original provider's conformity assessment and CE marking cover the unmodified system for its original purpose. The moment you cross one of these lines, the original paperwork no longer covers you, and you must carry out your own conformity assessment, draw up a fresh Article 47 Declaration of Conformity, and register under Article 49.

Crossing the line also changes what the original provider owes you. Article 25(2), rewritten by the Digital Omnibus, requires the initial provider to cooperate with the new provider: hand over the technical documentation, the known limitations and failure modes, and targeted technical access so you can test the system — unless it clearly specified that its system was not to be changed into a high-risk system. Article 25(4) requires you, as provider of the high-risk system, to agree in writing with the third parties that supply AI models, tools, services or components integrated into it; the free and open-source exemption does not extend to GPAI models. Breaches of Article 25(2) and (4) now sit expressly in the €15M or 3% tier (Article 99(4)(da)).

When you become a downstream provider of a high-risk system, the Article 16 stack follows in full: a risk management system (Article 9), technical documentation (Article 11 / Annex IV), data governance (Article 10), human oversight (Article 14), accuracy and robustness (Article 15), conformity assessment (Article 43), the Declaration of Conformity (Article 47), and registration (Article 49). These apply from 2 December 2027 for stand-alone Annex III systems (and 2 August 2028 for Annex I product-embedded systems) under the Digital Omnibus — Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force since 27 July 2026. Plan against 2 December 2027.

The GPAI value chain: what flows down to you

A second, distinct sense of "downstream provider" appears in the GPAI rules. Here, you are the downstream provider who builds an AI system on top of someone else's general-purpose AI model, and the GPAI model provider sits upstream.

The duties on the model do not transfer to you. They stay with the model vendor under Article 53, which requires GPAI model providers to:

• draw up and maintain technical documentation of the model;
• provide information and documentation to downstream providers who integrate the model, so those providers understand its capabilities and limitations and can comply with their own obligations;
• put in place a policy to comply with EU copyright law; and
• publish a sufficiently detailed summary of the training data.

That second duty is the value-chain hinge: the model vendor must give you, the downstream provider, the information you need to meet your obligations for the system you build. You are entitled to it; you are not expected to reconstruct the model's internals yourself. GPAI obligations have been in force since 2 August 2025, and fines on GPAI model providers are imposed by the Commission under Article 101 (€15M or 3%), enforceable since 2 August 2026 — a separate track from the Article 99 penalties on system providers and deployers.

Worked example: Mistwald Analytics GmbH, a 35-person SaaS firm

Mistwald Analytics GmbH, based in Leipzig, ~35 employees, ~€5M turnover, licenses a third-party GPAI model and builds an HR product on top of it. Two product decisions decide its role.

Decision one: a meeting-summary feature. Mistwald uses the model to summarise internal meeting notes inside its product. This is a minimal-risk use; Mistwald is the provider of its system but the system is not high-risk, so the Article 16 stack does not bite. The model vendor still owes Mistwald the Article 53 information so Mistwald understands what it is shipping.

Decision two: an automated candidate-ranking feature. Mistwald adds a feature that scores and ranks job applicants for its employer-customers, and ships it under the Mistwald brand. Two things happen at once. The feature is high-risk under Annex III, point 4(a) (recruitment). And because Mistwald places it on the market under its own name and has built a distinct high-risk function on top of the model, Article 25 makes Mistwald a downstream provider carrying the full Article 16 stack — its own conformity assessment (Annex VI route), Annex IV documentation, an Article 47 Declaration of Conformity, and registration under Article 49, due by 2 December 2027 (the date set by the Digital Omnibus). The model vendor's GPAI duties under Article 53 do not discharge any of Mistwald's system-level obligations; they only entitle Mistwald to the information it needs. Mistwald's employer-customers are deployers under Article 26.

On exposure: failing the high-risk provider obligations sits at €15,000,000 or 3% of worldwide annual turnover under Article 99(4), and for an SME the Article 99(6) cap takes the lower of the two figures.

How Confir helps

Confir registers each AI system you build on a third-party system or GPAI model, classifies it by use under Articles 5 and 6, and derives your role — deployer (Article 26) or, where an Article 25 trigger fires, downstream provider with the Article 16 stack. The engine is deterministic and rule-based: the same intake returns the same role verdict, and the rule that fired is shown in plain English, so the line between integrating a model and becoming its system's provider is explicit rather than guessed.

Frequently Asked Questions

What is a downstream provider under the EU AI Act?

A downstream provider is an organisation that takes an AI system or GPAI model built by someone else and, by integrating, substantially modifying, or rebranding it, places a product on the market under its own name — thereby becoming a provider under Article 25. The term also describes any company that builds an AI system on top of an upstream GPAI model, to whom the model vendor owes information under Article 53.

Does integrating a third-party model make me a provider automatically?

No. Simply using or integrating a GPAI model does not, by itself, make you the provider of that model. You become a downstream provider of an AI system under Article 25 only if you place a high-risk system on the market under your own name, substantially modify one (Article 3(23)), or change a system's intended purpose so it becomes high-risk. Short of those triggers, you are typically a deployer.

What does Article 25 require of a downstream provider?

If an Article 25 trigger applies to a high-risk system, you assume the full Article 16 provider stack: risk management (Article 9), technical documentation (Article 11 / Annex IV), data governance (Article 10), human oversight (Article 14), accuracy and robustness (Article 15), a fresh conformity assessment (Article 43), a Declaration of Conformity (Article 47), and registration (Article 49). The original provider's CE marking does not cover your modified or rebranded system, but Article 25(2) obliges that provider to hand over its technical documentation, known limitations and failure modes, and targeted technical access for testing, unless it clearly specified that the system was not to be changed into a high-risk system.

What information is the upstream GPAI model provider required to give me?

Under Article 53, the GPAI model provider must supply downstream providers with information and documentation about the model — enough to understand its capabilities and limitations and to meet your own obligations — alongside technical documentation, a copyright-compliance policy, and a published training-data summary. You are entitled to this; you are not expected to reverse-engineer the model. These duties have applied since 2 August 2025.

Are the GPAI model provider's fines the same as mine?

No. Fines on GPAI model providers are imposed by the Commission under Article 101 (up to €15M or 3%). Fines on system providers and deployers — including downstream providers of AI systems — are imposed by national authorities under Article 99, with the high-risk and most other obligations in the €15M or 3% tier under Article 99(4). The two enforcement tracks are distinct, though the headline figures are similar.

When do a downstream provider's high-risk obligations apply?

For stand-alone high-risk systems under Annex III, from 2 December 2027; for high-risk AI embedded in Annex I products, from 2 August 2028. Both dates are law: the Digital Omnibus, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and has been in force since 27 July 2026, replacing the original 2 August 2026 and 2 August 2027 dates. Plan against 2 December 2027 for stand-alone Annex III and 2 August 2028 for product-embedded Annex I.

Related guides

• Provider — definition, obligations, and the Article 25 role-shift
• Deployer — definition and obligations
• Substantial modification — Article 3(23) and the provider flip
• Operator — how the EU AI Act uses the term
• Article 25 — responsibilities along the AI value chain
• Article 16 — provider obligations explained
• Article 53 — obligations for GPAI model providers
• General-purpose AI model — definition and obligations