Chapter 11: General-Purpose AI and Foundation Models

EU AI Act Implementation Guide · Full Chapter

What Is a General-Purpose AI Model?

The EU AI Act defines a general-purpose AI (GPAI) model in Article 3(63) as an AI model trained on large amounts of data using self-supervision at scale, that displays significant generality, and is capable of competently performing a wide range of distinct tasks, regardless of how it is placed on the market or put into service. The word “model” is deliberate: the AI Act applies GPAI rules to the model layer, not to the downstream application built on top of it.

In practice, GPAI models are the large language models, multimodal models, and foundation models released by providers such as OpenAI, Anthropic, Google, Meta, Mistral, and others. GPT-4, Claude 3 Opus, Gemini Ultra, LLaMA 3, and Mistral Large are examples of models that meet the definition. A narrow model trained for a single task — for example, a classifier that predicts customer churn from tabular data — is not a GPAI model.

A GPAI model is not an AI system. It is a component that becomes part of an AI system when a provider or deployer integrates it into an application. This distinction matters because the AI Act's GPAI obligations (Articles 51–56) apply at the model level, while the system-level obligations (Chapters III and IV) apply at the application level. A single GPAI model may be integrated into many different AI systems, each of which may have its own risk classification.

The Two-Tier Obligation Structure

The AI Act creates two categories of GPAI model, each with a different set of obligations. The threshold separating them is the computational power used in training the model.

The 10²⁵ FLOPs threshold is a proxy for model capability. It reflects the view that models trained at this scale are likely to have capabilities that, if misused or if they fail, could have systemic consequences across the EU — affecting critical infrastructure, public safety, democratic processes, or economic stability at scale. The threshold was set in the initial regulation text and may be revised by the European Commission as the technology evolves.

The AI Office (formally the European AI Office, established under Article 64) is responsible for overseeing GPAI models. It classifies models with systemic risk, supervises compliance, and can conduct its own evaluations of any GPAI model it has reason to believe presents systemic risk.

Standard GPAI Model Obligations (Articles 52–54)

Providers of GPAI models that do not meet the systemic-risk threshold must comply with Articles 52 to 54. These obligations are designed to ensure that downstream providers — the companies and developers who integrate the model into their products — have the information they need to comply with their own AI Act obligations.

Technical Documentation (Article 53 and Annex XI)

Standard GPAI providers must draw up technical documentation covering the model, keep it up to date, and make it available to the AI Office on request. The documentation must cover the items specified in Annex XI of the AI Act, including: the general description of the model and its intended purpose, a description of the architecture and training methodology, the computational resources used, the data used in pre-training and fine-tuning (including the geographic origin of the data and data governance measures), information about the model’s known limitations and risks, and the measures taken to mitigate those risks.

The technical documentation requirement is a provider-facing obligation. Downstream providers who fine-tune an existing GPAI model and place it on the market under their own name become providers themselves and must produce their own documentation. Simply reselling access to a third-party model’s API does not make the reseller a provider of the underlying GPAI model.

Information for Downstream Providers (Article 53(1)(b))

Providers of standard GPAI models must make available to downstream providers — at their request or by default — the information and documentation they need to comply with their own obligations under the AI Act. This is the information-flow mechanism of the GPAI framework: a developer building a high-risk AI application on top of a GPAI model needs to be able to demonstrate that the model they are using has known capabilities and limitations. If the GPAI provider does not supply this information, the downstream provider cannot fulfil their own documentation obligations.

In practice, this means that GPAI providers publish system cards, model cards, acceptable use policies, and API documentation. Downstream providers should retain records of the information provided by their GPAI supplier as part of their own compliance documentation.

Copyright Policy (Article 53(1)(c))

Providers of standard GPAI models must put in place a policy that complies with EU copyright law, including the Text and Data Mining exceptions in Directive 2019/790 (the Digital Single Market Directive). This means adopting a policy for identifying and respecting rights-reserved content in training data, as well as honoring opt-out mechanisms where they exist. The copyright policy must be documented and maintained.

