EU AI Act General-Purpose AI (GPAI) Requirements: What Model Providers Need to Know

The EU AI Act invented a regulatory category that earlier drafts of the legislation did not even have a word for: General-Purpose AI (GPAI) models. This is the bucket that holds the big foundation models and the multi-purpose systems that rewired the entire technology industry from 2022 onward. If your organisation builds, fine-tunes, or distributes one of these models, you are now carrying a distinct set of obligations. They are not minor, and they touch both your compliance posture and your day-to-day engineering.

So here is what we are going to do. We will walk through exactly what the Act asks of GPAI model providers: the baseline obligations that apply to every GPAI model, the heavier requirements that kick in once a model is deemed a systemic risk, and the narrow exemptions carved out for open-source releases.

What Qualifies as a General-Purpose AI Model?

The EU AI Act defines a general-purpose AI model in Article 3(63) as an AI model that is trained with a large amount of data using self-supervision at scale, that displays significant generality, and that is capable of competently performing a wide range of distinct tasks regardless of the way the model is placed on the market. This definition is deliberately broad and captures models that can be integrated into a variety of downstream AI systems.

In practical terms, GPAI models include:

• Large language models (LLMs) such as GPT-series models, Claude, Gemini, Llama, and Mistral.
• Multimodal foundation models capable of processing text, images, audio, or video.
• Models that are fine-tuned from a general-purpose base model, where the fine-tuned version retains significant generality.
• Models distributed via API access, download, or embedded within downstream products.

The word that does all the work here is generality. Train a model for one narrow job, say flagging fraudulent credit card transactions, and it usually falls outside the GPAI definition. But build something that can be prompted or adapted to translate, summarise, write code, answer questions, and draft prose? That one is almost certainly in.

If you are not sure where your model lands, do not guess. Run a structured assessment. Our EU AI Act risk assessment guide lays out a framework you can adapt for GPAI classification calls.

Standard Obligations for All GPAI Model Providers (Article 53)

Size does not get you off the hook here. Every GPAI model provider, from the scrappy startup to the frontier lab, must meet a baseline set of obligations under Article 53. These kick in from August 2, 2025, though models already on the market get a transitional window before enforcement fully bites.

Technical Documentation

GPAI model providers must draw up and keep up to date technical documentation of the model, including its training and testing process and the results of its evaluation. This documentation must be sufficiently detailed to allow:

• Downstream providers (those who integrate the GPAI model into their own AI systems) to understand the model's capabilities and limitations.
• Regulatory authorities to assess compliance with the AI Act.
• Third parties conducting conformity assessments to evaluate the model.

The European Commission, in consultation with the AI Office, has published templates and guidelines specifying the minimum content for GPAI technical documentation. At a minimum, documentation should cover:

• A general description of the model, including its architecture, the number of parameters, and the modalities it supports.
• A description of the training process, including training data sources, data curation methodology, and computational resources used.
• Information about the model's intended purpose and reasonably foreseeable uses.
• Performance evaluation results, including benchmarks, known limitations, and failure modes.
• Information about risk mitigation measures taken during development.

Copyright Policy Compliance

Under Article 53(1)(c), GPAI model providers must put in place a policy to comply with Union copyright law, in particular Directive (EU) 2019/790, including the identification and compliance with reservations of rights expressed by rightsholders pursuant to Article 4(3) of that Directive.

This obligation has real teeth. Model providers must:

• Implement technical measures to identify and respect opt-out requests from content creators and publishers.
• Maintain records of training data sources and the steps taken to comply with copyright law.
• Make available a sufficiently detailed summary of the content used for training the GPAI model, following a template provided by the AI Office.

The training data summary is a public-facing document. It must be detailed enough to give a "meaningful understanding" of the data used, without requiring disclosure of trade secrets or proprietary information.

Transparency Obligations

GPAI model providers must make available to downstream providers information that is necessary for them to comply with their own obligations under the AI Act. This includes:

• The technical documentation described above.
• Information necessary for downstream providers to comply with transparency obligations when integrating the GPAI model into AI systems that interact with individuals.
• Information about the model's capabilities and limitations that downstream providers need to conduct their own risk assessments.

This downstream notification requirement builds a chain of accountability. When a downstream provider drops a GPAI model into a high-risk AI system, they need to understand that model well enough to fulfil their own obligations around risk management, data governance, and human oversight. The GPAI model provider has to hand over the information that makes that possible.

Cooperation with Authorities

