⚡ TL;DR — The Answer in 30 Seconds:

• Provider = you developed the AI system or substantially modified it and placed it on the market. You carry the heaviest obligations: Technical File, risk management system, conformity assessment, CE marking, EU database registration.
• Deployer = you use someone else’s AI system in a professional context. You have lighter but still significant duties: human oversight, monitoring, incident reporting, staff training.
• Many organisations are both simultaneously — provider of their own AI product to customers, deployer of third-party AI tools internally. Each role carries separate obligations.

Of all the questions I field from legal and product teams, this one comes up most consistently: “Are we a provider or a deployer?” And the answer almost always requires more than a yes or no, because the distinction isn’t always as clean as the law makes it sound.

Getting this right matters enormously. Misclassify yourself as a deployer when you’re actually a provider and you’re operating without the compliance programme the law requires. Misclassify yourself as a provider when you’re a deployer and you may be investing heavily in obligations that don’t apply to you. Either way, the consequences are real.

This post gives you the complete framework for determining which category you fall into — and what exactly you owe under each. For the broader regulatory context, start with our Ultimate Guide to EU AI Act Compliance.

How the EU AI Act Defines Provider vs. Deployer

The definitions sit in Article 3 of the EU AI Act and are precise — even if their application to real-world scenarios requires careful analysis.

A Provider (Article 3(3)) is “a natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model 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.”

A Deployer (Article 3(4)) is “a natural or legal person, public authority, agency or other body that uses an AI system under its own authority except where the AI system is used in the course of a personal non-professional activity.”

The decisive word in the Provider definition is “places on the market.” If you develop an AI system and offer it to third parties — customers, clients, users — under your own name, you are a provider of that system, regardless of whether you built the underlying model yourself or assembled it from third-party components. The decisive word in the Deployer definition is “uses” — you are consuming an AI capability built by someone else and applying it in your operations or products.

What Are AI Provider Obligations Under the EU AI Act?

Providers of high-risk AI systems carry the full weight of Chapter III compliance. Article 16 lists their obligations, and they are substantial:

For the step-by-step process for meeting these obligations before August 2026, use our 6-Month Readiness Checklist. For the technical documentation specifics, read our Article 11 and Annex IV pillar guide.

What Are AI Deployer Obligations Under the EU AI Act?

Deployers of high-risk AI systems have significantly lighter obligations than providers — but “lighter” does not mean trivial. Article 26 sets out deployer duties, and several of them require genuine operational investment.

As a deployer of a high-risk AI system, you must:

1. Use the system in accordance with the provider’s instructions (Article 26(1)). If you deploy a system outside its documented intended use, you may acquire provider-level obligations for the out-of-scope use case.
2. Assign appropriately trained human oversight personnel (Article 26(2)). You are responsible for ensuring that the people who oversee the system in your organisation are competent to do so — this requires genuine assessment of their skills, not just a box-tick.
3. Monitor the system’s operation and report serious incidents or malfunctions to the provider and to national authorities (Article 26(5)).
4. Maintain logs generated by the system for at least six months where you control the logging infrastructure (Article 26(6)).
5. Conduct a Fundamental Rights Impact Assessment (FRIA) before deploying the system if you are a public body, or if you operate in certain sensitive sectors (Article 27). Private sector deployers in most sectors are not directly required to conduct a FRIA, but doing so is strong governance practice.
6. Inform affected individuals that they are subject to AI-assisted decisions where required by Article 50.
7. Ensure AI literacy for all staff working with the system under Article 4.

The Grey Zone: When a Deployer Becomes a Provider

Article 25 creates the most important — and most frequently misunderstood — boundary in the entire provider/deployer framework. It establishes that a deployer becomes a provider, and acquires all provider obligations, when they make a substantial modification to the AI system.

What Counts as a Substantial Modification That Changes Your Legal Status?

Under Article 3(23), a substantial modification is “a change to the AI system after its placing on the market or putting into service which affects the compliance of the AI system with the requirements set out in this Regulation or results in a modification to the intended purpose for which the AI system has been assessed.”

