EU AI Act GPAI Rules: Models, Systemic Risk and Code

by David Porter

Friday, 14 August 2026 at 06:00

thumbnail_eu-ai-act-gpai-rules-models-sy

The EU AI Act regulates general-purpose AI models, or GPAI models, at model level. This is separate from the rules applying to AI systems that use those models.

A company can therefore face two connected compliance layers. The developer of a foundation model may be a GPAI model provider under Chapter V. A different company integrating that model into a recruitment, healthcare or chatbot application may be the provider of a downstream AI system. The downstream system can be high-risk or subject to Article 50 even when the upstream model itself is regulated as GPAI.

The GPAI obligations began applying on August 2, 2025. The Commission’s enforcement powers became applicable in August 2026. Providers of models already on the market before August 2, 2025 have until August 2, 2027 to comply.

For the broader legal map, use our complete EU AI Act guide. For responsibility across the model and application chain, read the providers and deployers guide.

GPAI rules at a glance

Question	Practical answer
What is regulated?	General-purpose AI models capable of performing a wide range of distinct tasks and being integrated into many downstream systems
Is a model the same as an AI system?	No. A model is a component; an AI system uses one or more models and other elements to generate outputs in a specific context
Who has the main duties?	The provider placing the GPAI model on the EU market under its name or trademark
What are the baseline duties?	Technical documentation, downstream information, copyright policy and a public training-content summary
Are open-source models exempt?	Some may be exempt from limited documentation duties, but conditions apply and copyright, summary and systemic-risk rules can remain
What creates systemic-risk duties?	High-impact capabilities, a statutory compute presumption or Commission designation
What additional duties apply?	Evaluations, adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting and cybersecurity
Is the GPAI Code mandatory?	No. It is a voluntary, endorsed route to demonstrate compliance
Who enforces the rules?	The European Commission through the AI Office
What is the maximum GPAI fine?	Up to 3% of worldwide annual turnover or €15 million, whichever is higher, under Article 101

What is a general-purpose AI model?

The Act defines a GPAI model as an AI model—including one trained with large amounts of data using self-supervision at scale—that displays significant generality and can competently perform a wide range of distinct tasks, regardless of how it is placed on the market. It can be integrated into a variety of downstream systems or applications.

Models used for research, development or prototyping before market placement are treated separately from models made available on the market.

The Commission’s GPAI provider guidelines give technical and practical criteria for applying the definition. They are not the Regulation itself, but they state how the Commission intends to interpret and enforce the rules.

Capability matters more than the marketing label

Calling a model “specialized” does not prevent GPAI status if it can perform a broad range of tasks. Conversely, a narrow model designed for one bounded function may fall outside the GPAI definition even if it uses modern generative techniques.

Relevant evidence can include:

the range of tasks evaluated;
modalities supported;
downstream integrations;
model documentation and release materials;
training approach and scale;
actual market use;
and restrictions that genuinely limit capability rather than merely marketing it differently.

A model is not an AI system

This distinction is central.

A model is the learned component that produces capabilities. An AI system combines a model with interfaces, prompts, retrieval, tools, policies, databases, workflows and other components to generate outputs for a particular objective and context.

For example:

a foundation model can be GPAI;
an enterprise assistant built on it is an AI system;
a recruitment-ranking workflow using that assistant may be a high-risk AI system;
and a public-facing chatbot using it may have Article 50 transparency duties.

Chapter V does not replace system-level classification. It supplies information and model-level controls that downstream providers need.

Who is a GPAI model provider?

A provider is the party that develops a GPAI model or has it developed and places it on the market under its own name or trademark.

This can include:

a company releasing model weights;
a company making a model available through an API;
an organization commissioning a model and releasing it under its brand;
and, in some circumstances, a downstream party that makes a significant modification and places the modified model on the market.

The method of distribution is not decisive. A model can be placed on the market through downloads, repositories, APIs, cloud services or other channels, for payment or free of charge.

A company merely using a third-party model is not automatically its provider. It may instead be a deployer of an upstream service and provider of a downstream AI system.

