GPAI, Provider or Deployer? Your EU AI Act Roles
Map your EU AI Act obligations by role. A practitioner guide to GPAI, provider vs deployer duties, and what changes on 2 August 2026.
The most expensive mistake we see in EU AI Act readiness programmes is not a missed control. It is a misclassified role. Teams pour weeks into building technical documentation for a system where they are merely the deployer, while quietly assuming someone upstream owns the conformity assessment for a model they have actually fine-tuned into a new high-risk system. The obligations follow the role. Get the role wrong and every downstream decision inherits the error.
This post is a practitioner's map. It explains what separates a GPAI provider, a system provider, and a deployer, how those roles stack, and which obligations attach to each as the high-risk regime goes live on 2 August 2026.
TL;DR / Key takeaways
- Your obligations are determined by your role, not by the technology. The same model can make one company a provider and another a deployer.
- Provider is the heavy role. Providers of high-risk systems own conformity assessment, EU database registration, technical documentation, and post-market monitoring.
- Deployers carry real, enforceable duties too — human oversight, monitoring, input-data relevance, logging, and in some cases a fundamental rights impact assessment.
- GPAI model obligations already apply (since 2 August 2025); Annex III high-risk obligations apply from 2 August 2026. Models on the market before August 2025 have until 2 August 2027.
- You can be both at once. Fine-tuning, rebranding, or substantially modifying a high-risk system makes you its provider while you remain its deployer.
The four questions that fix your role
Before any control work, answer four questions for every system and model in your estate. We run this as the first workshop in every Act readiness engagement, because it reframes the entire scope.
- Do you place the system on the market or put it into service under your own name or trademark? If yes, you are a provider.
- Do you use the system under your own authority in a professional setting? If yes, you are a deployer.
- Have you substantially modified a high-risk system, or changed its intended purpose so it becomes high-risk? If yes, you become the provider of that modified system — even if you bought it from someone else.
- Are you supplying a general-purpose AI model that others build on? If yes, the GPAI provider rules apply on top of everything else.
These are not mutually exclusive. A bank that licenses a credit-scoring engine, retrains it on its own portfolio, and rebrands the output is simultaneously a deployer of the original and a provider of the modified system. For a deeper treatment of when a system lands in the high-risk bucket, see our guide to Annex III high-risk classification.
Provider vs deployer: the obligation split
The cleanest way to internalise the difference is to put the duties side by side. The table below covers high-risk AI systems, where the gap between the roles is widest.
| Obligation | Provider | Deployer |
|---|---|---|
| Risk management system | Establishes and maintains it | Operates within its bounds |
| Technical documentation | Authors and keeps current | Retains and references |
| Conformity assessment | Performs before market entry | Not required |
| EU database registration | Registers the system | Public-body deployers register their use |
| CE marking and Declaration of Conformity | Issues both | Verifies they exist |
| Human oversight | Designs the capability in | Assigns competent humans to exercise it |
| Data governance | Ensures training/validation quality | Ensures input data is relevant for the purpose |
| Logging | Enables automatic logs | Keeps logs for the required period |
| Post-market monitoring | Runs the monitoring system | Monitors operation, reports malfunctions |
| Fundamental rights impact assessment | Not generally required | Required for public bodies and certain deployers |
| Incident reporting | Reports serious incidents to authorities | Informs the provider and, where set, authorities |
The asymmetry is deliberate. The provider knows how the system was built and is best placed to certify it. The deployer knows how it is used in the real world and is best placed to catch harm in operation. Both roles are load-bearing; neither can carry the other's weight.
GPAI providers: a third, distinct layer
General-purpose AI models sit underneath this provider/deployer split as their own regulatory layer. A GPAI provider — the organisation that develops and places the model on the market — owes a specific set of duties that have applied since 2 August 2025:
- Maintain up-to-date technical documentation for the model.
- Publish a sufficiently detailed summary of the training content.
- Put a policy in place to comply with EU copyright law.
- Provide downstream system providers the information they need to integrate the model and meet their own obligations.
Models classified as having systemic risk carry more: model evaluation, adversarial testing, systemic-risk assessment and mitigation, and serious-incident reporting. Crucially, GPAI models already on the market before 2 August 2025 are not exempt — they must reach full compliance by 2 August 2027.
For most enterprises, the practical consequence is downstream. If you build on a foundation model, your ability to discharge your own provider or deployer duties depends on documentation flowing down the supply chain. Where it does not flow, you have a contractual gap, not just a technical one. We have repeatedly found that the binding constraint on a client's compliance is a vendor clause, not an engineering task.
Where the roles collide: substantial modification
The single most under-appreciated rule is substantial modification. If you take a high-risk system and materially change it — or repurpose any system so that it newly falls into a high-risk category — you step into the provider's shoes for that system. The original provider's conformity assessment no longer covers you for the part you changed.
In practice this catches three common patterns:
- Fine-tuning a third-party model on your own data for a regulated use case.
- Rebranding a vendor system and putting it on the market under your own name.
- Repurposing a general tool into a decision system that affects access to employment, credit, or essential services.
If any of these describe your roadmap, budget for full provider obligations, including a conformity assessment. Our conformity assessment guide walks through the route options and the evidence each one demands.
What actually changes on 2 August 2026
The GPAI clock started in 2025. The high-risk clock strikes on 2 August 2026, when Annex III systems become subject to their full obligation set: conformity assessment, EU database registration, complete technical documentation, post-market monitoring, and demonstrable human oversight.
The enforcement teeth are real. Prohibited practices draw fines up to EUR 35 million or 7 percent of global annual turnover. High-risk non-compliance draws up to EUR 15 million or 3 percent. These are turnover-based ceilings, which means they scale with the size of the organisation that gets it wrong.
A defensible 2026 posture is not a binder of policies. It is a live system: documentation that tracks the build, logs that capture operation, monitoring that surfaces drift, and named humans who can intervene. For a sequenced, date-driven plan, use our August 2026 readiness checklist.
A pragmatic operating model
The teams that handle this well stop treating the Act as a documentation exercise and start treating it as an operating model. Three moves make the difference.
First, anchor it to a management system. ISO/IEC 42001 gives you the governance scaffolding — roles, risk processes, documentation control, and continual improvement — so that compliance is repeatable across systems rather than rebuilt for each one.
Second, assign accountable owners per system, not per regulation. A single named owner for each AI system, holding both the role classification and the obligation list, prevents the diffusion of responsibility that kills compliance programmes.
Third, push obligations into the supply chain on paper. If a GPAI provider owes you documentation, the contract should say so. If you owe a customer transparency, your terms should reflect it.
We deliver this as engineering, not paperwork — wiring monitoring, logging, and oversight into the platform so that the evidence is a by-product of running the system, not a quarterly scramble.
FAQ
What is the difference between a provider and a deployer under the EU AI Act?
A provider develops an AI system or has one developed and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its own authority in a professional context. Providers carry the heavier burden: conformity assessment, technical documentation, and EU database registration. Deployers must ensure human oversight, monitor operation, and use the system per the provider's instructions.
Can a company be both a provider and a deployer at the same time?
Yes, and this is common. If you fine-tune a model, rebrand a third-party system, or substantially modify a high-risk system, you can become the provider of that modified system while still deploying it. Each role triggers its own obligations, so you may carry both sets simultaneously for the same system.
What are GPAI obligations and when do they apply?
General-purpose AI (GPAI) model providers must maintain technical documentation, publish a training-data summary, implement a copyright policy, and cooperate with downstream providers. These obligations applied from 2 August 2025. GPAI models already on the market before that date must reach full compliance by 2 August 2027. Models with systemic risk face additional evaluation and incident-reporting duties.
What changes on 2 August 2026?
High-risk AI systems listed in Annex III become subject to their full obligations from 2 August 2026. That means conformity assessment, registration in the EU database, complete technical documentation, post-market monitoring, and demonstrable human oversight. Missing this deadline for a high-risk system exposes you to fines of up to EUR 15 million or 3 percent of global annual turnover.
Does using ChatGPT or Microsoft Copilot make us a provider?
Generally no. If you use a tool as delivered, you are a deployer of that system and a downstream user of the underlying GPAI model. You become a provider only if you place a system on the market under your own name, substantially modify a high-risk system, or change its intended purpose so that it becomes high-risk.
What are the core deployer obligations under the EU AI Act?
Deployers of high-risk systems must use the system in line with the provider's instructions, assign competent human oversight, ensure input data is relevant for the intended purpose, monitor operation and log incidents, keep system logs, and inform affected persons where required. Public bodies and certain entities must also complete a fundamental rights impact assessment before deployment.
How does ISO/IEC 42001 relate to EU AI Act compliance?
ISO/IEC 42001 is the management-system standard for artificial intelligence. It does not replace the EU AI Act, but it gives you the governance scaffolding — roles, risk processes, documentation, and continual improvement — that makes Act compliance auditable and repeatable. We use it as the backbone for client AI governance programmes that have to satisfy both regulators and internal assurance.
Where to go next
If you are unsure which role applies to which system in your estate, that is exactly the question to resolve first — before any control work begins. Our AI and data platform engineering team helps European enterprises classify their AI portfolio, close supply-chain documentation gaps, and build the monitoring and oversight that makes 2 August 2026 a non-event rather than a deadline.
Topics