You are a provider if you develop an AI system, or have one developed, and offer it under your own name. You are a deployer if you use someone else's AI system in your professional activities. Many companies are both at once, and a deployer can become a provider by rebranding or substantially modifying a system.
EU AI Act: Provider or Deployer? How to Tell Which One You Are
Why Your Role Under the EU AI Act Matters
Almost every obligation in Regulation (EU) 2024/1689 is addressed to a role, not to a company in general. Providers of high-risk AI systems carry the full compliance programme: risk management, data governance, technical documentation, conformity assessment, registration, and post-market monitoring. Deployers of the same systems carry a much shorter list: use the system as instructed, assign human oversight, monitor operation, keep logs, and inform affected people. Misjudging your role therefore means either doing far too much work or, more dangerously, far too little. The classification is also dynamic: actions you take after buying an AI system can quietly upgrade you from deployer to provider.
What Is a Provider
Article 3 defines a provider as a natural or legal person, public authority, agency, or other body that develops an AI system or a general-purpose AI model, 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. Two elements matter. First, development or commissioning development: writing the model yourself or paying someone to build it for you both count. Second, offering it under your own name: the branding test. A software house that builds an AI scheduling engine and sells it as its own product is a provider. So is a company that commissions an agency to build a custom chatbot and then offers that chatbot to its customers under its own brand, even though it wrote no code.
What Is a Deployer
A deployer is any natural or legal person, public authority, agency, or other body using an AI system under its authority, except where the AI system is used in the course of a personal non-professional activity. The phrase under its authority means the organisation decides how and when the system is used in its operations. A retailer using a purchased demand-forecasting tool, a clinic using a third-party triage assistant, and an HR department using an external CV-screening platform are all deployers. Using AI through a browser subscription rather than installing it changes nothing: the deciding factor is professional use under your control, not the delivery mechanism.
Side-by-Side Comparison
| Question | Provider | Deployer |
|---|---|---|
| Did you build it or commission it? | Yes | No, you bought or subscribed |
| Whose name or brand is on it? | Yours | The vendor's |
| Core duties for high-risk AI | Risk management, data governance, documentation, conformity assessment, CE marking, registration, post-market monitoring | Follow instructions for use, human oversight, input data relevance, monitoring, log retention, informing workers and affected persons |
| Typical fine exposure | Higher, because more obligations can be breached | Lower, but real: deployer duties carry the same fine tier of up to 15 million euros or 3 percent |
| Needs an EU authorised representative if outside the EU? | Yes, for high-risk systems | No |
How a Deployer Becomes a Provider
Article 25 lists three situations in which a distributor, importer, deployer, or other third party is treated as the provider of a high-risk AI system, inheriting all provider obligations. First, putting your name or trademark on a high-risk system already on the market: classic white-labelling. Second, making a substantial modification to a high-risk system in a way that it remains high-risk: a change not foreseen in the provider's original conformity assessment that affects compliance or intended purpose. Third, modifying the intended purpose of an AI system, including a general-purpose system, in a way that makes it high-risk when it was not before. A practical example: a company licenses a general writing assistant and reconfigures it to rank job applicants. Ranking applicants is a high-risk purpose, so the company has just become a provider of a high-risk system, with everything that entails.
Common Edge Cases
Fine-tuning a general-purpose model raises the most questions. Light prompt engineering and retrieval setups generally leave you a deployer. Fine-tuning a model and offering the result under your own name pushes you toward being a provider of that modified model or system, with obligations proportionate to the modification. API wrappers are another trap: if you build a product around a third-party model and sell it under your brand, you are the provider of that AI system even though the intelligence is rented. In-house builds count too: a bank that develops its own credit-scoring model and puts it into service for itself is both provider and deployer simultaneously, because putting into service for own use is enough. Finally, free tools: distributing an AI system free of charge still makes you a provider; payment is not part of the test.
What Each Role Should Do Before August 2026
Providers of high-risk systems have the long list, and most of it takes months: building a quality management system, preparing technical documentation, arranging conformity assessment, and registering in the EU database. Deployers should focus on five things: inventory the AI they use, obtain and read the instructions for use from each vendor, assign trained humans to oversee high-risk systems, set up log retention of at least six months, and prepare notices for workers and affected individuals where required. Both roles share the AI literacy duty, which has applied since February 2, 2025.
A Simple Decision Path
For each AI system, ask in order. One: do we offer this system to others or use a system we created ourselves? If we created it or commissioned it and it carries our name, we are the provider. Two: have we rebranded, substantially modified, or repurposed someone else's system into a high-risk use? If yes, we are treated as the provider. Three: do we simply use it in our business under the vendor's name and within its intended purpose? Then we are a deployer. Write the answer down per system, because your compliance plan, your budget, and your deadline pressure all follow from it.
How to Allocate Responsibilities with Vendors
Role boundaries become real in contracts. The Act expects providers of high-risk systems to give deployers instructions for use that make deployer compliance possible, and it requires third parties supplying tools, components, or services for high-risk systems to specify, by written agreement, the information and assistance the provider needs. When you buy AI, ask vendors four things in writing: the system's risk classification and reasoning, the instructions for use, how logging works and how you can access and retain logs, and who handles incident notification. When you sell AI, prepare those answers before customers ask, because larger buyers have begun inserting AI Act clauses into procurement templates as standard. Ambiguity in contracts does not move legal responsibility, the regulation allocates that by role, but clear contracts prevent the gaps where each side assumes the other is handling registration, monitoring, or notices.
Keep a Record of Your Role Decisions
Classification judgements deserve a paper trail. For each system, record what it is, who built it, whose name it carries, what its intended purpose is according to the provider, how you concluded provider or deployer status, and the date of the assessment. Revisit the record whenever something material changes: a rebrand, a new use case, a fine-tuning project, or a vendor change. Two triggers deserve standing alerts in your change process. Any plan to put your own brand on a bought-in system, and any plan to point an existing tool at decisions about people, hiring, credit, education, or access to services. Both can silently convert a light deployer position into a full provider one, and catching that in a planning meeting costs nothing, while discovering it after launch can mean retrofitting a conformity assessment under deadline pressure.
What About General-Purpose AI Model Providers
The provider concept also covers general-purpose AI models, the broad foundation models that power many downstream products, but the obligations differ from those for AI systems. A model provider must prepare technical documentation, share information with downstream system builders, put a copyright policy in place, and publish a summary of training content, with extra duties where a model poses systemic risk. If you fine-tune or otherwise modify such a model and release the result, you can become the provider of the modified model for your modification. Most businesses reading this are not model providers; they are system providers or deployers sitting downstream. The distinction matters mainly when negotiating with model vendors: the documentation they owe you under the Act is precisely what you need to meet your own duties, so ask for it by name rather than accepting a marketing datasheet in its place.
Check your AI compliance readiness — free.
Take the Readiness Check 3 minutes · 10 questions · no signup requiredThis article is for informational purposes only and does not constitute legal advice. Regulatory requirements change frequently — verify current rules with official sources. Built by Sawai Gyoseishoshi Office, Hiroshima, Japan.