EU AI Act Provider vs Deployer: What’s the Difference and What Are Your Obligations?
AI Law · EU AI Act Compliance
EU AI Act Provider vs Deployer: What’s the Difference and What Are Your Obligations?
Most SaaS companies are simultaneously a provider to their customers and a deployer of third-party AI systems. Each role carries different legal obligations — and the line between them moves if you modify the system.
1
The four roles under EU AI Act
Provider · Deployer · Importer · Distributor
2
Provider vs Deployer obligations
9 vs 4 · side-by-side comparison
3
Decision tree: which role are you?
4-step interactive · role + obligations
4
SaaS scenarios in practice
3 real-world configurations with verdict
5
Common questions
Role shifts · contracts · liability
!
Modifying a system = becoming provider
Article 25 · full obligation set applies
When an enterprise client sends a compliance questionnaire asking about your EU AI Act status, the first question is almost always: are you the provider or the deployer? For many SaaS companies, the answer is “both — depending on which AI component you’re asking about.” Getting this wrong in your contracts, your investor documents, or your client responses is a material legal risk. AI Regulatory Opinions from WCR Legal provide a formal analysis of your exact role position — the document enterprise procurement and legal teams are increasingly asking founders to produce before contract execution.
Section 1
The Four Roles Under EU AI Act
Article 3 of the EU AI Act defines four distinct roles in the AI supply chain. Each carries different obligations. A single company can hold more than one role simultaneously — a common situation for SaaS companies that both build AI-powered products and use third-party AI infrastructure to deliver them.
Article 3 Role Definitions
Provider · Deployer · Importer · Distributor
Article 3
1
Article 3(3) · Primary obligations
Provider — develops and places on the market under their own name
A provider is a natural or legal person that develops an AI system (or has it developed) and places it on the market or puts it into service under their own name or trademark — whether for payment or free of charge. If you built the AI system or the AI-powered product that is the regulated system, and it is available to external users or integrated into a client’s operations under your branding, you are the provider. Providers bear the heaviest obligation set: technical documentation, conformity assessment, CE marking, EU registration, post-market monitoring, and more. See the August 2026 deadline overview for the enforcement timeline.
2
Article 3(4) · Lighter obligations
Deployer — uses an AI system in a professional context
A deployer is a natural or legal person that uses an AI system under their authority in a professional context — except where the AI system is used in the course of a personal non-professional activity. If you are running a third-party AI system (e.g. an OpenAI or Anthropic API) as part of your product delivery without modifying the underlying model, you are acting as a deployer of that system. Deployers have four core obligations: implementing human oversight, retaining logs, conducting fundamental rights impact assessments where required, and informing affected employees. But deployers can become providers if they substantially modify the system or rebrand it under their own name.
3
Article 3(6) · Import exposure
Importer — brings an AI system from a third country onto the EU market
An importer is a natural or legal person established in the EU that places on the EU market an AI system that bears the name or trademark of a natural or legal person established outside the EU. Importers take on provider-equivalent obligations for ensuring that the foreign provider has complied with EU AI Act requirements. For most SaaS companies, this role is less common — but it arises when EU-based subsidiaries or distributors formally “place on the market” an AI product originally developed outside the EU.
4
Article 3(7) · Lightest obligations
Distributor — makes an AI system available without modification
A distributor is a natural or legal person in the supply chain that makes an AI system available on the EU market without modifying it. Distributors have the lightest obligations: primarily to verify that the system carries the required CE marking and documentation before making it available, and to take corrective action if they become aware of non-compliance. Distributors become importers or providers if they modify the system, place it under their own name, or put it into service in the EU in ways that go beyond simple resale.
Section 2
Provider vs Deployer: Obligation Comparison
For high-risk AI systems, the obligation sets for providers and deployers are materially different in both scope and burden. Understanding which column you fall into — and whether you fall into both — is the starting point for any EU AI Act compliance programme.
Provider
Article 16 · 9 core obligations
Heavier burden
Deployer
Article 26 · 4 core obligations
Lighter burden
Risk management system
Ongoing process across the entire system lifecycle
Art. 9
Data and data governance
Training, validation and testing data requirements
Art. 10
Technical documentation (Annex IV)
Per-system document before placing on the market
Art. 11
Record-keeping and logging capability
System must be capable of generating logs automatically
Art. 12
Transparency and user information
Instructions for use · limitations · human oversight guidance
Art. 13
Human oversight design
Design measures to enable human intervention and override
Art. 14
Accuracy, robustness and cybersecurity
Testing against performance metrics · adversarial robustness
Art. 15
Quality management system (QMS)
Written policies, procedures and controls for compliance lifecycle
Art. 17
EU database registration + CE marking
Register in EU AI database before placing on market · affix CE mark
Art. 49
Implement human oversight measures
Assign qualified persons · ensure oversight capability is actually used
Art. 26(2)
Retain logs for minimum 6 months
Where deployer has control over logging · subject to applicable law
Art. 26(5)
Fundamental rights impact assessment (FRIA)
Required for bodies governed by public law · certain private deployers
Art. 27
Inform and train affected employees
Workers whose tasks are subject to AI system decisions must be informed
Art. 26(6)
Article 25 — Critical role shift
A deployer becomes a provider if they substantially modify the AI system or place it on the market under their own name. This shift carries the full provider obligation set — including Annex IV technical documentation, conformity assessment, CE marking, and EU database registration. “Substantial modification” includes changes to the intended purpose, changes to the training process, or modifications that affect the system’s performance in ways not anticipated by the original provider.
Section 3
Are You a Provider, Deployer, or Both? Use This Decision Tree
Work through each question to identify your role for a specific AI system in your product or infrastructure. Run this analysis separately for each distinct AI system you use or build.
Role Decision Tree
Article 3 · Article 25 · EU AI Act
Per AI system
1Did you develop this AI system, or have it developed on your behalf?
Yes — we built it or commissioned its development
Includes fine-tuning, training from scratch, or custom model development
→
No — we use a third-party AI system as-is
e.g. OpenAI API, Anthropic Claude, Google Vertex, AWS Bedrock
→
2Are you placing this AI system on the market under your name, or as part of your product?
Yes — it is available to external users under our brand
Sold, licensed, or embedded in a product delivered to customers
→
No — we developed it for internal use only
Used internally, not made available to third parties
→
3Are you using this AI system in a professional context to deliver services to your clients?
Yes — we use it as part of our professional service delivery
AI outputs affect decisions or services delivered to clients or end-users
→
No — we only distribute or resell it without use
No professional deployment under our authority
→
4Have you substantially modified the third-party AI system — changed its intended purpose, retrained it, or placed it on the market under your own name?
Yes — we have modified it or rebranded it under our name
Fine-tuning, prompt engineering affecting intended purpose, or white-labelling
→
No — we use it as-is without modification
No changes to training, architecture, or intended purpose
→
Provider
You are a Provider under Article 3(3)
You developed this AI system and are placing it on the market under your own name. You bear the full Article 16 obligation set: risk management (Art. 9), data governance (Art. 10), Annex IV technical documentation (Art. 11), logging capability (Art. 12), transparency (Art. 13), human oversight design (Art. 14), accuracy and robustness testing (Art. 15), quality management system (Art. 17), and EU registration with CE marking (Art. 49). If the system is high-risk under Annex III, the August 2026 deadline applies. An AI Regulatory Opinion covering your classification and provider obligations is the document enterprise clients and investors will request.
Deployer
You are a Deployer under Article 3(4)
You are using a third-party AI system in a professional context without substantially modifying it. Your obligations are lighter: implement human oversight (Art. 26(2)), retain logs for at least 6 months where you control logging (Art. 26(5)), conduct a Fundamental Rights Impact Assessment if required (Art. 27), and inform affected employees (Art. 26(6)). Important: your contractual arrangements with the provider (Art. 25) should clearly allocate compliance responsibilities. Review your enterprise client contracts for any clause that shifts provider obligations to you — this is increasingly common. See our AI governance service for deployer compliance support.
Now a Provider
You have become a Provider under Article 25
By substantially modifying the third-party AI system or placing it on the market under your own name, you have assumed full provider obligations under Article 25. This includes the complete Article 16 obligation set — Annex IV technical documentation, conformity assessment, CE marking, EU database registration, and post-market monitoring. This is the most common unexpected liability in SaaS companies that customise AI APIs or white-label AI functionality. The original provider’s compliance documentation does not transfer to you — you must produce your own. See the August 2026 deadline for timing and engage AI regulatory counsel immediately to assess your documentation gap.
Distributor / Importer
You are likely a Distributor or Importer
If you make the AI system available on the EU market without modification and without using it under your professional authority, you are a distributor (Art. 3(7)) or, if the system originates from outside the EU, an importer (Art. 3(6)). Distributors must verify CE marking and compliance documentation before making the system available, and must take corrective action if they discover non-compliance. Importers take on provider-equivalent obligations for ensuring the foreign provider has met EU AI Act requirements. If you also use the system professionally, return to Q3 and select the first option.
Section 4
SaaS Scenarios in Practice
The provider/deployer distinction plays out differently depending on how a SaaS company’s product is architected. These three scenarios reflect the most common configurations at Series A–B stage.
1
HR Tech · Annex III
AI-powered CV screening embedded in a recruitment SaaS
Built in-house · sold to enterprise HR teams
Company builds a candidate ranking model trained on historical hiring data
Model is embedded in a SaaS product sold under the company’s brand to enterprise HR departments
HR teams (enterprise clients) use the system to shortlist candidates
Employment-related AI falls squarely within Annex III category 4 (employment, workers management)
Verdict: Provider of a high-risk AI system. Full Article 16 obligations apply. Annex IV technical documentation required. August 2026 deadline.
2
LegalTech · GPAI
Contract analysis tool built on OpenAI API, no custom training
API consumer · no model modification
Company builds a contract review product using OpenAI GPT-4 via API
No fine-tuning or retraining of the underlying model — prompt engineering only
Product delivered under company’s own brand to legal teams at law firms and corporates
Contract review is not an Annex III high-risk category (legal SaaS for document analysis sits outside the enumerated categories)
Verdict: Deployer of OpenAI (GPAI system). Not high-risk under Annex III. Lighter Article 26 obligations apply. GPAI transparency rules (Art. 50) may apply depending on user-facing outputs.
3
FinTech · Article 25 risk
Credit scoring feature built on a fine-tuned foundation model, white-labelled
Fine-tuned third-party model · rebranded
Company takes a third-party credit risk model and fine-tunes it on proprietary loan performance data
The fine-tuned model is white-labelled and sold to banking clients under the company’s brand
Banking clients use it for retail credit decisions — Annex III category 5b (creditworthiness assessment)
The fine-tuning and rebranding trigger Article 25 — the company is no longer a deployer
Verdict: Provider under Article 25 (substantial modification + own-name placement). High-risk system. Full Article 16 + Annex IV obligations apply. The original provider’s documentation does not satisfy this requirement.
Not sure which role applies to your product? WCR Legal prepares role analysis memos and AI Regulatory Opinions that define your provider/deployer position per AI system — the document enterprise legal and procurement teams are requesting before contract execution.
Get a role analysis →
Frequently Asked Questions
EU AI Act provider vs deployer
1
Can a company be both a provider and a deployer at the same time?
+
Yes — and this is the normal situation for most SaaS companies. A company can be a provider of its own AI-powered product (e.g. a proprietary recommendation engine sold to clients) while simultaneously being a deployer of third-party AI systems used internally or in the product’s infrastructure (e.g. using Claude or GPT-4 as the language model without modification). Each AI system must be analysed separately for role classification. The obligations for each role apply independently and concurrently. For an AI system where you hold both roles (rare, but possible in complex architectures), the heavier provider obligations govern.
2
Does prompt engineering count as “substantial modification” under Article 25?
+
The EU AI Act does not define “substantial modification” with precision for the provider/deployer boundary. The recitals and AIOB guidance suggest that the key test is whether the modification affects the intended purpose of the AI system or its performance in a way not anticipated by the original provider. Prompt engineering that stays within the original provider’s documented intended use is generally considered not to trigger Article 25. However, systematic prompt engineering that redirects the model into a new domain (e.g. using a general-purpose language model as a medical diagnosis tool through structured prompts) creates a credible argument for substantial modification. Where the boundary is unclear, a legal opinion is advisable before asserting deployer status to an enterprise client.
3
Our enterprise client is asking us to contractually accept provider obligations — should we?
+
Be cautious. Article 25 allows parties in the supply chain to contractually allocate responsibilities — but such allocation does not eliminate liability toward regulators; it only creates a basis for indemnification between the parties. If an enterprise client asks you as a deployer to contractually assume provider obligations, you are accepting: Annex IV technical documentation responsibilities, conformity assessment obligations, CE marking, EU database registration, and post-market monitoring. This is a material increase in legal exposure that typically requires significant legal review and pricing adjustment. Unreviewed AI Act clauses in enterprise MSAs are one of the most common and overlooked liability risks for Series A–B SaaS companies with EU customers. See our AI governance service for contract review support.
4
What happens if we are a provider but have not registered in the EU AI database by August 2026?
+
Non-compliance with EU AI Act registration and documentation obligations for high-risk AI systems can result in fines of up to €30 million or 6% of global annual turnover (whichever is higher) for providers who place high-risk AI systems on the market without complying with their obligations. Market surveillance authorities in EU member states are the primary enforcement bodies. Additionally, enterprise clients with EU compliance programmes are increasingly requiring evidence of EU AI Act compliance before or at contract renewal — non-registered providers risk losing EU enterprise contracts independently of regulatory enforcement. See the August 2026 deadline overview for the full enforcement timeline.
5
We are based outside the EU but have EU customers — do provider obligations apply to us?
+
Yes. The EU AI Act applies to providers that place AI systems on the EU market regardless of where the provider is established — the same jurisdictional model as GDPR. A non-EU provider placing a high-risk AI system on the EU market must comply with all Article 16 obligations and must appoint an EU authorised representative under Article 22 (a natural or legal person established in the EU designated by the provider to act on their behalf regarding EU AI Act compliance). Failure to appoint an authorised representative is itself a violation. This is a common oversight for US-based SaaS companies with EU enterprise customers. An AI Regulatory Opinion can confirm your jurisdictional exposure and the authorised representative requirement.
Know Exactly Which Role You Hold — Before Your Enterprise Client Does
WCR Legal prepares role analysis memos and AI Regulatory Opinions that document your provider/deployer position per AI system. Founders use these to respond to enterprise DD questionnaires, satisfy investor requests, and build their pre-term-sheet data rooms. Our AI governance service also covers the full compliance programme once your role is confirmed.
Post Comment