Skip to main content
Bureau of AI
Category: Third-Party & Supply Chain

Downstream Provider Obligations

Also known as: Downstream Provider Compliance Obligations, Obligations of Downstream Providers
Simply put

Downstream provider obligations are the compliance duties that fall on organizations or people who build on, integrate, or adapt a general-purpose AI model supplied by another party (the upstream provider) under the EU AI Act. To meet these duties, downstream providers often need specific information and documentation from the upstream model provider. This reflects a shared-responsibility structure in which the upstream provider supplies documentation and the downstream provider carries its own separate compliance responsibilities.

Formal definition

In the context of the EU AI Act, 'downstream provider obligations' refers to the compliance responsibilities borne by an entity that integrates, fine-tunes, or otherwise relies on a general-purpose AI (GPAI) model supplied by an upstream provider. According to the European Commission's materials, providers of GPAI models are required to draw up and maintain technical documentation and to provide documentation to the AI Office, national competent authorities, and downstream providers (referenced in connection with Article 53). Downstream providers hold distinct compliance obligations of their own but may depend on certain information from the upstream provider to satisfy those obligations. The evidence describes an information-flow and role-allocation mechanism between upstream and downstream parties rather than a fully enumerated list of every downstream duty; the specific scope of downstream obligations depends on the role a downstream entity takes on (for example, as a provider or deployer of an AI system) and is not exhaustively defined in the evidence provided here. As of the dates in the cited sources, some of the underlying guidelines are preliminary or evolving, so precise obligation details should be confirmed against the current text of the AI Act and Commission guidance.

Why it matters

Downstream provider obligations matter because the EU AI Act allocates compliance responsibilities across a supply chain rather than concentrating them in a single actor. An organization that integrates, fine-tunes, or otherwise builds on a general-purpose AI (GPAI) model supplied by another party does not inherit the upstream provider's duties wholesale, nor is it relieved of responsibility simply because it did not train the underlying model. Instead, the downstream provider carries its own distinct set of obligations, which typically depend on the role it takes on—for example, as a provider of a downstream AI system or as a deployer. Misunderstanding this allocation can leave a downstream organization exposed to compliance gaps it assumed the upstream provider had covered.

The structure also creates a practical dependency: according to the European Commission's materials, providers of GPAI models are required to draw up and maintain technical documentation and to make documentation available to the AI Office, national competent authorities, and downstream providers (referenced in connection with Article 53). Downstream providers often cannot satisfy their own obligations without receiving this information. As a result, the effectiveness of downstream compliance depends in part on information flow from upstream, making documentation exchange and role clarity operational necessities rather than optional courtesies.

Professionals should treat the specific scope of downstream obligations as role-dependent and evolving rather than fully settled. The evidence describes an information-flow and role-allocation mechanism, not an exhaustive enumeration of every downstream duty. Some underlying Commission guidelines are described in the cited sources as preliminary or evolving as of the dates referenced (for example, guidance summarized as of April 2025 and materials dated into 2025). Downstream organizations should confirm precise obligations against the current text of the AI Act and applicable Commission guidance rather than relying on a fixed checklist.

Who it's relevant to

AI system providers building on GPAI models
Organizations that integrate or fine-tune an upstream general-purpose AI model to create their own systems are the core audience for these obligations. They carry distinct compliance duties and typically depend on documentation from the upstream provider to satisfy them, so they need to secure that information flow and confirm which role-specific duties apply to their situation.
Deployers of AI systems
Entities that put an AI system into use may hold obligations that differ from those of providers. Because the cited sources note that provider and deployer obligations arise in different contexts, deployers should clarify whether their activities characterize them as a downstream provider or a deployer, since this affects which duties apply.
Compliance and governance teams
Compliance officers and AI governance functions must map how responsibilities are allocated across the upstream–downstream relationship, ensure required documentation is requested from and supplied by upstream providers, and avoid assuming that upstream compliance discharges their own separate obligations. Given that some guidance is described as preliminary or evolving, these teams should track updates to the AI Act and Commission materials.
Legal and contracting professionals
Legal specialists negotiating agreements with upstream GPAI model providers need to address documentation access and role allocation, since a downstream provider's ability to meet its obligations can hinge on information it must obtain from the upstream party. Contractual terms are one mechanism for securing the information flow the framework contemplates.

