Provider vs Deployer Obligations Under the EU AI Act

Under the EU AI Act, the provider develops an AI system, or has it developed, and places it on the market or puts it into service under its own name; the deployer uses it under its own authority. Providers carry most high-risk duties (Article 16). Deployers have a shorter list under Article 26, but can become providers under Article 25.

Key takeaways

• Your role is decided per AI system, not per company. The same organisation can be a provider of one system and a deployer of another.
• Providers of high-risk AI design compliance in: risk management, data governance, documentation, conformity assessment, CE marking, registration and post-market monitoring.
• Deployers of high-risk AI make it safe in use: following instructions, human oversight, input data, log retention, informing workers and affected people, and in some cases a fundamental rights impact assessment.
• A deployer becomes a provider if it puts its name or trademark on a high-risk system, substantially modifies it, or changes the intended purpose of any system so that it becomes high-risk.
• Article 4 AI literacy applies to both roles, whatever the risk level.

The six operator roles in the AI Act

The Act calls everyone in the AI value chain an "operator". The definitions are in Article 3, and getting them right is the first step in any compliance plan, as our EU AI Act guide explains in its overview.

"Putting into service" includes supplying a system for your own use. If your data science team builds a model and your business uses it internally, your organisation is both provider and deployer. Non-EU organisations are not off the hook: the Act reaches providers anywhere that serve the EU market and anyone whose AI output is used in the EU, as covered in how the EU AI Act applies to UK, US and other non-EU companies.

A quick way to map your roles across every system is Opsio's free AI governance assessment: it asks which AI you build, buy and embed, and returns a maturity score plus four editable Word documents, including an AI Vendor Due Diligence Checklist for the systems you deploy.

Provider vs deployer obligations side by side

For high-risk systems the split is deliberate: the provider controls design, so it carries the design duties; the deployer controls the context of use, so it carries the operational ones. The table summarises the main obligations. See Article 26 for the deployer text.

The rights assessment row deserves its own guide: public bodies, providers of public services and deployers of credit-scoring or life and health insurance pricing systems must complete a fundamental rights impact assessment under Article 27. Which systems count as high-risk in the first place is covered in high-risk AI systems: Article 6 and Annex III. As of October 2026, the Annex III obligations apply from 2 December 2027 and Annex I obligations from 2 August 2028.

Obligations that apply whatever the risk level

Two sets of duties reach beyond high-risk AI. First, AI literacy: the amended Article 4 frames the duty as taking measures to promote the AI literacy of staff and others operating AI on the organisation's behalf, and it applies to providers and deployers alike. Our article on AI literacy under Article 4 covers what a proportionate programme looks like. Second, Article 50 transparency, which applies from 2 August 2026 and is split by role: providers must make chatbots disclose that they are AI and mark synthetic content in a machine-readable way; deployers must disclose deepfakes and AI-generated text published to inform the public on matters of public interest, and must inform people exposed to emotion recognition or biometric categorisation.

When a deployer becomes a provider: Article 25

This is where many organisations get caught out. Under Article 25(1), a deployer, importer, distributor or other third party is treated as the provider of a high-risk system, with all the Article 16 duties, in three situations:

1. Own name or trademark. You put your name or trademark on a high-risk system already on the market, for example white-labelling a vendor's credit-scoring engine as your own product. Contracts can allocate obligations differently, but the default shifts to you.
2. Substantial modification. You make a substantial modification to a high-risk system, such as retraining a recruitment model on your own data in a way the provider did not foresee in its conformity assessment, and it remains high-risk.
3. Changed intended purpose. You take a system that is not high-risk, including a general-purpose AI system, and use it for a purpose that makes it high-risk under Article 6.

When this happens, the original provider is no longer the provider of that specific system, but it must cooperate: supply the information, technical access and assistance the new provider needs to meet its obligations. That cooperation duty does not apply if the original provider clearly said its system must not be turned into a high-risk system. Read the terms of service; many general-purpose AI vendors include exactly that restriction, which leaves you carrying the full provider burden without support.

