General-purpose AI obligations under the EU AI Act

The EU AI Act defines a general-purpose AI model as an AI model trained with a large amount of data using self-supervision at scale that displays significant generality and is capable of competently performing a wide range of distinct tasks.

In practice, this definition covers the major foundation models: large language models like GPT-4, Claude, and Llama; multimodal models; and large-scale image and code generation models. The definition is intended to capture models that are “general purpose” in that they were not designed for a single specific application.

What a GPAI model is not is a deployed AI system. The distinction matters: the GPAI provisions apply to the model itself, as made available by the provider. The downstream system that uses the GPAI model — the product or application built on top of it — is a separate AI system with its own classification and its own obligations.

For GPAI models, the provider is the organisation that trains the model and places it on the EU market — OpenAI, Anthropic, Google, Meta, Mistral, and similar organisations. These are GPAI providers.

An enterprise organisation that accesses the model via API to build a product or internal tool is a downstream provider — a provider of the downstream AI system built on top of the GPAI model. This organisation is not a GPAI provider; it is the provider of a separate AI system.

The distinction matters because the obligations are different:

• GPAI model provider — must satisfy Chapter V obligations: technical documentation, downstream provider information, copyright compliance, and (for systemic-risk models) adversarial testing and incident reporting.
• Downstream system provider — must classify their downstream system under the standard tier framework and satisfy whichever obligations apply to that tier. If the downstream system is high-risk, the provider must satisfy Articles 9–15, regardless of whether the GPAI model it uses has its own obligations.

All GPAI model providers must publish technical documentation covering the model's training methodology, the data used in training, the computational requirements for training and inference, and the model's capabilities and known limitations.

They must also make available to downstream providers — organisations building products on top of the model — the information and documentation they need to satisfy their own high-risk obligations. This is the transparency bridge between the GPAI framework and the downstream system framework: the GPAI provider must disclose what downstream providers need in order to document their systems.

In practice, the major GPAI providers satisfy the standard transparency obligation through model cards, system cards, and terms of service documentation. The adequacy of that disclosure for downstream Annex IV documentation purposes is an active area of discussion — the current state is that disclosure exists but is not always sufficient for the depth that Annex IV requires.

The GPAI transparency obligation creates a supply chain of disclosure: the GPAI provider discloses to the downstream provider, who uses that disclosure to build their Annex IV documentation. Where the GPAI provider's disclosure is incomplete, the downstream provider has a documentation gap that cannot be filled internally.

Article 53(1)(c) and (d) require GPAI providers to comply with EU copyright law in relation to their training data, and to publish a publicly available summary of the training data used. This is the copyright compliance obligation that has attracted significant attention from rights holders and publishers.

The practical implication for downstream providers and deployers is that they can reference the GPAI provider's published copyright compliance summary as part of their own data governance documentation. This does not transfer the liability — if the GPAI provider's training data included infringing content, the provider bears the copyright liability, not the downstream user — but it does create a documented chain of accountability.

Models trained using more than 10^25 FLOPs of compute are presumed to present systemic risk and must satisfy additional obligations under Articles 55–56. This threshold approximately corresponds to GPT-4-scale training at the time of the Act's adoption, though the European AI Office can update the threshold by delegated act.

The additional systemic-risk obligations are more operationally intensive:

• Adversarial testing — red-team testing against systemic risks (CBRN capabilities, large-scale cybersecurity risks, democratic process interference), conducted before market placement and after significant updates.
• Incident reporting — report serious incidents to the European AI Office within defined timeframes.
• Cybersecurity measures — technical measures protecting the model weights and training pipeline, proportionate to the systemic risk posed.
• Energy efficiency reporting — document energy consumption during training and inference.

Most enterprise organisations are not GPAI providers — they are deployers of systems that use GPAI models as a component. Their obligations come from their role as downstream system providers or deployers, not from the GPAI framework directly. But the GPAI framework affects what they can document about the systems they deploy.

The critical practical implication is that Annex IV documentation for a high-risk downstream system built on a GPAI model will have gaps in the data governance section (section 4) unless the GPAI provider discloses sufficient training data information. These gaps should be documented explicitly — “the model provider has not disclosed sufficient training data detail to satisfy this requirement” — rather than left blank. Documented gaps are defensible; undocumented gaps are not.

An AI security review of a system built on a GPAI model must address the GPAI layer explicitly. The review cannot assess what the model provider has not disclosed — but it can document what has been disclosed, what the gaps are, and what controls the downstream system implements to manage the risks created by those gaps.

The specific areas where a security review of a GPAI-powered system adds value are:

• Prompt injection risk assessment — GPAI models are susceptible to prompt injection via input, documents, and tool results. The review should assess the attack surface specific to the deployment context.
• Output validation controls — the review should assess whether outputs from the GPAI model are validated before being used to make or influence decisions, and whether the validation is proportionate to the risk.
• Data boundary controls — for systems that pass personal or sensitive data to the GPAI model (via the API), the review should assess whether data minimisation controls are in place and whether the API terms of service permit the data sharing that is occurring.
• Model provider dependency documentation — the review should document which model provider is used, what version, and what happens if the provider changes the model or its terms of service.

For a broader treatment of GPAI-specific security risks, see our guides on prompt injection and LLM supply chain security.