General Purpose AI (GPAI) Obligations: Rules for Foundation Models & LLMs
General Purpose AI (GPAI) Obligations: Rules for Foundation Models & LLMs

General Purpose AI (GPAI) Obligations: Rules for Foundation Models & LLMs

GPAI & Foundation Models · 12 min read · Updated March 2026

The EU AI Act introduced an entirely new regulatory category that did not exist in earlier drafts: General Purpose AI (GPAI) models — also known as foundation models, large language models, or frontier AI models. Chapter V of the Act (Articles 51–56) imposes a standalone set of obligations on GPAI model providers that apply regardless of whether or how those models are used in downstream applications. If you build, fine-tune, or distribute a GPAI model in the EU market, this guide covers everything you need to know.

Key Takeaways
  • GPAI obligations apply to model providers — not to the businesses that build applications on top of GPAI models. Downstream deployers have separate but lighter obligations.
  • All GPAI providers must meet baseline transparency and copyright obligations. Providers of systemic risk models (above 10²⁵ FLOPs) face significantly more demanding additional requirements.
  • The GPAI Code of Practice, published by the EU AI Office in 2025, provides a detailed implementation framework. Signing and following the Code creates a presumption of compliance.
  • GPAI obligations are enforced directly by the EU AI Office — not national authorities — meaning global providers face a single, centrally coordinated regulator.

1. What Is a “General Purpose AI Model” Under the EU AI Act?

Article 3(63) of the EU AI Act defines a GPAI model as “an AI model, including where such an AI model is 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 regardless of the way the model is placed on the market and that can be integrated into a variety of downstream systems or applications.”

In plain language: a GPAI model is one that was trained to do many things, not one specific task. The defining characteristic is significant generality — the ability to perform competently across diverse tasks from a single underlying model. This distinguishes GPAI models from narrow task-specific AI systems (a sentiment classifier, a fraud detector, a medical image analyser) which are purpose-built for one domain.

✅ GPAI Models (Examples)
  • GPT-4, GPT-4o, o1, o3 (OpenAI)
  • Claude 3 family (Anthropic)
  • Gemini 1.5 Pro, Ultra (Google DeepMind)
  • Llama 3, Llama 3.1 (Meta)
  • Mistral Large, Mixtral (Mistral AI)
  • Command R+ (Cohere)
  • DALL-E 3, Sora, Stable Diffusion XL
❌ Not GPAI Models
  • Fraud detection models (single task)
  • Medical diagnostic AI for one condition
  • Credit scoring models
  • CV ranking algorithms
  • Recommendation engines for one platform
  • Narrow NLP classifiers (sentiment, spam)
  • Speech-to-text for one language domain
What about fine-tuned models? A company that takes a GPAI model (e.g. Llama 3) and fine-tunes it for a specific use case (e.g. legal contract review) creates a downstream application, not a new GPAI model — provided the fine-tuning does not introduce new general capabilities. However, if the fine-tuned version retains broad general capability across many tasks, it may still qualify as a GPAI model, and the fine-tuner may become a GPAI provider. This distinction will be clarified in EU AI Office guidance — monitor developments closely.

2. Who Is a GPAI Model Provider?

Article 3(3) defines a provider as any person who develops a GPAI model and places it on the market. Critically for GPAI, this includes:

Commercial API providers — OpenAI, Anthropic, Google, Mistral, Cohere and others providing GPAI model access via commercial API. These are providers regardless of where they are headquartered — if they serve EU customers, EU AI Act applies.
Open-source model releasers — Companies and individuals releasing GPAI model weights publicly (e.g. Meta’s Llama releases, Mistral’s open releases, Stability AI). These are providers unless the open-source exception applies (see Section 7).
Companies that integrate GPAI into their own products — If you deploy a GPAI model as part of your product offering and the GPAI’s general capabilities remain accessible to end users (rather than being constrained to a specific narrow task), you may be a GPAI provider as well as an application deployer.
Not a GPAI provider: A company that builds a product using a GPAI API (ChatGPT, Claude, Gemini) and constrains it to specific tasks through system prompting, retrieval-augmented generation, or architectural guardrails — this company is an application provider or deployer, not a GPAI model provider. The underlying GPAI model provider carries the GPAI obligations; the application builder carries standard AI Act obligations for their application.

