Provider or deployer? Getting your AI Act role right
Everything in the AI Act hangs off one question asked per system: did you place this on the market under your name, or are you using it under your authority? Get the role wrong and you build the wrong program.
Updated July 16, 2026 · Informational guidance, not legal advice
The definitions, in one breath each
Under Article 3(3), 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, whether for payment or free of charge. Under Article 3(4), a deployer uses an AI system under its authority in a professional context.
The role determines the obligation set. Providers of high-risk systems carry Articles 9–15 via Article 16: risk management, data governance, technical documentation, logging capability, human-oversight design, conformity assessment, CE marking, registration. Deployers carry Article 26: operating within intended purpose, assigning competent oversight, monitoring, retaining logs, informing workers. These are different programs with different owners, artifacts, and costs — which is why classifying the role wrongly is expensive in both directions.
The answer is per-system
"Are we a provider or a deployer?" is malformed. A company is a provider of some systems and a deployer of others. The register needs a role field on every entry, with the reasoning recorded — not a single company-wide answer.
The gray zones where roles actually get decided
- White-labeling a vendor's AI feature under your own brand: you are placing a system on the market under your name — provider.
- Building an internal tool in-house and putting it into service: you are the provider and the deployer of the same system, and both obligation sets apply.
- Wrapping a general-purpose model API into a product with a specific intended purpose: you are typically the provider of that AI system. This is distinct from the obligations of the GPAI model's own provider under Articles 51–56, which stay upstream with the model provider.
- Configuring, prompting, or integrating a vendor tool within its documented intended purpose: deployer.
- Fine-tuning or substantially modifying a vendor's high-risk system: this can shift you into the provider role — see Article 25 below.
Article 25: the role-shifting traps
Article 25 is where deployers become providers without noticing. A deployer, distributor, or importer takes on the provider's obligations for a high-risk system when any of three things happens:
- It puts its own name or trademark on a high-risk system already on the market.
- It makes a substantial modification to a high-risk system on the market, such that the system remains high-risk.
- It modifies the intended purpose of a system that was not high-risk — including a general-purpose system — such that it becomes high-risk.
The third prong deserves the most attention from product teams: taking a general-purpose assistant and pointing it at resume screening or credit decisions changes its intended purpose into an Annex III area — and makes you the provider of a high-risk system, with the full Articles 9–15 load. When a role shift happens, the original provider must cooperate, handing over the documentation and technical access the new provider needs.
Contract for the shift before it happens
If your roadmap could substantially modify or re-purpose a vendor system, the time to secure documentation, technical-access, and cooperation commitments is at contract signature — not after the shift, when your leverage is gone and your obligations have already attached.
Recording the role so it holds up
Role classification is the second field of every register entry, right after the system itself. What makes it defensible is the same discipline as risk classification: the conclusion, the reasoning, the date, and an owner. For provider-role systems, the entry points at the Articles 9–15 program; for deployer-role systems, at the Article 26 duties; for both-role systems, at both. And the classification is not permanent — a rebrand, a substantial modification, or a re-purpose is a trigger to reclassify, and the register should make that trigger visible rather than relying on someone remembering.
Classify role and risk in the same pass
The free Attevera classifier walks one system through Articles 5 and 6 and Annex III — and the register records your role reasoning per system, so the answer survives staff turnover.
Run the free classifierFrequently asked questions
We resell a vendor's AI product under the vendor's brand. What are we?
Reselling under the vendor's own name and trademark makes you a distributor, with lighter duties — verify CE marking and documentation, hold non-conforming systems back. Rebranding it as yours is what flips you to provider under Article 25. This is informational guidance, not legal advice.
Does prompting or configuring a vendor LLM make us a provider?
Ordinary configuration and prompting within the vendor tool's intended purpose keeps you a deployer. The line is crossed when you place a system on the market under your name, or change its intended purpose into a high-risk area — a materially different act than writing a system prompt.
We built an internal tool ourselves. Do provider obligations really apply with no customers?
Putting a system into service for your own use under your own name is enough — provider obligations attach without a single external customer, alongside your deployer duties for operating it. Whether the system is high-risk still depends on Article 6 and Annex III.
How does this interact with GPAI model obligations?
Separately. Articles 51–56 bind the provider of the general-purpose model itself — the lab that trained it. Building on top of a GPAI model makes you the provider or deployer of your AI system, not of the model. Attevera's scope is the system-level record; foundation-model provider duties are out of scope.