GPAI obligations under the AI Act: a builder's guide

The AI Act splits into two regimes: one for AI systems (Articles 6–58) and one for AI models, specifically *General-Purpose AI* (GPAI) models (Articles 51–55). The two regimes are independent — a single product can be subject to both at the same time.

If you're building on top of GPAI (using a foundation model from someone else), most of these obligations do not fall on you. They fall on the model provider. But you need to understand the regime to know:

• Which information your upstream provider owes you.
• Which obligations attach to *you* if you fine-tune or substantially modify the model.
• When you cross the line from "deployer of GPAI" to "provider of GPAI".

What counts as GPAI?

Article 3(63) defines a GPAI model as one that:

• Is trained on a large amount of data using self-supervision at scale.
• Displays significant generality.
• Is capable of competently performing a wide range of distinct tasks.
• Can be integrated into a variety of downstream systems or applications.

The headline test is generality. A model trained for one task (a fraud-detection classifier, a translation model from English to French) is not GPAI. A foundation model that produces text, code, images, audio, or any combination — and where downstream developers compose it into many products — is.

Two tiers

Tier 1 — standard GPAI (Article 53)

Every GPAI model placed on the EU market triggers four core obligations on the model provider:

1. Technical documentation of the model, kept up to date and made available to the AI Office and competent authorities on request — content per Annex XI.
2. Information for downstream providers, enabling them to comply with their own AI Act obligations — content per Annex XII. This includes capabilities, limitations, intended uses, and acceptable use policies.
3. A copyright policy in compliance with Union law, including a mechanism to identify and respect Article 4(3) opt-outs of the Copyright in the Digital Single Market Directive (the "machine-readable opt-out" via robots.txt-style signals).
4. A sufficiently detailed summary of the training data, published according to a template provided by the AI Office.

There are exemptions for open-source models released under a free and open-source licence, with weights, architecture, and information about model usage publicly available — they only owe (3) and (4), the copyright policy and the training-data summary. The full Annex XI / XII obligations are waived.

Tier 2 — GPAI with systemic risk (Article 55)

A subset of GPAI models trigger additional obligations because they are deemed to pose systemic risk at Union level.

A model is presumed to have systemic risk if its cumulative training compute exceeds 10²⁵ FLOP — a threshold that catches the very largest foundation models (think frontier labs' biggest training runs). The Commission can also designate models as systemic-risk regardless of compute.

For these models, on top of Tier 1, the provider must:

• Perform model evaluation including adversarial testing, with documented protocols.
• Assess and mitigate possible systemic risks at Union level, considering risks like CBRN misuse, manipulation of democratic processes, large-scale fraud, etc.
• Track, document, and report serious incidents to the AI Office without undue delay.
• Ensure adequate cybersecurity protection of the model and the physical infrastructure.

Tier 2 obligations are heavy. They are essentially "frontier model lab" obligations.

What this means if you build *on top of* GPAI

If you call OpenAI's API, Anthropic's API, or any other commercial GPAI provider, the GPAI obligations sit on them, not on you. What you should do as a downstream builder:

1. Ask for the Annex XII information pack

Article 53(1)(b) requires the model provider to give you everything you need to comply with the AI Act. In practice, this means a document or portal entry covering:

• Model capabilities and limitations.
• Acceptable use policy.
• Type and provenance of training data, at the level detailed in Annex XII.
• Information about how to evaluate the model for downstream applications.

The major commercial labs publish a system card or "responsible scaling policy" document; if you're audited, that's the artefact you cite when explaining how *you* understood the model's properties.

2. Keep your own use within the acceptable-use policy

The model provider's AUP isn't decorative — Article 25(1)(c) says you become a *provider* of a high-risk AI system if you use a system "for purposes for which it was not intended" in a way that brings the AI Act's high-risk regime into play.

If a model's AUP forbids medical diagnosis and you ship a diagnostic feature anyway, you have not only breached the contract — you have put yourself in scope of GPAI obligations on top of the AI Act systems regime.

3. Re-evaluate when you fine-tune

If you fine-tune a foundation model and change its intended purpose in a substantial way, Article 25(1)(b) says you become the provider of the resulting model. That can pull GPAI obligations onto you for the fine-tuned variant.

The exact threshold for "substantial modification" is not bright-line, but reasonable signals are:

• You market the fine-tuned model as a separate product.
• The fine-tuning materially changes the model's capabilities or risk profile.
• You're using a much larger compute budget than typical adapter-style fine-tuning.

Lightweight LoRA adapters that customise tone or domain typically don't cross this line. Multi-billion-parameter continued pre-training on a different corpus probably does.

The specific obligations on builders

Independent of GPAI, if you ship a product using GPAI you may also be subject to Article 50 transparency obligations:

• Direct interaction: chat surfaces must disclose AI involvement (Article 50(1)).
• Synthetic content: generated images, audio, video, or text must be marked as machine-generated, in machine-readable form (Article 50(2)). This is the C2PA / content credentials regime in practice.
• Deepfake content: must be disclosed as artificially generated (Article 50(4)).

These attach regardless of who provided the underlying GPAI.

Quick self-check

Before assuming you have no GPAI obligations as a builder, walk through these:

1. Are you training your own large model from scratch? → You may be a GPAI provider. Re-read Article 53.
2. Are you fine-tuning a foundation model and shipping the result under your own name? → Possibly a GPAI provider via Article 25(1)(b).
3. Does your model usage fall within the upstream AUP? → If not, you risk being treated as having materially changed the intended purpose.
4. Does your product trigger Article 50? → Often yes if there's an AI surface.

If you're doing none of these — you're calling an upstream API and pasting outputs into a UI — your GPAI exposure is essentially zero. The upstream provider carries it.

Want a tailored analysis?

The [free 5-question risk classifier](/quiz) flags whether GPAI obligations apply to your system based on your role and the model you're using. The full assessment (€299) generates a draft GPAI obligations summary tied to your specific situation, suitable as a starting point for the technical documentation pack.

*Documentation tool, not legal advice. Have qualified counsel review before relying on any output for compliance purposes.*