Article 53: baseline obligations for GPAI providers

Article 53 establishes four central duties.

1. Prepare and maintain technical documentation

The provider must draw up and keep technical documentation about the model, including its training and testing process and evaluation results. The required content is connected to Annex XI and must be available to the AI Office and national competent authorities on request.

A practical file can include:

model architecture and parameters;
supported inputs and outputs;
training objectives and methodology;
key design choices;
data acquisition and curation approach;
compute and resources used;
evaluation methods and results;
limitations and known failure modes;
safety and security controls;
version and release history;
and changes after initial market placement.

The document should be operational evidence, not only a model card written for marketing.

2. Give downstream providers enough information

GPAI providers must prepare, maintain and provide information and documentation to providers of AI systems that intend to integrate the model.

The purpose is to let downstream providers understand capabilities and limitations and comply with their own AI Act duties. Useful information can cover:

intended and excluded uses;
input and output modalities;
integration requirements;
evaluation results;
known limitations;
safety mitigations;
recommended monitoring;
cybersecurity considerations;
version changes;
and information needed for system-level technical documentation.

This duty must be balanced with intellectual-property rights and trade secrets, but trade-secret protection is not a reason to provide nothing.

3. Maintain an EU copyright-compliance policy

The provider must put in place a policy to comply with Union copyright and related-rights law. That includes identifying and complying with rights reservations made under the EU text-and-data-mining framework.

A credible policy may address:

lawful data sourcing;
detection and honoring of machine-readable reservations;
dataset and crawler governance;
licensing and opt-out processes;
complaints and rights-holder requests;
memorization and output controls;
and documentation of decisions.

The AI Act does not resolve every copyright dispute about model training. It creates a specific governance obligation alongside the underlying copyright law.

4. Publish a sufficiently detailed training-content summary

Providers must prepare and make publicly available a summary of the content used to train the model, using the template provided by the AI Office.

The summary is not a demand to publish the entire dataset. It is intended to give meaningful information about major data categories and sources while respecting legitimate confidentiality and security interests.

The public summary and the confidential technical documentation serve different audiences and should not be treated as interchangeable.

Open-source GPAI models

The Act creates a limited exemption for certain models released under a free and open-source license that permits access, use, modification and distribution, where model parameters—including weights, architecture information and usage information—are publicly available.

Where the conditions are met, the provider may be exempt from parts of the Article 53 technical-documentation and downstream-information duties. However:

the copyright-policy duty remains;
the public training-content summary remains;
the exemption does not apply to GPAI models with systemic risk;
other laws remain applicable;
and “open source” must satisfy the statutory conditions rather than function as a marketing label.

A provider should document the license, public artifacts and exact obligations it considers exempt. A downstream company should not assume that an open model comes with all evidence needed for its own system-level compliance.

When does fine-tuning create a new provider?

Fine-tuning, continued pretraining, merging, distillation and other modifications do not all have the same legal effect.

The Commission’s GPAI guidelines take a pragmatic approach: actors making significant modifications can become providers of the modified GPAI model, while minor changes need not create the full provider role.

The assessment should consider:

the scale and method of modification;
additional training compute;
change in general capabilities;
newly introduced or removed limitations;
change in systemic risk;
new name or market release;
and whether downstream users reasonably rely on the modifier as provider.

Keep a modification record showing the base model, data, compute, tests, capability changes, safety changes and market event. The company can still be provider of a downstream AI system even when the model modification is not significant enough to make it a GPAI provider.

GPAI models with systemic risk

A subset of GPAI models is classified as having systemic risk because of high-impact capabilities or equivalent impact.

A model is presumed to have high-impact capabilities when the cumulative amount of compute used for its training, measured in floating-point operations, exceeds the statutory threshold of 10²⁵ FLOPs. The Commission can update technical elements through delegated acts and can designate models based on criteria such as capabilities, scale, market reach and access to tools or other systems.

The threshold is a presumption, not the entire test. A provider can submit substantiated arguments that a model exceeding the threshold does not present systemic risk, while the Commission can designate a model below the threshold where the legal criteria support it.

