General-purpose AI (GPAI) under the EU AI Act: provider obligations explained

The EU AI Act regulates AI systems through the four-tier risk model — unacceptable, high, limited, minimal. Separately, and in parallel, it regulates general-purpose AI models: the foundation models that power downstream applications. These rules sit in Chapter V of the Act and apply to the model itself, not to the specific use case.

This split matters because the same physical model can be both a GPAI model (regulated under Chapter V) and the engine inside a high-risk AI system (regulated under Chapter III). The two regimes apply concurrently. A provider of a GPAI model has obligations regardless of how the model is eventually used downstream; a deployer who builds a high-risk system on top of that model has separate obligations of their own.

This article covers the GPAI regime from the provider's side: what counts as GPAI, who is a provider, what the baseline obligations are, and what changes for systemic-risk GPAI.

What counts as general-purpose AI

Article 3 of the Act defines a general-purpose AI model as one that:

• displays significant generality,
• is capable of competently performing a wide range of distinct tasks,
• regardless of the way the model is placed on the market, and
• can be integrated into a variety of downstream systems or applications.

This is deliberately broad. It captures large language models (LLMs) like GPT, Claude, Llama, Mistral and Gemini; large multimodal models that handle text plus images, video, or audio; and large diffusion models for image generation. It captures models that are released as APIs, as downloadable weights, or embedded in products.

The threshold for "general" is qualitative, not quantitative in the definition itself (the 10^25 FLOPs threshold defines systemic-risk GPAI, not GPAI generally). A 13B-parameter open-weights LLM that handles a wide range of tasks is GPAI. A 7B model that does the same is GPAI. The Act does not exempt smaller models from the GPAI regime.

It is explicit in the recitals (recital 99) that the GPAI definition does not extend to models that are intended for a specific task even where they happen to be large. A 30B-parameter model purpose-built and marketed as a medical-imaging diagnostic, with no general-purpose capability, is not GPAI for these rules; it would be classified through the high-risk regime instead.

Who is the GPAI provider

The same general definition of "provider" applies: an entity that develops a GPAI model, or has one developed, and places it on the market or puts it into service under its own name or trade mark, whether for payment or free of charge.

A few specific positions in the AI supply chain worth being clear on:

• Training a GPAI model from scratch: you are the provider when you release it.
• Fine-tuning a GPAI model that you did not train, then releasing the fine-tuned model under your own name: you can become a provider of a new GPAI model if the result is itself general-purpose. Whether it is depends on whether the fine-tune materially changed the model's capabilities and intended use. A LoRA adapter that nudges style is generally not enough; a substantial fine-tune that broadens or narrows the model's task surface might be.
• Distilling a smaller model from a larger one: you are providing a new model. The distillate is your model.
• Hosting and serving an existing model unmodified (e.g. an inference provider): you are not the provider of that model, but you are subject to the obligations of distributors and may have host-specific obligations.

The Act adopts a deliberately strict view of "modifications that change provider responsibilities" to avoid loopholes. Article 25 (modification triggers for high-risk systems) has a parallel logic for GPAI: if you substantially modify a GPAI model, you become its provider for the modified version, and you inherit the corresponding obligations.

Baseline obligations for all GPAI providers

Articles 53 and 54 set out the obligations that apply to every GPAI provider. These apply regardless of whether the model is systemic-risk, regardless of whether it is open-source (with carve-outs noted below), and regardless of whether downstream use cases are high-risk.

1. Technical documentation about the model.

Maintain up-to-date technical documentation about the model, including its training and testing process and the results of its evaluation. The minimum content is set out in Annex XI Section 1. It includes: a description of the model's tasks and types of AI systems in which it can be integrated; the model's design specifications including architecture and the number of parameters; the data on which the model was trained, including the type and provenance of data and curation methodologies; computational resources used to train the model; energy consumption.

The documentation must be made available to the European AI Office and to national competent authorities on request.

2. Information for downstream providers.

Provide information and documentation to downstream AI providers who intend to integrate the GPAI model into their AI systems. The minimum content is in Annex XI Section 2. The aim is to enable downstream providers to understand the capabilities and limitations of the model and to comply with their own obligations.

In practice, this is the model card. Anthropic, OpenAI, Meta and Google already publish model cards as marketing artefacts; the Act makes a baseline version legally required.

3. Copyright compliance policy.

Put in place a policy to comply with Union copyright law, in particular to identify and respect, including through state-of-the-art technologies, a reservation of rights expressed pursuant to Article 4(3) of Directive (EU) 2019/790 (the Copyright in the Digital Single Market Directive).

In effect this means: respect machine-readable opt-outs (e.g. robots.txt, the TDM-Reservation header in HTTP responses, or other "do not train on this" signals from rights holders) when scraping training data. The standard the Commission expects is being worked out via the Code of Practice referenced in Article 56.

4. Public summary of training data.

Draw up and make publicly available a sufficiently detailed summary of the content used for training the GPAI model, according to a template provided by the AI Office.

This is the transparency-into-training-data obligation. It is not a full dump of the training corpus — that is not possible in practice and not what the Act asks. It is a structured summary that lets rights holders, researchers and the public see at a useful level what categories and major sources fed into training. The AI Office has published a template.

5. Cooperation with authorities.

