EU AI Act and the AI Value Chain: API Access, Components, and Who Owes What

One Product, Many Hands

A typical AI product in 2026 passes through several hands before reaching a user: a model developer trains a general-purpose model; a platform exposes it through an API; a software company builds an application on the API; an enterprise deploys the application on its staff or customers. Regulation (EU) 2024/1689 was drafted for exactly this topology. Rather than placing all duties on one actor, it assigns obligations per role — provider of the GPAI model, provider of the AI system, importer, distributor, deployer — and then adds rules for how responsibility moves when actors change the product or their position. Understanding the allocation is the difference between a clean contract stack and a liability surprise.

The Model Layer: Chapter V Duties Travel with the Provider

The GPAI model provider — whoever places the model on the EU market under its own name — owes the Chapter V set: Annex XI technical documentation, Annex XII information for downstream providers, a copyright policy, a public training data summary, and the Article 55 duties where systemic risk applies. Crucially, these duties do not transfer to API customers: integrating a model through an API does not make the integrator responsible for the model's documentation, nor does the model provider's compliance satisfy any obligation of the integrator. The layers are parallel, connected by one statutory conduit: the Article 53(1)(b) information duty, which obliges the model provider to give downstream providers what they need to understand capabilities and limitations and to meet their own obligations.

The System Layer: API Integrators Are Providers

The company that builds an application on a model — its own or a third party's, vertically integrated or via API — is the downstream provider under Article 3(68), and the provider of an AI system under Article 3(3) when it places that system on the market under its own name. Its duties depend on what the system is: the full high-risk regime of Chapter III where Annex III or Annex I applies, from August 2, 2026; the transparency duties of Article 50 for chatbots, synthetic content generation, emotion recognition and deepfakes; and, always, AI literacy under Article 4. The model behind the API is an input to this compliance, not a substitute for it: the integrator's risk management, data governance and testing must address the behaviour of the combined system, including the failure modes of the model it chose.

Article 25: When Roles Shift Mid-Chain

Article 25 is the value chain's switching mechanism for high-risk systems. A distributor, importer, deployer or other third party is considered a provider of a high-risk AI system — assuming all provider obligations — where it puts its name or trademark on a high-risk system already on the market, substantially modifies such a system in a way that keeps it high-risk, or modifies the intended purpose of a system, including a general-purpose one, such that it becomes high-risk. The original provider then steps back for the modified system, but must cooperate: it remains obliged to make available the information and technical access reasonably required for the new provider to fulfil its obligations, unless it had clearly excluded the change of the system into high-risk in its instructions.

The practical translations: white-labelling someone's high-risk product makes you its provider of record; taking a general-purpose assistant and marketing it for recruitment screening converts you into a high-risk provider; and writing clear intended-purpose and acceptable-use documentation is the upstream provider's main defence against inheriting other people's repurposing.

Written Agreements for High-Risk Components

Article 25(4) adds a contract rule that procurement teams should know by heart: the provider of a high-risk AI system and third parties supplying AI systems, tools, services, components or processes that are used or integrated in it shall, by written agreement, specify the necessary information, capabilities, technical access and other assistance, based on the generally acknowledged state of the art, that enable the high-risk provider to fully comply with its obligations. The duty does not apply to third parties making tools and components other than GPAI models publicly available under a free and open-source licence. The AI Office is directed to develop voluntary model contractual terms for such agreements — but absence of model terms is no excuse: the statutory requirement for a written agreement stands on its own, and a high-risk provider that cannot show one for its model supplier has a conformity gap with its own name on it.

Designing the Contract Stack

Translating the statute into agreements, the recurring checklist for an API-based value chain looks like this:

• Annex XII delivery: the model provider supplies and updates the downstream information package, with notice periods for model version changes, deprecations and behavioural updates.
• High-risk assistance: Article 25(4)-conformant commitments on information, technical access and assistance, calibrated to the integrator's conformity assessment needs — evaluation evidence, robustness data, documentation extracts that can be referenced in Annex IV technical files.
• Transparency plumbing: where Article 50 marking depends on the model layer (watermarking, provenance signals), specification and continuity commitments, since the integrator's compliance dies with a silently removed feature.
• Incident flows: bidirectional duties — the integrator reports model-implicated incidents upstream; the model provider passes capability and safety findings downstream — with timelines that fit both Article 73 system reporting and Article 55 model reporting where applicable.
• Intended purpose discipline: acceptable-use terms that exclude high-risk repurposing where the model provider does not wish to support it, and clear statements where it does.
• Audit and evidence: rights to the compliance artefacts each side needs for its own supervisor — national authorities for the system, the AI Office for the model.

Importers, Distributors and the Rest of the Chain

Two further roles complete the map for packaged AI products. Importers — those placing a third-country provider's system on the Union market — must verify before doing so that the conformity assessment was carried out, the documentation exists and the system bears required markings, under Article 23. Distributors making a system available must verify markings and documentation and act when they have reason to consider a system non-conformant, under Article 24. Both must refuse or halt distribution of non-conformant high-risk systems and cooperate with authorities. For the model layer, the analogue is the authorised representative: under Article 54, non-EU GPAI providers must appoint one in the Union before placing a model on the market, giving supervisors a reachable counterparty. In practice, enterprise buyers benefit from these verification layers — a high-risk product that has passed through a diligent importer arrives with its paperwork already checked once — but the layers do not absolve the buyer's own deployer duties.

A Concrete Example

An HR software vendor builds a CV-screening module — Annex III high-risk — on a commercial GPAI model via API. The vendor is the high-risk provider: it runs the Chapter III programme and signs an Article 25(4) written agreement under which the model provider supplies bias-testing evidence, robustness documentation and ninety days notice of model changes. A bank licenses the vendor's product and deploys it unmodified under the vendor's brand: the bank is a deployer, with Article 26 duties — human oversight, monitoring, data relevance — but not provider obligations. A competitor instead licenses the product, rebrands it, and markets it under its own trademark: Article 25 makes the competitor the provider of record, and the original vendor's cooperation duty switches on. Meanwhile the model provider's acceptable-use policy expressly contemplates employment use cases — having priced and documented that exposure — where a rival model's terms exclude them, pushing the compliance burden fully onto integrators who choose it anyway.

Common Pitfalls

The classic value-chain failures: assuming the API vendor's compliance covers the application — the layers are parallel, never substitutive; integrating without the Annex XII package and discovering the gap during conformity assessment; rebranding or repurposing without running the Article 25 analysis, and learning post-launch that provider obligations transferred; missing written agreements for high-risk component suppliers, an omission that is itself inspectable; and contracts frozen at signature while models update weekly — version-change notice clauses are the cheapest insurance in AI procurement.

Action Plan

Map every AI product to its chain — model, system, distribution, deployment — and write the role of each entity against each link, because obligations attach to roles, not to brands. Close the documentation conduits in both directions, paper the high-risk links with Article 25(4) agreements, and rerun the analysis whenever branding, purpose or the model itself changes. The AI Act made the value chain a sequence of explicit legal positions; companies that know which position they occupy at each link negotiate better, comply cheaper, and absorb supplier surprises that flatten their unprepared competitors.

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.