Two examples: rolling out Copilot vs building a CV-screening model

Company A rolls out Microsoft Copilot to 2,000 staff

Microsoft is the provider of Copilot, and of the underlying model in its GPAI role. Company A is a deployer. Drafting emails, summarising meetings and writing code are not Annex III uses, so no high-risk obligations apply. Company A still has work to do: promote AI literacy among the people using it, disclose any deepfakes or AI-written public-interest text it publishes, apply GDPR to the personal data flowing through prompts, and set clear rules in an acceptable use policy.

The risk is drift. If the HR team starts pasting CVs into Copilot and asking it to rank candidates, the use moves into Annex III area 4. Under Article 25(1)(c), Company A may then be treated as the provider of a high-risk system it never designed, without the documentation, testing or conformity assessment that role requires. The practical answer is a policy line that bans this use, plus monitoring.

Company B builds its own CV-screening model

Company B's data team trains a model that scores applicants and the recruitment team uses it. Company B is the provider, because it developed the system and put it into service for its own use, and also the deployer. The use is Annex III area 4, and scoring candidates is profiling, so the Article 6(3) derogation is not available. By 2 December 2027 Company B needs a risk management system, data governance including bias testing, Annex IV documentation, logging, human oversight design, a quality management system, internal-control conformity assessment, an EU declaration of conformity, CE marking and EU database registration. As deployer it must also inform applicants, keep logs, assign trained reviewers and inform worker representatives where the tool is used on current staff.

How Do You Manage the provider–deployer boundary in practice?

• Record a role for every system in your AI inventory, and review it when use changes.
• Ask vendors for their classification and their instructions for use before purchase; this belongs in an AI vendor due diligence checklist.
• Check contracts for clauses that forbid high-risk use, allocate Article 25 duties or limit cooperation.
• Control modifications. Fine-tuning or retraining a high-risk system should go through change management with a "substantial modification" check.
• Write the boundary into policy so staff know which uses of general tools are off limits.

Frequently asked questions

What is the difference between a provider and a deployer under the AI Act?

A provider develops an AI system, or has it 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 design-stage obligations such as conformity assessment; deployers carry use-stage obligations such as human oversight, log retention and informing affected people.

What are the deployer obligations for high-risk AI?

Under Article 26, deployers must use the system according to the instructions, assign competent human oversight, ensure relevant input data, monitor operation and report risks and serious incidents, keep logs for at least six months, inform workers before workplace use and inform people subject to decisions. Some deployers must also complete a fundamental rights impact assessment under Article 27.

Can a company be both provider and deployer?

Yes. An organisation that builds an AI system and uses it internally is the provider, because putting a system into service for your own use counts, and also the deployer. It must meet both sets of obligations. Roles are assessed system by system, so the same company may be a provider for one tool and a deployer for another.

Does fine-tuning a model make us a provider?

It can. Making a substantial modification to a high-risk system turns you into its provider under Article 25(1)(b). Separately, adapting a general-purpose model or system for a high-risk purpose makes you the provider under Article 25(1)(c). Fine-tuning for a low-risk use, such as drafting marketing copy, does not by itself make you the provider of a high-risk system.

Are importers and distributors liable under the AI Act?

Yes, with lighter duties. Importers must verify that the provider has completed conformity assessment, prepared documentation, applied the CE marking and appointed an authorised representative where needed. Distributors must check CE marking and accompanying documents. Either becomes a provider if it rebrands, substantially modifies or repurposes a high-risk system.

Know your role for every AI system

Most AI Act obligations follow from one question: are you the provider or the deployer of this system? Opsio's free EU AI Act readiness assessment walks you through it in 14 steps, about 40 minutes, and writes four editable Word documents from your answers: an AI Governance Framework, an AI Acceptable Use Policy, an AI Vendor Due Diligence Checklist and an AI Risk Assessment Template, plus a maturity score. Free, with no card and no obligation.

This article is general information, not legal advice. Check the consolidated text of Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744. Statements are accurate as of October 2026.