What are the obligations of downstream providers under the EU AI Act?

Downstream providers — those who provide AI systems integrating a GPAI model — carry the ordinary AI system obligations: high-risk provider duties under Chapter III where the system falls in Annex III or Annex I, transparency duties under Article 50 for chatbots and synthetic content, and AI literacy duties under Article 4. The model provider's Chapter V compliance does not substitute for any of this.

What information must a GPAI model provider give downstream providers?

Under Article 53(1)(b) and Annex XII, the model provider must make available documentation describing the model — tasks, modalities, licence, acceptable use policies — and its technical integration requirements, sufficient for downstream providers to understand capabilities and limitations and to meet their own obligations. Qualifying open-source models without systemic risk are exempt from this structured duty.

Can a downstream provider become a provider of the GPAI model itself?

Yes, by modifying the model significantly. Commission guidance from July 2025 treats a downstream modifier as a new model provider when the compute used for the modification exceeds roughly one third of the original model's training compute, with obligations scoped to the modification performed.

When does rebranding an AI system make you the provider?

Under Article 25, putting your name or trademark on a high-risk AI system already on the market, substantially modifying it, or changing its intended purpose so it becomes high-risk makes you the provider, with full Chapter III obligations transferring to you.

Do downstream providers need contracts beyond the statutory information right?

In practice yes. The statute sets minimum information duties, but downstream providers should contract for version-change notice, compliance assistance for high-risk documentation, continuity of output-marking interfaces, incident cooperation and risk allocation for model outputs.

Quick answer

A downstream provider under the EU AI Act is anyone who provides an AI system that integrates a general-purpose AI model. They are entitled to documentation from the model provider under Article 53(1)(b) and Annex XII, and they carry their own obligations as AI system providers — including high-risk duties and Article 50 transparency where applicable.

Updated June 2026 · MmowW AI Compliance

EU AI Act Downstream Providers: Obligations When You Build on a GPAI Model

Who Is a Downstream Provider

Article 3(68) of Regulation (EU) 2024/1689 defines a downstream provider as a provider of an AI system, including a general-purpose AI system, which integrates an AI model, regardless of whether the model is provided by themselves and vertically integrated or provided by another entity based on contractual relations. In plain terms: if you build and offer a product whose intelligence comes from a GPAI model — your own or someone else's — you are a downstream provider for that system.

The category matters because the AI Act regulates two layers separately. Chapter V regulates the model and binds the model provider. The rest of the regulation regulates AI systems and binds whoever provides or deploys those systems. A company that wraps a third-party language model into a customer-service product is not a GPAI model provider — but it is the provider of an AI system, with everything that entails.

What You Are Entitled to Receive

Article 53(1)(b) obliges GPAI model providers to draw up, keep up to date and make available information and documentation to providers of AI systems who intend to integrate the model. The minimum content is listed in Annex XII and is designed to do two things: enable downstream providers to have a good understanding of the capabilities and limitations of the model, and enable them to comply with their own obligations under the regulation.

Annex XII covers a general description of the model — tasks, acceptable use policies, release date, distribution methods, modalities, licence — and a description of its technical integration elements: the technical means required for integration, instructions for use, infrastructure requirements, and relevant information on training where needed for downstream compliance. If your model supplier cannot or will not give you this package, that is a regulatory red flag as well as a commercial one; the only carve-out is for qualifying free and open-source models without systemic risk, where the open publication of weights, architecture and usage information substitutes for the structured package.

Your Own Obligations as a System Provider

Integrating a GPAI model does not import the model provider's compliance; it starts your own. Depending on what your system does, the relevant duties include:

High-risk obligations. If your system falls within Annex III use cases — employment screening, credit scoring, education assessment, essential services and others — or is a regulated product component under Annex I, you carry the full provider obligations of Chapter III from August 2, 2026: risk management, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy and robustness, conformity assessment and CE marking.
Article 50 transparency. If your system interacts directly with people, you must design it so they know they are dealing with AI. If it generates synthetic audio, image, video or text, outputs must be marked in machine-readable format as artificially generated. These duties apply from August 2, 2026.
AI literacy. Article 4 has required appropriate AI literacy measures for staff dealing with AI since February 2, 2025.

When a Downstream Provider Becomes Something More

Two escalation paths deserve attention. First, under Article 25, a distributor, importer, deployer or other third party is considered a provider of a high-risk AI system if it puts its name or trademark on a high-risk system already on the market, substantially modifies one, or changes the intended purpose of a system in a way that makes it high-risk. Second, an entity that modifies the GPAI model itself — for example through significant fine-tuning — can become a GPAI model provider in its own right, with Article 53 duties scoped to the modification. Commission guidance from July 2025 uses the share of original training compute as the practical yardstick for when a modification creates a new model provider.

