EU AI Act — Provider vs deployer (roles & when the line shifts)
Note: this explainer is informational and framework references are never a compliance guarantee — align your program with your legal counsel.
The EU AI Act provider vs deployer distinction is the most consequential role question in the whole regime, because it decides whose obligations apply. Most companies are deployers; a smaller set are providers; and — this is the part that surprises people — a deployer can become a provider by what it does with a tool. Article 3 sets the definitions, Article 25 sets the switch.
Deployer (Betreiber) — the default role
A deployer is anyone using an AI system under their own authority in a professional capacity (Article 3(4)). That is the vast majority of organisations: you buy or subscribe to an AI tool and put it to work. Deployer duties are the lighter set — for high-risk systems they are the Article 26 obligations (use per instructions, monitor operation, keep logs), not the full provider conformity regime.
Provider (Anbieter) — who places it on the market
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 (Article 3(3)) — paid or free. Providers of high-risk systems carry the heavy obligations: conformity assessment, technical documentation, a quality management system, registration, and post-market monitoring. If you only use third-party tools, you are not a provider merely by using them.
When a deployer becomes a provider (Article 25)
Article 25 is the trigger. A deployer (or distributor/importer) is treated as the provider of a high-risk system — and takes on the provider obligations — if it:
- puts its own name or trademark on a high-risk system already on the market;
- makes a substantial modification to a high-risk system such that it stays high-risk; or
- changes the intended purpose of an AI system (including a general-purpose one) so that the system becomes high-risk.
Any one of these flips the role. The original provider is then relieved of the obligations for that system going forward and must cooperate with the new provider.
Where the line actually sits — fine-tuning vs substantial modification
The switch is narrower than it sounds. Using, configuring, or prompting a tool within its intended purpose is ordinary deployer activity — not a role change. A substantial modification (Article 3(23)) is a change not foreseen in the system's original conformity assessment that affects its compliance or alters its intended purpose. So:
- Choosing settings, writing prompts, or connecting a tool to your data → still a deployer.
- Rebranding a high-risk system as your own, re-engineering it beyond its assessed purpose, or repurposing a non-high-risk tool into a high-risk use → you may now be a provider.
Fine-tuning sits on a spectrum: light adaptation within the intended purpose stays deployer-side; fine-tuning that changes what the system is for can cross into a substantial modification. When in doubt on a high-risk workflow, treat it as a legal question, not a settings one.
Practical takeaway for SMEs
Buying and using AI tools keeps you a deployer with the Article 26 duties. You only risk provider status if you rebrand, substantially modify, or repurpose a system into high-risk territory. The prerequisite either way is knowing which AI systems are in use and how — so the role question can be answered per tool, not guessed.
Shield's lever: Discovery and the audit log give you the per-tool inventory and usage picture that a provider-vs-deployer determination depends on. Applying the EU AI Act & GDPR Starter bundle from the preset library keeps that picture current.
Was this article helpful?
Related articles
EU AI Act Article 26 — Deployer obligations
Article 26 defines your duties when deploying high-risk AI — applicable from December 2027 under the Digital Omnibus. What paragraphs (1), (5), and (6) require and how Shield prepares you now.
Read articleEU AI Act Article 6 — High-risk classification
Article 6 sets the EU AI Act high-risk classification: the Annex III areas, the 6(3) filter, and why the label attaches per use case × context — not per app. Applicable from December 2027 under the Digital Omnibus.
Read articleEU AI Act Article 50 — Transparency obligations
Article 50 sets the EU AI Act transparency obligations: AI chatbots must disclose they are AI, and AI-generated content and deepfakes must be marked. Applicable from 2 August 2026, with a narrow Article 50(2) marking transition to 2 December 2026 for pre-existing systems.
Read articleEU AI Act Article 5 — Prohibited practices
Article 5 bans AI practices deemed unacceptable — already in force. What is prohibited, why shadow AI is your exposure, and how Shield keeps prohibited-class tools out.
Read articleStill stuck?
Send us the details — we answer within one business day.