GPAI Models Inside High-Risk AI Systems: How the EU AI Act Regimes Interact

Overview: Two Regimes, One Product

The EU AI Act contains two largely parallel regulatory tracks. Chapter V governs general-purpose AI models — the foundation layer trained on broad data at scale, capable of performing a wide range of distinct tasks, and typically integrated into downstream applications. Chapter III governs high-risk AI systems — the application layer performing the sensitive functions listed in Annex III or embedded in Annex I products. The tracks have different addressees, different obligations and even different supervisors: the Commission's AI Office for models, national market surveillance authorities for systems. Yet modern AI products routinely straddle both: a recruitment screening tool built on a large language model, a clinical triage assistant on a fine-tuned foundation model, a credit decisioning platform calling a model API. Understanding how the regimes interlock — and where responsibility transfers — is now a core competency for anyone building or buying serious AI in Europe.

The Baseline Allocation of Duties

The structure resolves into a clean default. The GPAI model provider owes the Chapter V obligations from August 2, 2025: technical documentation of the model under Annex XI, information and documentation for downstream providers under Annex XII, a policy to comply with Union copyright law including the reservation of rights, and a sufficiently detailed public summary of training content in the AI Office's template. Models meeting the systemic risk conditions of Article 51 — including the presumption attached to training compute above ten to the twenty-fifth floating point operations — additionally owe model evaluations, adversarial testing, systemic risk mitigation, serious incident reporting and cybersecurity protection under Article 55.

The high-risk system provider — the entity placing the application on the market under its own name — owes everything in Chapter III: risk management, data governance for the system's own training and fine-tuning data, technical documentation covering the whole system including its model components, logging, transparency to deployers, human oversight design, accuracy and robustness evidence, conformity assessment, CE marking, registration and post-market monitoring. Crucially, building on someone else's model does not dilute these duties. The system provider answers for the behaviour of the complete system, including failure modes inherited from the model — hallucination, bias, prompt injection susceptibility — whether or not it trained a single parameter.

The Connective Tissue: Article 25 and Annex XII

A system provider cannot document what it cannot see, and the regulation knows it. Article 53(1)(b) obliges model providers to make available, to providers of AI systems who intend to integrate the model, the information and documentation of Annex XII — capabilities, limitations, technical conditions of integration, modalities of the training process — sufficient to enable downstream providers to comply with their own obligations, while protecting intellectual property and trade secrets. Article 25(4) reinforces the chain for high-risk systems: the provider of a high-risk AI system and third parties supplying AI systems, tools, services, components or processes 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, to enable the high-risk provider to fully comply — with a carve-out for third parties making tools and components other than GPAI models available under free and open-source licences. The compliance reality is contractual: the model supply agreement is now a regulatory document, and a high-risk builder that accepts a model under terms providing no documentation flow has signed away its own ability to comply.

The Fine-Tuning Trap

The most consequential and least understood rule in the interplay concerns modification. An organisation that fine-tunes or otherwise substantially modifies a general-purpose model and places the result on the market may become the provider of a new general-purpose AI model, inheriting Chapter V duties for the modification — with the recitals indicating that obligations then focus on the modification performed, building on the original model's documentation. Simultaneously, under Article 25(1), a distributor, importer, deployer or other third party becomes the provider of a high-risk system when it puts its name on one, substantially modifies one, or modifies the intended purpose of a system such that it becomes high-risk. The two rules can stack: a company that fine-tunes a foundation model and ships it inside its own hiring tool can find itself holding model-level duties to the AI Office and system-level duties to national authorities at once. Companies should map these thresholds before engineering decisions are made, not after — the difference between prompting, retrieval augmentation, adapter tuning and full fine-tuning carries regulatory weight that technical teams rarely suspect.

Timeline Asymmetries Worth Knowing

• GPAI obligations: applicable since August 2, 2025; models placed on the market before that date must be brought into compliance by August 2, 2027
• High-risk Annex III obligations: applicable from August 2, 2026
• High-risk Article 6(1) embedded systems: applicable from August 2, 2027

The asymmetry means a high-risk builder integrating models today should already be receiving Chapter V documentation from its model suppliers — and its own Chapter III deadline arrives August 2026. Builders whose suppliers cannot produce Annex XII packages now have a supply chain problem, not a future risk.

Practical Steps for System Builders

1. Inventory the models inside every product, including embedded third-party components and API dependencies, and record each supplier's Chapter V status
2. Contract the information flow: Annex XII documentation, update notification duties, deprecation terms and Article 25(4) assistance clauses belong in every model supply agreement for high-risk use
3. Classify your modifications honestly against the provider-shift thresholds, with engineering and legal reviewing together
4. Test the integrated system, not the model's benchmark claims: your Article 15 accuracy and robustness evidence must reflect the system in its intended context
5. Design model-swap resilience: if a supplier withdraws a model or fails its own compliance, your conformity assessment must survive the substitution

Concrete Example

A HR technology company builds a candidate screening product on a major foundation model via API, adding retrieval over job descriptions and a scoring layer it trains itself. The screening product is Annex III point 4 high-risk: the company is its provider and owes full Chapter III compliance by August 2, 2026, documented across the whole stack. The foundation model provider owes Chapter V duties and must supply Annex XII documentation enabling the integration. The scoring layer is the company's own — its training data falls under Article 10 data governance directly. If the company later fine-tunes the foundation model on hiring dialogue data and markets the tuned model to other vendors, it steps into model-provider shoes for that modification, adding AI Office jurisdiction to its national supervision. Three regulatory relationships, one product — each manageable, none optional.

Action Before August 2, 2026

The interplay rewards early contractual housekeeping above all else. Audit existing model agreements for documentation and assistance clauses; most pre-2025 contracts contain none. Request Annex XII packages from every supplier now and treat non-response as a vendor risk signal. Map modification practices against the provider-shift thresholds before the next product cycle locks them in. And watch the AI Office's guidance on downstream documentation and the evolving codes of practice, because the practical detail of what suppliers must hand over is being settled there. The layered regime is genuinely workable — but only for organisations that know, at every layer of their stack, who the law thinks they are.

Open-Source Models: A Partial Exemption With Sharp Edges

One nuance deserves separate treatment because it is so frequently overstated. Providers of models released under free and open-source licences, with weights, architecture and usage information publicly available, are exempt from some Chapter V obligations — notably the Annex XI documentation and Annex XII downstream information duties — but the exemption evaporates for models with systemic risk, and the copyright policy and training content summary duties remain. More importantly for the interplay: the exemption operates at model level only. A high-risk system built on an open model enjoys no relief whatsoever — the system provider owes full Chapter III compliance and must generate from its own analysis the model understanding that a commercial supplier would have documented. Open weights help here: the system builder can inspect, evaluate and red-team the model directly rather than negotiating for documentation. But that freedom is also the obligation — there is no upstream party contractually bound to assist, and the Article 25(4) assistance mechanism explicitly does not bind third parties releasing tools and components under free and open-source licences. Teams choosing between a commercial model with an Annex XII package and an open model with none should price that documentation burden into the decision; for an Annex III product, it is rarely trivial.

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.