GPAI: what general-purpose AI obligations mean for you

The EU AI Act creates a whole regime for general-purpose AI (GPAI) models, the large foundation models like GPT, Claude, Gemini, Llama and Mistral that sit underneath most of the AI you actually use. It comes with real obligations: documentation, copyright policies, training-data summaries, model evaluations, incident reporting. If you have seen the headlines, you might reasonably worry this is another compliance burden landing on you.

Here is the reassuring part, and the reframe that matters: for the vast majority of businesses, the GPAI obligations are not yours. They fall on the providers of the models, the labs that build them and place them on the market. If you use GPAI through an API or build a product on top of one, you are a downstream user, not a GPAI-model provider, and you do not carry the model duties. What you need to understand is where the line is, how the rules affect you indirectly, and the one trap, fine-tuning, that can pull the obligations onto your plate. That is what this post covers.

What actually counts as a GPAI model

The Act defines a general-purpose AI model (Article 3(63)) as one trained on large amounts of data using self-supervision at scale, that displays significant generality, can competently perform a wide range of distinct tasks, and can be integrated into downstream systems. In plain terms: the big foundation models. GPT-4, Claude, Gemini, Llama, Mistral are GPAI models; a chatbot or a document tool you build on top of one is a GPAI system.

Two distinctions are worth holding onto:

• Model versus system. The GPAI rules attach to the model. The AI system you build on it is governed by the rest of the Act, including the risk-tier rules for AI systems. A model can be general-purpose while the system you build is high-risk, limited-risk or minimal-risk in its own right.
• GPAI is a separate track. The general-purpose-AI regime runs alongside the Act’s risk tiers, not inside them. A GPAI model is not automatically “high-risk”; it has its own set of obligations aimed at the model layer.

Two tiers: all GPAI, and GPAI with systemic risk

The Act splits GPAI models into two groups.

• All GPAI models carry a baseline set of transparency and copyright duties.
• GPAI models with systemic risk carry those plus a heavier set. A model is presumed to pose systemic risk if the total compute used to train it exceeds 10^25 floating-point operations (FLOPs) (Article 51), a threshold designed to capture the most capable frontier models. The AI Office can also designate a model as systemic-risk on other grounds.

In practice, the systemic-risk tier is a small club of the largest frontier models from the biggest labs. If you are reading this as a normal business, you are not in it, and you are almost certainly not a provider of the baseline tier either.

What the obligations actually are (on the provider)

For completeness, here is what the model makers must do, so you can see what you are relying on them for.

Every GPAI provider (Article 53) must:

• keep up-to-date technical documentation of the model;
• give downstream providers who build on the model the information and documentation they need to comply with their own obligations;
• put in place a policy to comply with EU copyright law, including the text-and-data-mining rules; and
• publish a sufficiently detailed summary of the content used to train the model, using the AI Office’s template.

There is a lighter regime for genuinely open models (Article 53(2)): providers of GPAI models released under a free and open licence are relieved of some of the documentation duties, but not the copyright policy or the training-content summary, and the relief does not apply to systemic-risk models.

Providers of systemic-risk GPAI (Article 55) must additionally:

• perform model evaluation, including adversarial testing (red-teaming);
• assess and mitigate systemic risks the model could pose;
• track, document and report serious incidents to the AI Office and national authorities; and
• ensure adequate cybersecurity of the model and its physical infrastructure.

They also have to notify the AI Office (Article 52) when a model meets the systemic-risk threshold.

The GPAI Code of Practice

Because formal harmonised standards take years to write, the EU AI Office facilitated a voluntary GPAI Code of Practice (Article 56), published in July 2025, that providers can sign up to in order to demonstrate compliance in the meantime. It has three chapters: transparency, copyright, and safety and security. Most of the major model providers signed up to it, with a notable holdout or two. It is voluntary, but for a model maker, adhering to it is the path of least resistance to showing it is meeting the obligations, and it is a useful signal to look for when you choose which models to build on.

