What Is a GPAI Model?
A GPAI model is a general-purpose AI model under Article 3 of the EU AI Act – a model trained broadly that can be used for many different tasks. The vendor that builds the model carries the GPAI obligations in the regulation's Chapter V. That responsibility doesn't automatically transfer when you buy access to the model.
When the EU AI Act comes up, the term GPAI shows up quickly, often without being explained. It’s worth sorting out, since it determines who carries which responsibility when you build on a large AI model. The short answer: most of the burden sits with whoever built the model, not with you as the user – but you have your own responsibility that’s easy to miss.
What GPAI Means
GPAI stands for general-purpose AI, and it’s defined in Article 3 of the EU AI Act. It’s a model trained broadly on large datasets that can be used for many different tasks – writing text, summarizing, classifying, coding, and much more – rather than a model built for a single narrow function.
The large language models behind services like Copilot are typical GPAI models. The point of the category is that the regulation places special obligations specifically on whoever builds and supplies such a model, since it becomes a building block in a great many downstream applications.
The Division of Roles: Builder vs. User
This is the core of it, and the part that’s most often misunderstood. Responsibility is split between two roles.
The model builder – the vendor – carries the GPAI obligations in the regulation’s Chapter V. These include, among other things, technical documentation, information for downstream developers, and a copyright policy. These obligations have applied since August 2, 2025.
You, using the model in your business, are instead the deployer under Article 26. Your burden concerns how you use the system: human oversight, following the vendor’s instructions, and not taking the system outside its intended purpose. The key thing to understand is that the vendor’s GPAI burden doesn’t transfer when you buy access – but your own deployer responsibility comes with it. Two different roles, two different areas of responsibility.
The Sanctions Logic
Who pays if something goes wrong at the model level? Here too, the answer is split. Under Article 101, a GPAI provider that breaches the regulation can be fined up to EUR 15 million or 3 percent of global annual turnover, whichever amount is higher.
That penalty hits the vendor, not the customer. A breach of the GPAI obligations is the vendor’s responsibility, and it’s the vendor that risks the fine. That doesn’t mean you’re free of all responsibility – your deployer responsibility under Article 26 has its own rules – but the burden for the model’s own compliance isn’t on your desk.
Systemic Risk and the Unclear Classification
A subset of GPAI models are classified as models with systemic risk. The threshold is based on how much compute power went into training: if a model crosses a certain level, it’s judged capable of especially significant societal impact and then faces stricter requirements.
The problem in practice is that official classification can be missing or delayed for a specific model. That leaves you without word on which requirement level applies. A concrete scenario: you want to build on one of the very largest models but find no clear classification. The pragmatic stance is to treat a frontier model as likely GPAI with systemic risk until the classification is settled. If you build your documentation for the higher requirement from the start, you avoid retrofitting it later if the assessment ends up landing strict.
Who the GPAI Providers Are in Your Stack
To make it concrete: in a Copilot or Foundry stack, the GPAI providers are whoever builds the underlying foundation models. That’s OpenAI, Anthropic, Google, and Mistral for their respective models, and Microsoft for its own. The same company can appear in several roles – both as model builder and as the platform running the model – but the GPAI obligations attach to the role of having built the model.
For you as a buyer, that means two things. Map out who’s the model builder behind each service you use, so you know where the Chapter V responsibility sits. And keep track of your own deployer responsibility under Article 26, since that’s your part regardless of how responsible the vendor is. Want help sorting out the roles in a specific AI solution? Read more about our work with AI or get in touch.
Frequently asked questions
Who's responsible for a GPAI model – us or the vendor?
The foundation is split. The model builder carries the GPAI obligations in Chapter V, which have applied since August 2, 2025. You, as the one using the model in your business, are instead the deployer under Article 26. The vendor's burden therefore doesn't transfer when you buy access – but your own deployer responsibility comes with it.
What happens if the GPAI provider breaks the rules?
The penalty hits the provider, not the customer. Under Article 101, a GPAI provider that breaches the regulation can be fined up to EUR 15 million or 3 percent of global annual turnover, whichever is higher. That burden is carried by whoever built and supplies the model.
What is a GPAI model with systemic risk?
It's a GPAI model that crosses a threshold in training compute and is therefore judged capable of especially significant impact. Such models face stricter requirements. The threshold is based on how much compute went into training, and official classification for a specific model can be delayed or simply missing.
Who are the GPAI providers in practice?
In a Copilot or Foundry stack, it's whoever builds the underlying foundation models: OpenAI, Anthropic, Google, and Mistral for their respective models, and Microsoft for its own. The same company can be both model builder and platform provider, but the GPAI obligations attach to the role of building the model.
How should we handle a model whose classification is unclear?
Treat it cautiously. When official classification is missing, the pragmatic stance is to treat a frontier model as likely GPAI with systemic risk until the classification is settled. That way you build your documentation for the higher requirement from the start, instead of having to retrofit it later if the classification lands strict.