Contractual Reality: What to Negotiate

The regulation gives downstream providers a statutory information entitlement, but contracts decide how usable it is. Negotiation points that matter in practice:

Delivery and updates of the Annex XII package, including notice when the model version you depend on changes behaviour or is deprecated.
Assistance commitments for your high-risk compliance — evaluation data, robustness evidence, documentation extracts you can reference in your own technical documentation.
Output-marking interfaces: if the model provider's marking technology underpins your Article 50 compliance, you need specification and continuity commitments.
Incident cooperation: timelines and channels for security and safety information flowing both ways.
Allocation of copyright and data-protection risk for model outputs, including indemnities calibrated to your use case.

Key Dates for Downstream Providers

The timeline matters because the two regulatory layers switched on at different times. Model-level obligations under Chapter V have applied to GPAI providers since August 2, 2025, which is why Annex XII packages should already be available from your suppliers — and why their absence is worth escalating. System-level obligations follow the general schedule: the prohibitions of Article 5 have applied since February 2, 2025, AI literacy under Article 4 likewise, while the high-risk regime of Chapter III and the transparency duties of Article 50 apply from August 2, 2026. High-risk systems that are components of regulated products under Annex I have until August 2, 2027. A downstream provider planning a product launch in 2026 should therefore treat August 2, 2026 as the date its own heaviest obligations bite, regardless of how long the underlying model has been compliant.

It is also worth knowing where supervision sits. The AI Office oversees GPAI model providers centrally, while national market surveillance authorities supervise AI systems. A complaint about your product lands with a national authority; a deficiency in your supplier's model documentation is a matter for the AI Office — and your contract should oblige the supplier to cooperate when the two intersect.

A Concrete Example

A HR-technology firm builds a candidate-screening assistant on a commercial GPAI model accessed by API. The system is high-risk under Annex III. The firm requests the supplier's Annex XII package and uses it to complete its own technical documentation, noting the model's stated limitations on multilingual fairness. It implements human oversight so recruiters review every recommendation, logs system activity, runs bias testing on its candidate data, and completes conformity assessment before the August 2026 deadline. In parallel it adds the chatbot disclosure required by Article 50 to its candidate-facing interface. The model provider remains responsible for Chapter V compliance of the model; the HR firm is responsible for everything the system does in the hiring context.

Common Pitfalls

The most frequent mistake is assuming the model vendor's compliance covers the product. It does not: model-level duties and system-level duties are parallel tracks, and supervisory authorities will look to the system provider for system-level failures. The second mistake is integration without documentation — building on a model whose Annex XII package was never obtained, leaving gaps in the downstream technical file that surface during conformity assessment. The third is silent model swapping: replacing the underlying model or upgrading versions without re-running the testing that supported the original compliance claims. The fourth is ignoring the escalation rules — white-labelling a high-risk system or repurposing a general tool into an Annex III use case quietly converts you into the provider of record under Article 25.

Action Plan

Map every product to its underlying models and classify each system against Annex III and Article 50. Collect Annex XII packages from every model supplier and build contractual update obligations around them. Where your systems are high-risk, start the Chapter III workstream now — the obligations have applied since August 2, 2026 deadlines were set, and conformity assessment is the long pole. And whenever you rebrand, modify or repurpose someone else's system, run the Article 25 analysis before launch, not after.

Treat the downstream role as a position of leverage as well as obligation. Model providers compete for serious enterprise integrators, and the information rights the regulation grants you are a baseline that good suppliers will exceed. Downstream providers who ask precise, Annex-XII-shaped questions during procurement consistently get better documentation, better assistance commitments and better pricing on compliance support than those who discover the requirements after the contract is signed.

And keep a model registry. A simple internal table — product, underlying model and version, Annex XII package on file, system classification, last compliance review date — is the single most useful artefact a downstream provider can maintain, because every obligation discussed above attaches to a specific model-system pair at a specific time. Review the registry quarterly, and let it drive the contract renewals: the suppliers worth keeping are the ones whose documentation arrives before you chase it.

Check your AI compliance readiness — free.

Take the Readiness Check 3 minutes · 10 questions · no signup required

This article is for informational purposes only and does not constitute legal advice. Regulatory requirements change frequently — verify current rules with official sources. Built by Sawai Gyoseishoshi Office, Hiroshima, Japan.