Inside Downstream Provider Obligations

Downstream Provider (as commonly framed)
An actor who takes an existing AI system or model, often provided by an upstream developer, and integrates, adapts, fine-tunes, or deploys it further along the value chain. The term is used in several AI governance discussions, notably in the EU AI Act context, where obligations can shift depending on the role an actor assumes. The precise scope of who counts as a 'downstream provider' varies by framework and should be confirmed against the applicable instrument rather than assumed.
Role-Based Obligation Allocation
Downstream obligations typically depend on the functional role an actor plays rather than on a fixed label. In many frameworks, an actor that substantially modifies a system, places it on the market under its own name, or changes its intended purpose may assume provider-level responsibilities. The allocation of duties along the chain is a defining feature of the concept.
Information and Documentation Flow
Downstream provider obligations commonly involve receiving, relying on, and passing along technical documentation, usage instructions, and risk-relevant information from upstream parties, and supplying comparable information to further deployers or users. This is a coordination function rather than a guarantee that all upstream information is complete or accurate.
Boundary Between Provider and Deployer Duties
A recurring component is distinguishing obligations that attach to providers (those who develop or substantially modify a system) from those that attach to deployers or users. Whether a downstream actor crosses into provider status is often the pivotal determination and is treated differently across regulatory regimes.
Governance and Model Risk Interfaces
Downstream obligations sit at the intersection of AI governance (accountability structures and policies governing who is responsible for an integrated system) and model risk management (identifying and controlling risks introduced or altered by adaptation and deployment). These interfaces overlap but remain distinct: governance assigns responsibility, while model risk practices measure and monitor the risks that responsibility covers.

Common questions

Answers to the questions practitioners most commonly ask about Downstream Provider Obligations.