3. Baseline Obligations for All GPAI Providers (Articles 53–54)

Every GPAI model provider — regardless of model size, compute used, or whether it is open or closed source — must meet the baseline obligations of Article 53. These apply from 2 August 2025 (one year before the general high-risk AI deadline).

Art. 53(1)(a)
Technical Documentation

Draw up technical documentation covering: information required by Annex XI (training methodology, training data, compute used, model architecture, capabilities and limitations, evaluation results) and Annex XII (for models made available to downstream providers — summary of capabilities, limitations, and any safeguards applied).

Annex XI is the GPAI equivalent of Annex IV (used for high-risk AI systems) — a comprehensive technical dossier covering training, data, architecture, and evaluation. Unlike Annex IV, Annex XI documentation is shared with downstream providers, not just held internally.
Art. 53(1)(b)
Information Provision to Downstream Providers

GPAI providers must make available to downstream providers (those building applications on the model) sufficient information about the model’s capabilities, limitations, and applicable safeguards to enable those providers to fulfil their own EU AI Act compliance obligations. This creates a compliance supply chain: a downstream high-risk AI application provider cannot meet their Annex IV requirements without adequate information from their GPAI model provider.

Art. 53(1)(c)
Copyright Compliance Policy

Implement and make publicly available a policy for complying with EU copyright law — in particular the Text and Data Mining (TDM) exceptions in Articles 3 and 4 of the DSM Directive. This must address: how training data was collected, how opt-out signals were identified and respected, and what the provider’s approach is to rights holders who request removal of their content from future training runs. The CJEU’s pending ruling on LLM copyright will directly affect what this policy must say in practice.

Art. 53(1)(d)
Training Data Summary Publication

Publish a sufficiently detailed summary of the content used for training the GPAI model — covering the types of data, sources, and geographic or temporal scope. The summary must be published in a machine-readable format. This is distinct from the full Annex XI documentation: the summary is public-facing; the full technical documentation is held internally and shared with the EU AI Office on request.

Art. 54
Documentation Retention

Retain technical documentation for 10 years from the date the GPAI model was placed on the market. For continuously updated models (where the model is re-trained or updated on an ongoing basis), the clock restarts from the last material update. Determine and document your version management approach — what constitutes a new model version vs. a new model for documentation purposes.

4. Systemic Risk Models: The Additional Obligations (Article 55)

A subset of GPAI models are designated as having “systemic risk” — those with the highest computational power and therefore the greatest potential for large-scale, hard-to-predict harm. These models face significantly more demanding requirements under Article 55.

The Systemic Risk Threshold — Article 51

Training compute > 10²⁵ floating point operations (FLOPs)

A GPAI model trained using more than 10²⁵ FLOPs is presumptively classified as having systemic risk. As of early 2026, models known to exceed or be at this threshold include: GPT-4, Gemini Ultra, Claude 3 Opus, and the largest Llama 3 variants. The Commission may update this threshold via delegated acts. Models below the threshold can also be designated systemic if the EU AI Office determines they meet systemic risk criteria through capability evaluation.

Additional ObligationArticleWhat it requires
Adversarial Testing & Red-Teaming55(1)(a)Conduct model evaluation, including adversarial testing (“red-teaming”), to identify and mitigate systemic risks before and after release. Evaluation must cover: CBRN risk facilitation, large-scale disinformation capability, autonomous harmful action capability, and cybersecurity attack capability.
Incident Reporting55(1)(b)Report serious incidents and possible corrective measures to the EU AI Office within defined timeframes. A serious incident for a systemic risk GPAI includes: discovered CBRN facilitation capability, large-scale cyberattack facilitation, evidence of autonomous harmful multi-step action, or significant harm to individuals arising from model outputs.
Cybersecurity Measures55(1)(c)Implement cybersecurity protections appropriate to the systemic risk level — including protecting model weights from unauthorised access or exfiltration, securing training infrastructure, and monitoring for attempts to extract or replicate the model through adversarial querying.
Energy Efficiency Reporting55(1)(d)Report energy consumption data to the EU AI Office where requested. The Commission is developing standardised methodologies for measuring GPAI model energy use — systemic risk providers must be able to report against these when requested.