This obligation is not exempt for open-source GPAI providers. Under Article 53(2), open-source GPAI models are exempt from the technical documentation and downstream information obligations, but the copyright compliance requirement and the training data summary requirement apply in full regardless of the model’s licensing status.

Training Data Summary (Article 53(1)(d))

Providers must publish a sufficiently detailed summary of the content used to train the GPAI model. The AI Office has developed a template for this summary as part of the GPAI Code of Practice process. The summary must be publicly available and must include enough detail for a downstream provider or an enforcement authority to understand the character and scope of the training data. It is not required to be a comprehensive data sheet, but it must go beyond a generic statement that the model was trained on “data from the internet.”

Open-Source Exceptions (Article 53(2))

GPAI model providers that release their model weights and parameters under a free and open-source licence may apply for exemption from the technical documentation obligation (Article 53(1)(a)) and the downstream information obligation (Article 53(1)(b)). The exemptions are conditional: the model must be genuinely open-source, and the provider may not have a systemic-risk classification under Article 51.

GPAI Models with Systemic Risk (Articles 55–56)

Providers of GPAI models classified as systemic risk must fulfil all the obligations in Articles 52–54, plus the additional obligations in Articles 55 and 56. The additional obligations reflect the AI Office’s judgement that models at this capability level warrant enhanced scrutiny and active risk management.

Model Evaluation (Article 55 and Annex XI, Section 2)

Systemic-risk GPAI providers must perform model evaluation in accordance with standardised protocols, including adversarial testing. The evaluation must assess the model’s known and reasonably foreseeable systemic risks at the EU level and the concrete measures implemented to mitigate those risks. Adversarial testing — sometimes called red-teaming — involves deliberately probing the model for harmful or unexpected behaviour under adversarial conditions. Evaluations must be documented and made available to the AI Office on request.

Annex XI, Section 2 sets out the additional information that providers of GPAI models with systemic risk must document: in addition to the Annex XI requirements for standard GPAI, providers must include documentation of the adversarial testing methodologies used, the results of those tests, the identified systemic risks, and the mitigation measures adopted. (Annex XII is a separate document — the transparency information a provider supplies to downstream providers under Article 53(1), point (b).)

Incident Reporting (Article 55(1)(c))

Providers of systemic-risk GPAI models must track, document, and report to the AI Office any serious incidents — or any information that becomes available to them about serious incidents — that are related to their models. A serious incident is defined as an incident that leads, or could lead, to the death of a person or serious harm to their health, a significant unintended disruption to critical infrastructure, a significant infringement of fundamental rights, or other serious and irreversible harm to society at the scale that would justify systemic-risk classification.

The reporting obligation is not limited to incidents that the provider caused. If a provider of a systemic-risk GPAI model becomes aware that a downstream use of their model has caused or could cause a serious incident, they must report it. This creates an ongoing monitoring requirement for providers of systemic-risk models.

Cybersecurity Measures (Article 55(1)(d))

Systemic-risk GPAI providers must ensure adequate cybersecurity protection for the model, its associated infrastructure, and the physical security of the hardware on which it runs. The AI Act does not prescribe specific technical standards, but it requires proportionate measures that account for the risks associated with the model’s capabilities. Providers are expected to implement controls against adversarial manipulation, model extraction, data exfiltration, and other attacks that could affect the model’s behaviour at scale.

The AI Office and the GPAI Code of Practice

The AI Office (established under Article 64 within the European Commission) has primary responsibility for overseeing GPAI models. It has powers that national competent authorities do not have in the GPAI context: it can conduct evaluations of any GPAI model, request access to documentation and model weights, impose corrective measures, and refer systemic-risk findings to the European Commission.