In practice, these actions almost always constitute substantial modifications that convert a deployer into a provider:

• Fine-tuning a third-party model on your own proprietary data
• Changing the intended use case of the system beyond what the provider documented — using a document summarisation AI for employment decision support, for example
• Removing or bypassing safety controls built into the system by the provider
• Integrating the system into a product architecture that materially changes its risk profile relative to its documented intended use
• Building a Retrieval-Augmented Generation (RAG) layer over a GPAI model with proprietary data, where the RAG output is used for high-risk decisions

These actions, when taken by a company that started as a deployer, trigger provider-level compliance obligations — including the full Technical File, risk management system, conformity assessment, and EU database registration. Companies that make these modifications without recognising the change in legal status have acquired a provider’s compliance obligations without a provider’s compliance programme.

Real-World Scenarios: Provider, Deployer, or Both?

Scenario 1: The SaaS HR Platform

A company builds an AI-powered candidate screening tool and sells it as a SaaS product to employers. The AI is trained on the company’s own data and operated under the company’s brand.

Classification: Provider. The company developed the AI system and places it on the market under its own name. Full Article 16 provider obligations apply to the screening tool. If the company also uses a third-party AI tool internally for its own employee performance management, it is simultaneously a Deployer of that separate system.

Scenario 2: The Bank Using a Credit Scoring API

A bank integrates a third-party credit scoring API into its loan application workflow. The bank uses the API output as one input into loan decisions made by human underwriters.

Classification: Deployer. The bank is using a system developed and placed on the market by the API provider. Article 26 deployer obligations apply. However, if the bank substantially modifies the scoring logic — adding proprietary features, re-weighting outputs, building a wrapper model — it moves toward provider status for the modified system.

Scenario 3: The Enterprise Using OpenAI for Internal Operations

A manufacturing company uses the OpenAI API to build an internal tool that analyses HR performance reviews and flags employees for promotion consideration.

Classification: Provider of a high-risk AI system. This is the scenario most companies get wrong. Even though they’re “just using an API,” they have built a system that uses AI for employment decisions (Annex III, Category 4) and placed it into service within their own organisation. The fact that it’s internal doesn’t change the classification — it’s still a high-risk AI system that requires a Technical File, risk management system, and conformity assessment. See our dedicated guide on using third-party LLMs and your AI Act obligations.

Scenario 4: The Reseller

A consultancy purchases an AI compliance tool from a vendor and provides it to clients as part of their service offering, under the consultancy’s own branding.

Classification: Provider. By placing the system on the market under their own brand — even though they didn’t build it — the consultancy becomes a provider under Article 3(3). They must ensure the system meets all applicable requirements, which in practice requires a contractual arrangement with the original vendor to provide the underlying compliance documentation.

The Dual-Role Reality: How to Manage Both Sets of Obligations

Most technology companies are both providers and deployers — providers of their own AI product, deployers of the AI tools they use internally (HR systems, productivity tools, analytics platforms). Managing both roles requires:

• A complete AI system inventory that distinguishes provider systems (your own products) from deployer systems (third-party tools you use). See our post on why you need a centralised AI system inventory.
• Separate compliance tracks for each role — the provider track covering Articles 8–17, 43, 71, 72; the deployer track covering Article 26, Article 27 (if applicable), and Article 4.
• A vendor management programme that verifies the compliance status of third-party AI providers whose systems you deploy. See our post on AI vendor due diligence in 2026.
• Clear internal ownership — the compliance team owns both tracks but needs named owners in product/engineering (for provider obligations) and in operations/procurement (for deployer obligations).

Frequently Asked Questions

Jasper Claes

Jasper Claes is a Compliance Manager and consultant specializing in AI governance for high-scale technology companies operating in regulated markets. He advises product and legal teams on implementing practical compliance frameworks aligned with evolving regulations such as the EU AI Act. Through his writing, Jasper focuses on translating complex regulatory requirements into clear, actionable guidance for teams building and deploying AI systems.