5. The GPAI Code of Practice: What It Covers and Why It Matters

The EU AI Office developed the GPAI Code of Practice in close consultation with major GPAI providers, researchers, and civil society throughout 2024–2025. The Code translates the high-level obligations of Articles 53–55 into practical implementation guidance with specific, measurable commitments.

Why signing matters: Under Article 56, adherence to the Code of Practice creates a presumption of compliance with the corresponding Chapter V obligations. This does not eliminate enforcement oversight — the EU AI Office retains audit powers — but it significantly reduces regulatory risk and demonstrates proactive good faith to regulators. GPAI providers that have not signed the Code face greater scrutiny and have no presumption of compliance to rely on.

What the Code covers (baseline tier)
  • Model documentation templates aligned with Annex XI
  • Training data summary format and publication standards
  • Copyright compliance policy minimum requirements
  • Information disclosure standards for downstream providers
  • Transparency and model cards publication requirements
What the Code covers (systemic risk tier)
  • Red-teaming methodology and scope requirements
  • Evaluation benchmarks for systemic risk capabilities
  • Model safety policy publication standards
  • Incident classification and reporting procedures
  • Cybersecurity baseline controls for model weights
  • Energy consumption measurement methodology
Who has signed the Code of Practice?
As of March 2026, the following organisations have publicly committed to the GPAI Code of Practice: OpenAI, Google DeepMind, Anthropic, Meta, Mistral AI, Cohere, Stability AI, and several major European AI research institutes. Microsoft, Amazon, and Apple have engaged with the process as downstream deployers rather than GPAI model providers. Notably, some smaller open-source model providers have struggled to engage with the Code given the significant documentation and evaluation requirements it imposes — this is an area of ongoing policy discussion at the EU AI Office.

6. What GPAI Obligations Mean for Downstream Application Builders

If you build applications on top of GPAI models (using GPT-4, Claude, Gemini, or Llama via API), you are not a GPAI model provider — you are a downstream application provider or deployer. You do not carry the Chapter V obligations. However, GPAI obligations affect you indirectly in three important ways:

Your high-risk AI compliance depends on your GPAI vendor’s documentation
If you build a high-risk AI application on a GPAI model (e.g. an HR screening tool built on GPT-4), your Annex IV technical documentation must include information about the underlying model’s capabilities, limitations, training data, and safeguards. Article 53(1)(b) requires GPAI providers to give you this information. If your GPAI vendor cannot provide adequate documentation — because they haven’t complied with their own Article 53 obligations — you cannot complete your Annex IV file. Your vendor’s compliance is literally a precondition for your compliance.
GPAI-powered applications may still be high-risk under Annex III
Using a GPAI model as your underlying engine does not change the risk classification of your application. An HR screening tool built on Claude is a high-risk AI system under Annex III, Category 4 — regardless of the fact that Claude itself is a GPAI model governed by Chapter V. The application’s risk classification is determined by its purpose and context, not the technology stack underneath it.
Significant modification may reclassify you as a GPAI provider
Article 25 addresses reclassification: if you substantially modify a GPAI model — including through significant fine-tuning that expands its capabilities or changes its behaviour materially — you may become a GPAI model provider in your own right. If your organisation undertakes substantial fine-tuning of foundation models, seek legal advice on whether this triggers GPAI provider obligations.

7. The Open-Source Exception: What It Covers and Its Limits

Article 53(2) provides a significant (but not unlimited) exemption for GPAI models released under open-source licences. GPAI providers who make model weights and parameters freely available under an open-source licence may benefit from a reduced obligation set — specifically, they are exempt from the documentation requirements of Article 53(1)(a) and (b).

What open-source providers are still required to do:

The copyright compliance policy obligation (Art. 53(1)(c)) still applies — even for open-source models
The training data summary publication obligation (Art. 53(1)(d)) still applies
The open-source exception does NOT apply to systemic risk models — even open-source GPAI models above the 10²⁵ FLOPs threshold must meet all Article 55 systemic risk obligations. The open-source exception is unavailable for the most capable models regardless of their licence.
💡
The open-source exception controversy: The exception was hard-fought in negotiations, with Meta and the open-source AI community arguing that open-source models cannot practically comply with full documentation requirements since there is no centralised entity controlling downstream use. Critics (including many civil society organisations) argued the exception creates a safety gap. Watch the EU AI Office for guidance on how the exception is interpreted in enforcement — it is widely expected to be applied narrowly.

8. Enforcement: The EU AI Office’s Direct Jurisdiction

Unlike high-risk AI enforcement — which sits primarily with National Market Surveillance Authorities — GPAI enforcement is centralised at the EU AI Office. This means:

🌍 Global reach
The EU AI Office can investigate and impose penalties on GPAI providers regardless of where they are headquartered — a US, UK, or UAE-based foundation model company is subject to the same enforcement as a European one.
📋 Information requests
The EU AI Office can request documentation, access to models, evaluation cooperation, and explanations of model behaviour from any GPAI provider. Non-compliance with information requests is itself an infringement.
🔬 Scientific Panel evaluations
For systemic risk models, the EU AI Office can commission the Scientific Panel to conduct independent evaluations — including red-teaming exercises — of GPAI model capabilities. Providers must cooperate with these evaluations.
💸 Penalties
GPAI violations attract fines of up to €15M or 3% of global turnover for most violations; up to €35M or 7% of global turnover for systemic risk model violations involving Article 55 obligations. See our penalties guide for full details.
Understand your full GPAI obligations
Our EU AI Act Summary covers the full GPAI chapter in depth — including the Code of Practice, systemic risk designation process, and the copyright compliance requirements shaped by the current CJEU litigation.
Read EU AI Act Summary →

9. Frequently Asked Questions

We use GPT-4 via API to build our application. Are we a GPAI provider? +
No. Using a GPAI model via API makes you a downstream application provider or deployer — not a GPAI model provider. OpenAI is the GPAI model provider for GPT-4 and carries the Chapter V obligations. Your obligations depend on what you build with it — if your application is high-risk under Annex III, you carry Provider or Deployer obligations under Chapters III and IV. If your application is limited risk or minimal risk, you carry only the relevant lighter obligations.
We fine-tuned Llama 3 on our proprietary dataset. Are we now a GPAI provider? +
Possibly — it depends on the nature and extent of the fine-tuning. If you fine-tuned for a specific, constrained task (e.g. answering questions about your company’s products) and the fine-tuned model does not retain broad general capabilities, you are likely a downstream application provider, not a GPAI provider. If your fine-tuning was substantial, changed the model’s behaviour significantly across many tasks, or if you are making the fine-tuned model available to other developers, you may be a GPAI model provider. Article 25 reclassification applies. Seek specific legal advice on your fine-tuning approach before August 2026.
When did GPAI obligations start applying? +
GPAI model provider obligations under Articles 53–55 applied from 2 August 2025 — one year before the general high-risk AI deadline of August 2026. This means GPAI providers were already required to meet baseline obligations (documentation, copyright policy, training data summary) from August 2025 onwards. If your organisation is a GPAI provider that has not yet addressed these obligations, you are already in a period of non-compliance and should take immediate action.
How does the EU AI Office decide if a model has systemic risk? +
Article 51 establishes two routes to systemic risk designation: (1) Automatic presumption for models trained above 10²⁵ FLOPs — providers self-assess and report to the EU AI Office. (2) EU AI Office designation for models below the compute threshold based on capability evaluation — the Office can designate a model as systemic risk if it determines, based on evaluations by the Scientific Panel, that it has capabilities posing systemic risks regardless of the compute used in training. Providers can challenge a designation through a formal review process. The EU AI Office publishes a list of models it has assessed and designated.
Leave a Reply

Your email address will not be published. Required fields are marked *

You May Also Like