Does becoming a downstream provider mean I take on the same obligations as the original developer of the AI system or model?
Not automatically. In many frameworks the distribution of obligations depends on the role you occupy and the actions you take, not simply on your position in the supply chain. A common misconception is that downstream actors inherit the full obligation set of upstream developers. In practice, obligations are typically allocated according to who exercises control over particular functions or modifications. Where a downstream actor substantially modifies a system or puts it into service under its own name, it may assume some obligations that resemble those of an upstream developer for the affected aspects, but this is a role- and action-dependent reallocation rather than a blanket transfer. The precise thresholds and triggers vary by regulatory instrument and jurisdiction, and some remain subject to interpretation and guidance, so this general description should not be read as a fixed rule.
If I only integrate or deploy an AI system without changing it, am I free of downstream provider obligations?
Not necessarily. A frequent error is to assume that pure integration or deployment carries no obligations, or conversely that any use makes you a provider. In many frameworks a distinct set of duties can attach to those who put a system into use, and these are often described separately from provider obligations, which is one reason professionals distinguish deployer or user roles from provider roles. Whether specific downstream provider obligations apply typically turns on factors such as whether you modify the system, market it under your own name, or change its intended purpose. Absence of modification reduces the likelihood of assuming provider-level obligations under many instruments, but it does not necessarily eliminate all responsibilities, and the applicable duties depend on the specific framework and how your role is characterized within it.
How do we determine whether our organization qualifies as a downstream provider in a given deployment?
A practical starting point is to map, for each AI system, what your organization actually does: whether you resell, integrate, fine-tune, retrain, rebrand, or alter the intended purpose. Many frameworks tie obligation status to these actions rather than to labels. Document the specific modifications and the degree of control you exercise over the system's design and function. Because the triggers and thresholds differ across instruments and jurisdictions, this determination is typically made per system and per applicable framework, and it is common to seek legal review where the characterization is unclear or where multiple frameworks may apply. Treat the classification as something to be evidenced and revisited, not fixed once.
What documentation should we maintain to support our downstream provider position?
Organizations commonly retain records that evidence the nature and extent of their role, such as descriptions of any modifications made, the stated intended purpose before and after any change, contractual allocations of responsibility with upstream suppliers, and any information received from upstream developers. Where you rely on upstream documentation to meet your own obligations, retaining and being able to reference that material is often important. The specific documentation expectations depend on the applicable framework, so this list reflects common practice rather than a universal requirement. Aligning documentation practices with your organization's broader model risk management and AI governance records can reduce duplication, while keeping the distinct purposes of each record clear.
How should downstream provider obligations be handled in contracts with upstream suppliers?
Contracts are frequently used to clarify how responsibilities and information flows are allocated between upstream and downstream parties, for example by specifying what technical documentation, performance information, or notices the upstream party will provide. It is worth noting that contractual allocation between private parties does not necessarily override obligations imposed directly by a regulatory instrument; in many frameworks certain duties attach to a role regardless of private agreement. Contracts can therefore support compliance and manage residual risk, but they are typically treated as complementary to, not a substitute for, statutory or regulatory obligations. Legal review is commonly used to confirm how these interact in a given jurisdiction.
How do downstream provider obligations relate to our existing AI governance and model risk management functions?
Downstream provider obligations generally sit at the intersection of both. AI governance structures, covering accountability, oversight, and policy, are often where responsibility for determining and tracking these obligations is assigned, while model risk management processes, such as validation, ongoing monitoring, and control of model-related risks, are often where the substantive work of meeting them is carried out. Keeping these functions distinct matters: governance defines who is accountable and under what policy, whereas model risk management addresses the identification, measurement, and control of risks from the models in use. Mapping specific downstream obligations to existing lines of defense can help avoid gaps, but the mapping should reflect how your organization has defined those roles rather than assuming a single standard allocation.

Common misconceptions

A downstream provider inherits all upstream compliance work and therefore has little independent responsibility.
In many frameworks, an actor that modifies a system, deploys it under its own name, or changes its intended purpose can take on independent, provider-level obligations rather than simply relying on upstream conformity. The extent of inherited versus independent duty depends on the applicable instrument and the actor's specific role, and should not be assumed.
The terms 'downstream provider,' 'deployer,' and 'user' are interchangeable.
These are typically distinct roles carrying different obligations. Whether a downstream actor is treated as a provider or a deployer often turns on facts such as substantial modification or rebranding. Conflating the roles can lead to misallocated compliance responsibilities.
Meeting downstream obligations eliminates the model-related risk of the deployed system.
Obligations and controls are measures that reduce and manage risk, not eliminate it. Downstream integration or adaptation can introduce residual and even new risks that require ongoing monitoring, distinct from the inherent risk of the original upstream system.

Best practices

Determine your functional role before assuming your obligations: assess whether integration, fine-tuning, substantial modification, or rebranding may shift you into provider-level responsibilities under the applicable framework, rather than defaulting to a deployer or user label.
Establish structured information exchange with upstream parties, capturing the documentation, intended-purpose statements, and usage instructions you receive, and defining what you must pass to further deployers or users.
Do not treat upstream documentation as a substitute for your own diligence; verify that received information is sufficient for your intended use and flag gaps, since upstream completeness cannot be assumed.
Maintain a clear governance mapping that assigns accountability for the integrated system, distinguishing responsibilities that remain with the upstream developer from those you assume through modification or deployment.
Apply model risk practices to changes you introduce, monitoring for risks arising from adaptation or deployment context separately from the inherent risk of the original system, and track residual risk over time.
Confirm the scope, binding status, and jurisdiction of the specific instrument driving your obligations before acting, as downstream duties differ across regulatory regimes and are not interchangeable.