Providers must notify the AI Office when a model meets the relevant condition, within the period required by Article 52. This should be connected to compute tracking and capability evaluation before release—not discovered after a public launch.

Article 55: additional systemic-risk duties

Providers of GPAI models with systemic risk must perform additional controls.

Model evaluations and adversarial testing

Providers must evaluate models using standardized protocols and tools reflecting the state of the art, including adversarial testing. Evaluations should examine relevant capabilities, limitations and misuse pathways.

A mature program separates:

capability evaluation;
safety evaluation;
security testing;
red teaming;
external evaluation where appropriate;
and release-gate decisions.

Systemic-risk assessment and mitigation

Providers must assess and mitigate possible systemic risks at EU level, including sources arising from development, market placement and use.

Risks can include severe effects on public health and safety, fundamental rights, society, democracy, cybersecurity or other domains described by the Act and guidance. The analysis should cover foreseeable downstream use and misuse, not only intended demonstrations.

Serious-incident reporting

Providers must track, document and report relevant serious incidents and possible corrective measures to the AI Office and, where appropriate, national competent authorities.

This requires an operational incident taxonomy, reporting owners, investigation process, evidence preservation and clear handoffs to downstream providers.

Cybersecurity

Adequate cybersecurity protection is required for the model and its physical infrastructure. Controls can include:

secure development and access management;
protection of model weights;
insider-risk controls;
infrastructure hardening;
vulnerability management;
abuse monitoring;
supply-chain security;
and incident response.

Cybersecurity must scale with the model’s capabilities and threat profile.

The General-Purpose AI Code of Practice

The GPAI Code of Practice is a voluntary compliance tool prepared through a multi-stakeholder process and endorsed by the Commission and AI Board as an adequate way to demonstrate compliance.

It contains three chapters:

Transparency—supporting Article 53 documentation and downstream information.
Copyright—supporting the copyright-policy obligation.
Safety and Security—supporting Article 55 duties for systemic-risk models.

Signing the Code does not change the legal text or eliminate enforcement. It provides a structured route, greater predictability and evidence of how the provider intends to meet obligations.

A provider that does not sign can comply through alternative adequate means, but should expect to explain those means to the AI Office in a clear and complete manner.

GPAI timeline

Date	Effect
August 2, 2025	Chapter V obligations began applying to newly placed GPAI models
August 2, 2026	Commission enforcement powers for GPAI became applicable
August 2, 2027	Providers of GPAI models placed on the market before August 2, 2025 must comply

The complete sequence appears in our EU AI Act timeline.

A provider should preserve reliable evidence of the first EU market-placement date and each later model release. “Legacy” status is model-specific; it is not a permanent exemption for a company.

What downstream providers should request

Companies integrating a GPAI model should obtain enough information for system design and classification, including:

model identity and version;
provider and authorized representative;
intended and excluded uses;
modalities and context limits;
evaluation results and known limitations;
safety and security documentation;
prompt and integration guidance;
change and deprecation policy;
incident-notification commitments;
data-processing and retention information;
copyright and output information;
and evidence relevant to high-risk technical documentation.

A “trust us” statement is not a compliance package. Procurement should identify missing evidence and decide whether technical controls, contractual rights or a different model are needed.

Relationship with Article 50

GPAI transparency and Article 50 transparency address different things.

Chapter V concerns the model, its training information, downstream documentation, copyright and systemic risk.
Article 50 concerns certain AI-system interactions and outputs, including chatbot notice, machine-readable marking and deepfake disclosure.

A GPAI model provider may supply technical mechanisms that help downstream system providers mark content. The legal Article 50 duty still attaches to the relevant provider or deployer of the AI system.

Read our Article 50 transparency guide before assuming that a model card or training summary satisfies output-labeling requirements.

Enforcement and fines

The European Commission, through the AI Office, enforces GPAI-provider obligations. It can request documents and information, conduct evaluations, require measures and investigate non-compliance.

