Chapter 7. GPAI: model-provider obligations, systemic risk, Code of Practice
A separate track of the AI Act — general-purpose AI. The view "from below": what it means for someone who doesn't make the model but uses it.
The situation at Kompas
In chapters 3 and 5, Kompas ran into someone else's foundation model: part of the obligations depends on what its provider discloses. It's time to deal with a separate track of the law — the GPAI regime (general-purpose AI). Kompas's interest here is twofold and strictly practical: (a) what the law requires of the model provider at all, and (b) what of that Kompas, as a consumer, is entitled to demand and lean on to close its own gaps in Annex IV.
The chapter's conclusion turns out to be unexpectedly strategic: choosing a foundation model is not only a question of price and quality, but a regulatory decision.
What the rule says
The GPAI regime (Art. 51–55, in force from 02.08.2025) — the duties of providers of general-purpose models:
- Technical documentation of the model and information down the chain — so that downstream developers (like Kompas) can meet their obligations. This is the direct legal bridge from "someone else's model" to your technical file.
- A copyright-compliance policy during training.
- A public summary of training data per the AI Office template.
Systemic-risk GPAI. Models above the impact threshold (the law uses the criterion of a very large amount of compute at training as a presumption of systemic risk) carry heightened duties: model evaluation, adversarial testing (adversarial / red-teaming), incident reporting, enhanced cybersecurity.
The GPAI Code of Practice — a voluntary instrument helping providers demonstrate conformity before harmonized standards appear; following it creates a presumption of good faith.
Stitch with the value chain (ch. 5): the GPAI provider's documentation is the input for Kompas's Annex IV and Art. 10. Part of what Kompas can't know about the model itself, it gets (or doesn't get) here.
How it lands on the product
Kompas is a downstream deployer of GPAI: it doesn't carry the model provider's duties, but critically depends on what the provider disclosed. Hence a practical artifact — a model-provider due-diligence checklist: model card, training-data summary, license and usage limitations, stated metrics and known limitations, presence of a Code of Practice. And a separate column — "what to do if they don't give it": record the gap in the dossier as an accepted risk with a justification.
A practical shift in thinking: choosing the model provider becomes a compliance decision. A model with the best benchmarks but no disclosed documentation creates a hole in Kompas's Annex IV that there's nothing to fill.
Where it breaks
The provider discloses too little. Even with a duty to disclose down the chain, the volume and quality of documentation vary. Kompas may be left with a gap in Art. 10 / Annex IV that it structurally cannot close — and that it will have to explain to an auditor.
The systemic-risk threshold moves. The systemic-risk criterion and the list of such models are being revised; the status of a specific model may change, dragging with it a change in the downstream context.
Open-weight models. For open-weight models, part of the provider's duties is relaxed — and so the share of liability and "explanation of provenance" shifts down, onto whoever deploys them, i.e. onto Kompas.
What to do as engineer/product
Introduce model due diligence into the provider-selection procedure on par with price and quality: a model without the needed documentation is a compliance risk, not a good deal. Run the checklist before integration, not after.
Record in the dossier exactly what the provider disclosed and what it didn't — a liability boundary acknowledged in writing protects better than the silent hope that "the model is serious, so it's all fine."
Provocation
Choosing a foundation model is a regulatory decision disguised as a technical one. The team chooses by benchmarks, price and latency, and pays with conformity: a leading model without disclosed documentation leaves a hole in your technical file that you — not its provider — will have to close in front of the auditor.
Read next
Shipping an AI product under regulatory risk?
A read of your product against the EU AI Act: risk class, role in the value chain, obligations and dossier — as a design constraint on the way in, not a lawyer's check at the end.
Email meThe transition engine
Next Move Engine — the system that takes a team to an autonomous delivery loop.
Next Move Engine →