Timing and penalties

The GPAI obligations have applied since 2 August 2025. Models already on the market before that date have until 2 August 2027 to come into line, and the AI Office’s enforcement powers for GPAI begin around 2 August 2026. Penalties for GPAI providers can reach the higher of €15 million or 3% of global annual turnover (Article 101).

One point of confusion worth clearing up: these GPAI dates are separate from the high-risk timeline that the EU’s Digital Omnibus package pushed back. The GPAI obligations were already in force from August 2025 and were not the subject of that deferral. We track the full picture in the EU AI Act deadlines.

What it actually means for you

Now the part that matters. Which of these are you?

• A deployer or downstream user (you use ChatGPT, the Claude API, Copilot, or a product built on a foundation model). The GPAI model obligations are not yours. They sit with the model provider. You are governed by the rest of the Act as a deployer of whatever AI system you use or build, which is a separate question. What GPAI gives you is a right to rely on the provider: they must hand you the documentation you need to build compliant systems on their model. So your job is to use that, not to reproduce it.
• A provider of an AI system built on GPAI (you ship a product powered by a foundation model). Still not a GPAI-model provider. Your obligations are those of a system provider under the Act, and you lean on the model provider’s documentation to meet them.
• A fine-tuner or modifier. This is the one to watch. Fine-tuning a model for your own use does not, by itself, make you the provider of a new GPAI model. But if your modification is substantial, you can be treated as the provider of a distinct GPAI model, with the fuller duties that brings. The Commission’s guidance points to a threshold based on how much compute your fine-tuning uses relative to the original training (around a third has been indicated). Below it, you take on obligations only for your modification, if any; above it, you may inherit the lot. If you are fine-tuning open models at scale, get this line checked.

There is also a general rule for AI systems worth knowing: if you put your own name or trademark on a high-risk AI system, or substantially modify one, the provider obligations for that system can shift onto you (Article 25). That is about AI systems rather than GPAI models, but it is the same principle, doing more than just using something off the shelf can move the compliance burden.

What to actually do about it

For a normal business building on GPAI, the practical to-do list is short:

1. Know which models you build on. Put them in your AI system register, model and provider included.
2. Collect the provider’s documentation. You are entitled to it; keep it with the system it supports, because it is what lets you meet your own obligations and answer a customer’s or regulator’s questions.
3. Make GPAI compliance part of vendor selection. When you evaluate an AI vendor, a provider that has signed the Code of Practice and publishes proper model documentation is de-risking your supply chain. One that is opaque is pushing risk onto you.
4. Watch the fine-tuning line. If you move from prompting and light fine-tuning to substantial modification of open models, get advice before you assume you are still just a user.
5. Govern the system, not just the model. Your real obligations are as a deployer or system provider. That is where a working AI Management System earns its place.

The UK angle

The UK has no GPAI-specific law; its approach is principles-based. But the EU rules reach UK businesses two ways. First, a UK model provider whose model is placed on the EU market is caught directly. Second, and far more commonly, UK businesses building on GPAI are affected through the supply chain: the documentation you receive, the models you can safely build on, and what your EU-facing customers demand of you all flow from this regime. You do not need to be in the EU for the GPAI rules to shape the tools you use.

The short version

General-purpose AI models carry a specific set of EU AI Act obligations, but they land on the model makers, not on the businesses that use them. If you deploy GPAI or build products on it, your job is to rely on the provider’s documentation, factor their compliance into how you pick vendors, govern the AI system you actually ship, and keep a careful eye on the one line that can change your status: substantial fine-tuning. Understand which side of that line you are on and the GPAI regime turns from a worry into someone else’s homework, with a short checklist of your own.

Not sure how the EU AI Act applies to what you build? The free EU AI Act check maps your situation to the obligations that actually attach to you, in about ten minutes, no email required. When you want help drawing the lines properly, talk to us.

For the full picture, see the EU AI Act guide.