GPAI model providers must cooperate as necessary with the European Commission, the AI Office, and national competent authorities. That means providing information and documentation upon request, giving authorities access to the model for evaluation purposes, and answering supervisory inquiries promptly.

Systemic Risk: The Elevated Tier

Then there is the deep end. The Act stacks a second, far more demanding tier of obligations on GPAI models that pose systemic risk. A model is presumed to carry systemic risk if it trips either of these conditions:

The Computational Threshold

There is a hard line drawn in compute. A GPAI model is classified as systemic risk when the cumulative computation used to train it, measured in floating point operations (FLOPs), is greater than 10^25 FLOPs. The lawmakers picked that number to catch the most capable models around when the Act was adopted.

As of early 2026, the models clearing that bar are the frontier systems coming out of the major AI laboratories. The Commission can also move the line. It has the power to update the threshold through delegated acts as compute grows and as we all learn more about how compute actually maps to capability.

Commission Designation

Even if a GPAI model does not meet the computational threshold, the Commission may designate it as having systemic risk based on criteria set out in Annex XIII. These criteria include:

• The number of registered end users.
• The number of business users who have integrated the model into their products.
• The model's performance on relevant benchmarks, including measures of general capability.
• The number of parameters.
• The amount and diversity of training data.
• Any other factor the Commission considers relevant to assessing the potential for systemic impact.

This designation power gives the Commission flexibility to capture models that may pose systemic risk despite falling below the computational threshold, for example because of unusually broad deployment or because of capabilities that emerge at lower compute levels.

Additional Obligations for Systemic Risk Models (Article 55)

If your model lands in the systemic-risk tier, the baseline does not go away. You still owe everything under Article 53, and then Article 55 piles a further set of requirements on top.

Model Evaluation

Providers must perform state-of-the-art model evaluations, including adversarial testing (red-teaming), to identify and mitigate systemic risks. These evaluations must assess:

• The model's potential to generate content that could enable harm, including biological, chemical, radiological, nuclear, or cyber threats.
• The model's susceptibility to manipulation, jailbreaking, or prompt injection.
• The accuracy and reliability of the model's outputs across different contexts.
• The model's potential for unintended emergent capabilities.

Evaluations run throughout the model's lifecycle, not just at the point of release. Update the model, fine-tune it, or deploy it in a new context, and you evaluate again.

Red-Teaming

Red-teaming is explicitly required for systemic risk models. This goes beyond standard quality assurance testing. Red-teaming involves adversarial testing designed to probe the model's safety guardrails, identify potential failure modes, and assess the model's resilience to deliberate misuse.

The AI Office may issue specific guidance on red-teaming methodologies, and providers should be prepared to demonstrate that their red-teaming processes are thorough, well-documented, and run by people with real expertise.

Cybersecurity Requirements

Providers of systemic risk models must ensure an adequate level of cybersecurity protection for the model and its physical infrastructure. This includes:

• Protecting model weights, training data, and inference infrastructure from unauthorized access.
• Implementing access controls and audit trails for model interaction.
• Monitoring for and responding to security incidents that could compromise the model's integrity or availability.

Incident Reporting

Providers must track, document, and report serious incidents to the AI Office and, where appropriate, to national competent authorities. A serious incident includes any event that results in or could result in serious harm to individuals, critical infrastructure, or the environment, or that reveals a previously unknown systemic risk.

Energy Consumption Reporting

Providers must document and report the energy consumption of the model during training and, where practicable, during inference. The EU wants those numbers on record, partly for its sustainability objectives and partly because future rules on the environmental impact of AI may build on them.

Codes of Practice

The EU AI Act leans on codes of practice to make GPAI compliance more workable in the real world. The AI Office has been pulling stakeholders together to draft these codes, and they are meant to give you practical guidance on:

• How to prepare technical documentation that meets the Act's requirements.
• Best practices for copyright compliance in training data curation.
• Methodologies for model evaluation and red-teaming.
• Approaches to cybersecurity risk management for GPAI models.

While codes of practice are voluntary, adherence to an approved code of practice can serve as a presumption of conformity with the relevant provisions of the AI Act. Providers that choose not to follow a code of practice must demonstrate equivalent compliance through alternative means.

Open-Source GPAI: Exemptions and Their Limits

Open-source gets a break here, but only a partial one. The EU AI Act carves out a limited exemption for GPAI models released under free and open-source licences. Under Article 53(2), providers of these models are excused from a couple of obligations, specifically the technical documentation and downstream notification requirements, as long as:

