All guides

Jul 10, 2026 · 8 min read

AI Act Provider vs Deployer: Who Owns Article 50 in 2026

If you ship AI features into the EU, the first Article 50 question is not "what must we disclose?" but "which role are we playing?" This guide explains the AI Act provider vs deployer split, shows how one team can hold both roles at once, and gives you a decision guide that maps what you actually do with an AI system to the transparency duty that lands on you. It is not legal advice; for determinations that carry real consequences, talk to counsel.

Two dates anchor everything below. Article 50's transparency obligations start to apply on 2 August 2026. A limited transition can push provider-side machine-readable marking to 2 December 2026 for eligible systems already on the market before the general application date.

Provider vs deployer: the split that decides your duties

The AI Act does not assign obligations to companies. It assigns them to roles attached to a specific AI system. The same organisation can be a provider of one system and a deployer of another, so the honest unit of analysis is per product, not per company.

  • 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.
  • A deployer uses an AI system under its own authority in the course of its activity — running it for real users, in production.

Article 50 splits the four transparency obligations along exactly this line. Two land on providers, two land on deployers.

The two provider duties

  • Art. 50(1) — where an AI system is intended to interact directly with people (chatbots, voice assistants), the provider must design it so people are informed they are dealing with an AI, unless that is obvious to a reasonably observant, well-informed person in the circumstances.
  • Art. 50(2) — providers of systems that generate synthetic audio, image, video or text must mark that output as artificially generated or manipulated in a machine-readable format, and make the marking detectable. This is the duty most likely to use the transition window to 2 December 2026.

The two deployer duties

  • Art. 50(3) — deployers of emotion-recognition or biometric-categorisation systems must inform the people exposed to them, and process any personal data in line with the GDPR and other applicable law.
  • Art. 50(4) — deployers must disclose deepfakes (AI-generated or manipulated image, audio or video), and disclose AI-generated or manipulated text published to inform the public on matters of public interest. Narrow exceptions exist — for example where a human keeps editorial responsibility for published text, or for evidently artistic, creative or satirical work, where disclosure is scaled so it does not spoil the work.

Notice the symmetry: providers build the marking *into* the output; deployers make the human-facing *disclosure* at the point of use. The provider's machine-readable mark under 50(2) does not discharge the deployer's plain-language disclosure under 50(4), and vice versa. On many products, both duties apply to the same piece of content and both parties have work to do.

The same team is often both — and that is normal

Because roles attach to systems, a single team routinely wears both hats. If you *build* a generative feature and put it on the market under your brand, you are its provider (50(1)/50(2)). If you also *run* that feature to produce content you publish or expose to users, you are its deployer for those uses (50(3)/50(4)). Wearing both hats is not a mistake to avoid; it is the default for most product teams, and it means you should walk each AI system through both provider and deployer questions rather than picking one label for the whole company.

Using a third-party model API does not remove your duties

A common assumption is that building on OpenAI, Anthropic or another hosted model pushes the obligations upstream. It does not. Calling a third-party model API does not remove the duties attached to the AI system *you* provide or deploy. You have taken someone else's model and built a system around it — your prompts, your interface, your outputs, your users. The transparency duties for that system are yours.

Two clarifications matter here:

1. Fine-tuning does not automatically make you the model's provider. Modifying or fine-tuning a general-purpose model does not, by itself, turn you into the provider of that underlying model. 2. "Significant" modification is the edge case. A significant modification can trigger a separate general-purpose AI (GPAI) assessment and shift some provider obligations onto you. Where the line sits is genuinely a question for counsel — see the Commission's guidance on obligations for GPAI providers. Treat heavy fine-tuning or retraining as a flag to get advice, not a call to make alone.

Either way, your Article 50 duties for the system you ship do not disappear because the weights came from someone else.

Scope reaches outside the EU

Role, not geography, is the trigger — but geography still catches you. The obligations reach providers and deployers outside the EU when their systems are placed on the EU market or when the system's output is used in the EU. A US-based team with EU users is squarely in scope. See the EU Commission's Article 50 service desk for the official framing.

Decision guide: what you do → which duty is yours

Walk each AI system in your product through these questions. Answer them per system, and expect several to apply at once.

1. Do you place this AI system on the EU market or put it into service under your own name? If yes, you are a provider for it — carry on to questions 2 and 3. 2. Does it interact directly with people? If yes and the AI nature is not obvious, Art. 50(1) applies: build in an "I am an AI" signal. 3. Does it generate synthetic audio, image, video or text? If yes, Art. 50(2) applies: mark the output as artificial in a machine-readable format (transition to 2 December 2026 may apply). 4. Do you run this AI system in production under your own authority? If yes, you are a deployer for it — carry on to questions 5 and 6. 5. Is it an emotion-recognition or biometric-categorisation system? If yes, Art. 50(3) applies: inform the exposed people and handle personal data under the GDPR. 6. Does it produce deepfakes, or AI text you publish to inform the public on matters of public interest? If yes, Art. 50(4) applies: disclose it (subject to the narrow editorial and artistic exceptions).

If you answered yes to questions in both halves for the same system, you hold both roles for it — again, the normal case.

Worked example: one company, two roles

Take a fictional company, "Northwind", with two products.

Product A — an AI writing assistant Northwind builds and sells. Northwind develops the assistant, wraps a third-party model in its own interface, and sells it under the Northwind brand. For Product A, Northwind is the provider:

  • Art. 50(1): the assistant chats with users, so it signals that they are talking to an AI.
  • Art. 50(2): it generates text and images, so Northwind marks that output as AI-generated in a machine-readable format.
  • The third-party model underneath changes none of this. Northwind placed the *system* on the market under its own name.

Product B — an internal newsroom tool a media client runs on Northwind's platform. Here Northwind's customer uses an AI system in production to draft and publish public-interest articles and to generate illustrative images. For Product B, that customer is the deployer:

  • Art. 50(4): it discloses AI-generated images that qualify as deepfakes, and discloses AI-generated public-interest text — unless a human editor retains editorial responsibility, in which case the narrow exception may apply. That judgement belongs to the customer and its counsel.

Same underlying technology, two different roles, two different obligation sets — decided per product. If Northwind *also* ran the assistant to publish its own marketing blog, it would pick up deployer duties for *that* use on top of its provider duties for the product itself.

Machine-readable marking is metadata, not proof

One caution before you build. The machine-readable marking expected under Art. 50(2) — HTML attributes, JSON-LD, header metadata — is advisory metadata, not signed provenance. It is not C2PA content credentials and should not be treated as sufficient on its own; it can be stripped or lost as content moves between platforms. There is a voluntary EU Code of Practice on transparency of AI-generated content that can help you shape a more robust approach. Use the marking as one layer, and keep a record of what you mark and how.

For a plain-language walk-through of the article itself, the artificialintelligenceact.eu explainer on Article 50 is a useful companion to the official text.

Next step

Map every AI system in your product against the six questions above, note the role and the duties for each, and write down where a third-party model or a heavy fine-tune might need counsel. If you want a structured starting point, run DiscloseKit's free readiness check to see which Article 50 duties a given system is likely to touch — an operational review to inform your work, not a substitute for legal advice or a claim that any product is "compliant." The Act and official guidance, not this article, decide what is enough.

See exactly what applies to your product

Run the free check

Sources

This is compliance tooling, not legal advice. Consult counsel for your specific case.