The GPAI Code of Practice is a self-regulatory instrument developed by the AI Office in cooperation with GPAI providers, industry stakeholders, civil society, and academic experts. Under Article 53(4) (and Article 55(2) for systemic-risk models), providers may rely on the code to demonstrate compliance with the applicable GPAI obligations until a harmonised standard is published. Following the code does not itself confer a presumption of conformity: that presumption is granted only by compliance with European harmonised standards, to the extent those standards cover the obligations. The code does not remove the legal obligations — it provides a structured pathway to demonstrate compliance with them.

The first version of the GPAI Code of Practice was published in draft by the AI Office in November 2024, with an iterative consultation process running into 2025. Providers of GPAI models placed on the EU market are expected to engage with the code process and document their compliance position relative to the code’s provisions.

Implications for Deployers Using Third-Party AI APIs

If you are a developer or business that accesses GPAI capabilities by calling a third-party API — for example, using the OpenAI API, the Anthropic API, the Google Gemini API, or an equivalent service — you are not a GPAI provider. The obligations in Articles 51–56 fall on the company that developed and released the model, not on the downstream developer or deployer who accesses it via an API.

This does not mean GPAI rules are irrelevant to you. Four specific implications apply:

1 — You are a deployer of a GPAI-based AI system. When you build an application using a GPAI model and put it into service, you deploy an AI system. Your obligations as a deployer depend on the risk classification of your system, not on the classification of the underlying GPAI model. If your application falls into an Annex III high-risk domain, you have the full set of Chapter III deployer obligations regardless of which GPAI model powers it.

2 — You need information from the GPAI provider. If you are deploying a high-risk AI system built on a GPAI model, you need to include information about the model’s capabilities and limitations in your own technical documentation. Under Article 53(1)(b), the GPAI provider is obligated to make this information available to you. If your GPAI supplier does not publish adequate model cards, system cards, or equivalent documentation, you have a legal basis to request it.

3 — Fine-tuning may make you a provider. If you take an open-source GPAI model, fine-tune it, and release it on the EU market — either as a product or via an API — you may become a GPAI provider yourself, subject to the Article 52–54 obligations. The threshold is placing the fine-tuned model on the market under your own name with your own intended purpose, not simply using it internally.

4 — Check your GPAI provider’s acceptable use policy. GPAI providers include acceptable use restrictions in their terms of service. Deploying a GPAI model in ways that violate these restrictions may constitute a breach of your contract with the provider and — if the violation involves a prohibited or high-risk use — may also expose you to AI Act liability for the application you have built.

When Does Chapter 11 Apply?

GPAI obligations under Articles 51–56 applied from 2 August 2025 — 12 months after the AI Act entered into force on 1 August 2024. This is earlier than the general AI Act compliance date of 2 August 2026. GPAI providers who had not met the Article 52–56 obligations were already out of compliance as of 2 August 2025.

Under Article 111(3), providers of GPAI models that were placed on the market before 2 August 2025 must take the necessary steps to comply with the obligations laid down in the Regulation by 2 August 2027. Models placed on the market from 2 August 2025 onward are subject to the full obligation set from the date of their release in the EU market.

GPAI Obligation Summary Table

Self-Check: GPAI Classification and Obligations

Summary

The AI Act imposes a two-tier obligation structure on providers of general-purpose AI models. Standard GPAI models are subject to Articles 52–54: technical documentation, information provision to downstream providers, a copyright compliance policy, and a public training data summary. Open-source GPAI models below the systemic-risk threshold are exempt from the first two but not the last two. GPAI models trained with more than 10²⁵ FLOPs are classified as systemic risk and must additionally comply with Articles 55–56: model evaluation and adversarial testing documented per Annex XI, Section 2, incident reporting to the AI Office, and cybersecurity protection. The AI Office oversees GPAI compliance and a GPAI Code of Practice provides a structured conformity pathway. Deployers who access GPAI capabilities via third-party APIs are not GPAI providers, but they must obtain sufficient model information for their own documentation obligations if they are deploying high-risk AI systems. GPAI obligations applied from 2 August 2025. Chapter 12 covers AI governance structures: the obligations for market surveillance, the role of national competent authorities, and the internal governance processes that organisations must implement under Article 26.