The user wants to understand Provider in the context of EU AI Act and apply it to practical AI governance or compliance work.
Use Provider for the actor that develops, places on the market, or puts into service an AI system or GPAI model under its name; use Deployer for the actor that uses an AI system under its authority.
A provider and a deployer are different EU AI Act actor roles. A provider is the actor that develops, has developed, places on the market, or puts into service an AI system or GPAI model under its own name or trademark. A deployer is the actor that uses an AI system under its authority, except for purely personal non-professional activity. The difference is therefore not simply “vendor versus customer,” because a customer can become a provider if it substantially modifies a system, rebrands it, or changes the intended purpose in a regulated way. The core linked Atlas concepts are provider, deployer, and ai-system. Provider duties usually focus on design, compliance evidence, market placement, documentation, and post-market monitoring. Deployer duties usually focus on responsible use, following instructions, human oversight, operational monitoring, data input quality where relevant, and escalation when the system creates risk. In mixed supply chains, one organization may even hold different roles for different systems, versions, or deployment contexts.
Think of provider and deployer as the difference between making a tool available and using the tool in your workplace. A company that manufactures and sells a safety-critical machine is responsible for design and product compliance. A factory that buys and operates the machine is responsible for using it correctly, training staff, following instructions, and monitoring problems. AI is similar. The provider must usually prove the system was built and supplied lawfully; the deployer must usually prove it is used responsibly in the real operating context. Both roles matter, and a safe system can still fail if the operator uses it in the wrong context.
Analogy
A machine manufacturer versus a factory operator: one supplies the system, the other uses it under real workplace conditions.
This distinction matters because AI Act compliance fails when duties are assigned to the wrong party. A provider-heavy task, such as technical documentation or conformity assessment, cannot simply be pushed to a deployer that lacks design evidence. A deployer-heavy task, such as local human oversight or monitoring in a workplace process, cannot be solved by the provider alone. The timeline also matters: prohibited-practice and AI-literacy duties already started on 2 February 2025, GPAI obligations started on 2 August 2025, and transparency rules are scheduled from 2 August 2026. Role mapping must therefore happen before contracts, launch, or operational rollout. This is especially important in procurement because missing supplier evidence or missing local oversight can both delay approval.
Urgency
Incorrect role mapping can leave both parties believing the other side owns a required control, creating an audit and enforcement gap.
The practical obligation is to create a role map for each AI system, then connect controls to the correct actor. Providers should document intended purpose, risk classification, system design, testing, instructions, conformity evidence where required, post-market monitoring, and corrective-action processes. Deployers should document how the system is used, who supervises it, what instructions are followed, what input data is controlled, how users are trained, and how incidents or malfunctions are escalated. Contracts should support this split by requiring information flows, audit support, incident cooperation, and change notices. The map should be revisited whenever the system is rebranded, materially changed, integrated into another product, or used for a new purpose.
The biggest mistakes come from treating the role split as a commercial label rather than a legal and operational analysis. A company may be a customer in the contract but still take on provider-like responsibility if it changes the AI system’s purpose or supplies it onward.
Mistake 1: Calling every SaaS customer a deployer ignores cases where the customer rebrands, resells, or substantially modifies the system.
Mistake 2: Assuming provider documentation replaces local deployer oversight leaves human review, staff training, and real-use monitoring undocumented.
The main Atlas comparison is provider-vs-deployer. Related terms include provider, deployer, ai-system, downstream-provider, intended-purpose, conformity-assessment, and documentation. This page should also link to the provider and conformity assessment question pages. It gives readers a clean path from role theory to evidence collection, contracts, and operational governance responsibilities. It also supports clean internal linking from role labels to controls.