Regulatory roles
EU AI Act provider vs deployer roles
The organisation's role is determined by what it does with a particular AI system. A company can be a deployer for one system and a provider for another.
Prepared by EU AI Fit editorial team · Published 24 August 2026 · Source review 31 August 2026 · Page updated 24 September 2026
When are you likely to be a provider?
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 trade mark. Substantial modification or changing an intended purpose can also affect the role analysis.
When are you likely to be a deployer?
A deployer uses an AI system under its authority in a professional context. Buying a third-party AI product does not remove responsibility for how the organisation configures, monitors and uses it.
What should the role record contain?
Record the system, contractual chain, branding, intended purpose, configuration, modifications and operational control. Explain the conclusion, list unresolved facts and identify who approved it.
In this scenario: one organisation, two roles to investigate
Meridian Support uses a purchased assistant internally and separately develops a branded customer-facing service. Do not apply the same role conclusion to both simply because they share a model. For each use, draw the supply chain, identify whose name appears on the system and establish who determines the intended purpose. Changes to a high-risk system may need specific Article 25 analysis; ordinary configuration is not automatically a provider-role change.
When the answer is not yet known
A contract that calls every customer an ‘end user’ does not settle the regulatory question. Ask the product owner for branding and purpose, engineering for the extent of modifications, and procurement for the supply arrangement. Record competing interpretations and the missing fact that would resolve them. Approval should attach to the scoped system and facts, not to a permanent company-wide label.
Role decision record
Use these prompts to assemble the facts for review. A general-purpose model and the downstream system built with it may require separate analysis.
Download editable worksheet (CSV)No email or account required. Includes response, evidence, owner, review and follow-up columns for your team. This is a working aid, not an official form or proof of compliance.
On smaller screens, scroll the table horizontally or download the worksheet.
| Question | Record | Review consequence |
|---|---|---|
| What system and purpose are being assessed? | Boundary, outputs and affected decisions | Separate materially different uses |
| Who develops or commissions the system? | Legal entities and contractual chain | Investigate provider responsibilities |
| Under whose name is it supplied or put into service? | Branding and market/use evidence | Check against the actual operator definition |
| Who uses it under their authority? | Deployment entity and professional use | Investigate deployer responsibilities |
| What has changed? | Purpose, modification, version and decision influence | Review Article 25 where relevant; do not assume every change transfers roles |
| Who approved the conclusion? | Sources, reasoning, open facts and date | Reassess if a decisive fact changes |
Recommended next step
Assess the role separately for each system and use case; do not apply one organisation-wide label.
Run the free exposure checkRelated practical guides
Put the guidance into practice