Cooperate as necessary with the Commission and national competent authorities in the exercise of their powers under the Act, including providing additional information on request.

Open-source carve-outs

Article 53(2) exempts open-source GPAI providers from the technical-documentation obligation (1) and the downstream-information obligation (2), if:

• the model is released under a free and open-source licence that allows access, use, modification and distribution of the model, and
• the parameters, including weights, the information on the model architecture, and information on usage are publicly available.

The carve-out does not extend to the copyright-compliance policy (3) or the training-data summary (4). Open-source GPAI providers still owe both. The carve-out also does not extend to systemic-risk GPAI obligations (below) — if your open-source model meets the systemic-risk threshold, the full systemic-risk obligations apply regardless of licence.

Additional obligations for systemic-risk GPAI

Some GPAI models are designated as "GPAI models with systemic risk" and face a higher tier of obligations under Article 55. The designation can happen two ways:

Compute threshold. A model is presumed to have high-impact capabilities (and therefore systemic risk) when the cumulative amount of computation used for its training measured in floating-point operations is greater than 10^25. At time of writing this captures the frontier models — GPT-4-class and above — and a steadily growing list of model providers.

Commission designation. The Commission can also designate a model as systemic-risk on the basis of capability indicators, regardless of training compute. The reverse is also true: a model that exceeds the threshold can argue against the designation by showing it does not, in fact, present systemic risks. This is a defined procedure under Article 52.

For a systemic-risk GPAI model, the provider must additionally:

1. Model evaluation, including adversarial testing.

Perform model evaluation in accordance with standardised protocols and tools reflecting the state of the art, including conducting and documenting adversarial testing of the model with a view to identifying and mitigating systemic risks.

2. Systemic-risk assessment and mitigation.

Assess and mitigate possible systemic risks at Union level, including their sources, that may stem from the development, the placing on the market, or the use of the GPAI model with systemic risk. The recitals list examples of systemic risks: misuse for chemical, biological, radiological, or nuclear weapons; loss of control over a model with autonomous capabilities; harmful bias and discrimination at scale; gender-based violence; mis- and disinformation impacting fundamental rights; influence on democratic processes.

3. Tracking, documenting and reporting serious incidents.

Keep track of, document and report, without undue delay, to the AI Office and, as appropriate, to national competent authorities, relevant information about serious incidents and possible corrective measures to address them.

4. Adequate cybersecurity.

Ensure an adequate level of cybersecurity protection for the GPAI model with systemic risk and its physical infrastructure.

Compliance with the Commission-endorsed Code of Practice under Article 56 provides a means of demonstrating compliance with Articles 53 and 55 until harmonised standards are published. The first version of the Code of Practice was finalised in 2025. Providers can either sign the Code or demonstrate compliance through other means.

Downstream integration: what changes for the AI system

If you integrate a GPAI model into your own product and place that product on the market, you become a provider of the downstream AI system, in addition to whatever role the model provider holds. You inherit the risk-tier classification of your downstream use case independently of what the model provider has done. Putting a GPAI model behind a recruitment-screening interface produces a high-risk recruitment screening system; your obligations under Chapter III apply.

The model provider's obligations do not transfer to you. Their model documentation and information-for-downstream-providers gives you what you need to comply with your own obligations (data-governance documentation, capability and limitation disclosures, etc.), but the high-risk provider obligations on your system are yours alone.

This is also true if you fine-tune a third-party GPAI model. You may become a GPAI provider of the new model (if the result is still general-purpose) and a provider of the AI system you build on top of it. Two parallel sets of obligations, both yours.

Timeline

GPAI obligations apply from 2 August 2025 (with a transition for GPAI models placed on the market before that date; they have until 2 August 2027 to fully comply). Systemic-risk obligations apply on the same date for newly placed models, with the same two-year grace for those already on the market on 2 August 2025.

This is the same date Member States must designate competent authorities. The supervisory architecture for GPAI is centralised at the European AI Office, established within the Commission, rather than at the national level — a deliberate choice given that GPAI providers are typically global and their models are deployed across the Union simultaneously.

What to do now if you're a GPAI provider

The compliance baseline is achievable but not trivial. The practical work, in order:

1. Classify the model. Is it GPAI under the Article 3 definition? Is it systemic-risk by compute threshold? If you are at or near 10^25 FLOPs of training compute, assume systemic-risk and prepare for the additional obligations.
2. Write the model card and Annex XI documentation. If you already have an internal model card, the gap is usually structured information on training data, computational resources, energy consumption, and downstream-developer guidance.
3. Adopt or write the copyright-compliance policy. Define how you handle TDM opt-out signals during data collection. Document the data sources you consider clean. Document your process for handling takedown requests for memorised content.
4. Draft the public training-data summary to the AI Office template.
5. For systemic-risk only: implement adversarial testing protocols, set up incident-reporting channels to the AI Office, document your systemic-risk mitigation programme, and review cybersecurity posture against the obligations.
6. Sign or align with the Code of Practice for the relevant period. It is currently the most concrete way to demonstrate compliance.

If you build on top of a GPAI model rather than providing one, your work is in the risk-classification guide for the AI system you are putting on the market. The model provider's obligations don't transfer; yours don't propagate up. They run in parallel.