Article 101 allows fines for intentional or negligent infringements, failure to provide requested documents or information, non-compliance with required measures or failure to provide model access for evaluation. The ceiling is 3% of annual worldwide turnover or €15 million, whichever is higher.

Maximum fines are not automatic. Enforcement also depends on the facts, gravity, duration, cooperation and corrective action.

A GPAI compliance checklist

Determine status and role

Confirm whether the artifact is a model rather than only a system.
Apply the GPAI definition and Commission criteria.
Identify the legal entity placing it on the EU market.
Record release and legacy dates.
Assess significant modifications and branding.

Build Article 53 evidence

Complete technical documentation.
Prepare downstream-provider information.
Establish an EU copyright-compliance policy.
Publish the training-content summary using the official template.
Appoint an authorized representative where required.

Test systemic risk

Track training compute.
Evaluate high-impact capabilities.
Establish notification triggers.
Document any rebuttal of the statutory presumption.
Monitor Commission designation and delegated acts.

Operationalize Article 55 where applicable

Run state-of-the-art evaluations and adversarial testing.
Maintain a systemic-risk framework.
Create serious-incident reporting.
Protect weights and infrastructure.
Review downstream and misuse risk before release.

Choose a compliance route

Decide whether to sign the GPAI Code.
Map each Code commitment to controls and evidence.
If not signing, document alternative adequate means.
Prepare AI Office submissions through the required channel.

The broader sequence belongs in the EU AI Act compliance checklist.

Common GPAI mistakes

Calling every generative application a GPAI model

A chatbot or business application is usually an AI system. The underlying model may be GPAI.

Treating open source as a complete exemption

The exemption is conditional and limited. Copyright, training-summary and systemic-risk duties can remain.

Ignoring fine-tuning

Significant modification can create a new provider role and change risk.

Giving downstream providers only marketing documentation

They need technical information sufficient for their own compliance and integration decisions.

Treating the compute threshold as the only systemic-risk test

Commission designation and broader capability criteria also matter.

Assuming the Code replaces the law

The Code is a voluntary route to demonstrate compliance, not a separate legal regime.

Frequently asked questions

What does GPAI mean?

GPAI means general-purpose AI. It refers to models with significant generality that can competently perform a wide range of distinct tasks and be integrated into many downstream systems.

Is ChatGPT a GPAI model?

ChatGPT is an AI system or service built on models. The underlying general-purpose models can be GPAI models. The legal object and provider must be identified precisely.

Are all foundation models covered?

Many can be, but the statutory definition and Commission criteria must be applied. Narrow research or pre-market prototypes may be treated differently.

Do GPAI rules apply to non-EU providers?

Yes, where they place GPAI models on the EU market. An EU authorized representative may be required.

Are open-source GPAI models exempt?

Only from certain duties when the detailed license and transparency conditions are met. Systemic-risk models do not receive that exemption.

When do legacy models need to comply?

Models placed on the market before August 2, 2025 must comply by August 2, 2027.

Does fine-tuning always make me a GPAI provider?

No. Significant modification and market placement are central. Minor adaptation may not create the full model-provider role, although system-provider duties can still apply.

What is a GPAI model with systemic risk?

It is a GPAI model with high-impact capabilities or equivalent impact, identified through the statutory presumption or Commission designation.

Is signing the GPAI Code mandatory?

No. Signatories can use it to demonstrate compliance; non-signatories must use alternative adequate means.

Who fines GPAI providers?

The European Commission enforces Chapter V through the AI Office and can impose Article 101 fines.

Bottom line

GPAI compliance is model governance, not a synonym for chatbot labeling. Providers must establish who placed the model on the EU market, produce technical and downstream documentation, operate a copyright policy, publish a training-content summary and test whether systemic-risk duties apply.

Downstream companies should treat that material as an input—not a substitute—for their own system classification, transparency, high-risk and deployment obligations.

byDavid Porter

AI Act Europe Artificial Intelligence

What Is Llama? Meta's AI Models Explained

How to Run DeepSeek Locally: Models, Hardware and Setup

Write a comment