Article 50 provider vs deployer: which obligations apply?

Why the role decision matters

Article 50 does not assign one generic transparency task to every organisation that touches AI. Provider duties and deployer duties cover different parts of the value chain. A role record is the starting point for a defensible control map.

Provider signals

The official guidance describes a provider as a person or organisation that 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.

Provider signals can include:

• your company name or trademark is attached to the system;
• you determine the intended purpose and release the system to customers;
• a contractor or upstream vendor builds components for a system sold under your brand;
• you substantially modify or rebrand an upstream system in a way that changes the role analysis.

Using a third-party model API does not automatically settle the question. A SaaS company can be a provider of the customer-facing AI system even when another company provides the underlying general-purpose model.

Deployer signals

A deployer uses an AI system under its authority in a professional activity. Examples may include a company using an AI tool to publish content, operate a customer-facing workflow, or expose people to emotion recognition or biometric categorisation.

Employees acting under the organisation's control are generally not separate deployers for each use. The organisation remains the relevant unit for documenting ownership and controls. Purely personal, non-professional activity is treated differently in the Act.

How the Article 50 duties differ

Provider-oriented controls can include:

• designing directly interactive systems so people are informed that they are interacting with AI;
• adding effective machine-readable marking to generated or manipulated outputs where Article 50(2) applies;
• ensuring the information is clear, distinguishable and accessible.

Deployer-oriented controls can include:

• informing exposed people about emotion recognition or biometric categorisation systems;
• visibly disclosing deepfake content;
• disclosing certain AI-generated or manipulated text published to inform the public on matters of public interest, subject to the specific exception conditions.

Mixed-role example

A software company builds and sells a branded customer-support chatbot. It may be the provider of that chatbot and should assess the interaction-disclosure design. The same company uses a third-party generative tool to create a synthetic executive video for its own campaign. For that separate use, it may also be the deployer responsible for a visible deepfake disclosure.

Do not store one organisation-wide answer such as "we are a deployer." Record the role per AI system, use case and output flow.

Questions to record

1. Who developed the system and who determined its intended purpose?
2. Whose name or trademark appears on the system?
3. Who offers or puts it into service in the EU?
4. Who operates it and controls the professional use?
5. Does another party white-label, resell or substantially modify it?
6. Which party controls the interaction design and output pipeline?
7. Has the answer been reviewed after product or supplier changes?

Evidence for the role decision

Keep architecture diagrams, supplier contracts, product branding, release ownership, intended-purpose documentation and a dated rationale. Link the rationale to the exact controls assigned to each role. Escalate ambiguous white-label, reseller and multi-party arrangements for qualified professional review.

Article 50 Hub separates declared facts, technical control suggestions and professional review so the role decision remains inspectable rather than becoming an unexplained score.