• The model's parameters (weights) are made publicly available.
• The model's architecture and usage information is publicly accessible.
• The model is released under a licence that permits access, use, modification, and distribution.

Read the fine print, though, because this exemption has real limits:

• Copyright compliance is not exempted: Even open-source GPAI model providers must comply with copyright law and make available a training data summary.
• Systemic risk obligations override the exemption: If an open-source GPAI model meets the systemic risk threshold (10^25 FLOPs or Commission designation), the provider must comply with all obligations under both Article 53 and Article 55, regardless of the open-source nature of the release.
• The exemption does not protect downstream deployers: Organisations that integrate an open-source GPAI model into a high-risk AI system remain fully subject to the Act's requirements for high-risk systems. The open-source exemption applies only to the model provider's obligations, not to the obligations of those who use the model.

So if you are deploying open-source models in sensitive territory, think healthcare, law enforcement, or financial services, the open-source exemption will not shield you. You still have to run your own risk assessments, keep your own documentation, and stand up every required safeguard. For a full checklist of what applies, see our EU AI Act Compliance Checklist.

Enforcement and Penalties

The AI Office is the body that enforces GPAI obligations, and the numbers are serious. Break a GPAI-specific requirement and penalties can climb to 15 million EUR or 3% of global annual turnover, whichever is higher. Feed the AI Office incorrect, incomplete, or misleading information and you are looking at fines of up to 7.5 million EUR or 1% of turnover.

These sit apart from the fines tied to high-risk AI system violations, and the two can land at the same time if a provider is in breach of both GPAI obligations and high-risk requirements. For the full picture of how enforcement plays out, see our guide on EU AI Act fines and enforcement.

Practical Steps for GPAI Model Providers

If you build or distribute GPAI models, here is where we would start:

1. Classify your model: Determine whether your AI model meets the definition of a GPAI model under Article 3(63), and whether it exceeds the systemic risk threshold of 10^25 FLOPs.

2. Prepare technical documentation: Begin drafting complete documentation that covers architecture, training data, evaluation results, and known limitations. Use the AI Office's templates as a starting point.

3. Implement copyright compliance: Develop or enhance your data curation pipeline to identify and respect copyright opt-out requests. Prepare a training data summary for public release.

4. Establish downstream communication channels: Create processes for sharing required information with downstream providers who integrate your model into their own AI systems.

5. If systemic risk applies, implement additional safeguards: Set up model evaluation, red-teaming, cybersecurity, and incident reporting programmes that meet Article 55 requirements.

6. Engage with codes of practice: Participate in or monitor the development of codes of practice coordinated by the AI Office, and assess whether adherence to an approved code is the most efficient path to compliance.

7. Build compliance monitoring capabilities: Establish ongoing monitoring to track regulatory developments, respond to supervisory requests, and update documentation as your model evolves.

The GPAI provisions mark a real shift in how foundation models get regulated, and there is no quiet corner of the market left to hide in. The providers who build their compliance footing now are the ones who will keep selling into the EU without drama, and who will win the downstream customers who care that a model is reliable, well-documented, and genuinely transparent. Start early. The work compounds in your favour.

Start Your Free Compliance Assessment

Still weighing which tools can carry the load? Our comparison of the best EU AI Act compliance tools breaks down the options in detail. And if you want to understand what the Act bans outright, no documentation or safeguard can buy your way back in, read our guide to EU AI Act prohibited practices.

Update: Where the Digital Omnibus Stands (June 12, 2026)

A quick note before you act on any date in this article. The Digital Omnibus is a simplification package the European Commission proposed on November 19, 2025. It would amend several EU digital laws at once, and for the AI Act it proposes two big changes: the high-risk obligations would apply later (December 2, 2027 for the stand-alone high-risk systems listed in Annex III, and August 2, 2028 for high-risk AI embedded in regulated products), and a number of requirements would be simplified along the way.

Here is the part that matters: none of this is law yet. The European Parliament and the Council reached a provisional agreement on May 7, 2026, and formal adoption is expected, but until the final text is adopted and published, nothing changes. The dates and obligations described in this article are the ones in force today. And the rules that already apply, like the prohibited practices and the AI literacy duty, stay exactly where they are no matter what happens to the Omnibus.

We are watching this closely. The moment the Omnibus is adopted, amended, or rejected, we will update this article to reflect the new EU AI compliance dates. Check back, or run the free 90-second risk check to see your obligations under the rules as they stand right now.