Provider vs deployer under Article 50: what website owners still need to do
Read Article 50 closely and you hit an uncomfortable sentence. The chatbot rule — Article 50(1) — is addressed to providers: "Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system."
If you bought your chat widget off the shelf, you did not design or develop it. So a reasonable person reads that and concludes the duty sits with the vendor, not with them. That reading is half right, and the half that is wrong is the expensive half. This page walks the definitions, shows which of the four Article 50 duties lands on which role, and — the part most write-ups skip — explains why the role label does not change what a regulator sees when they open your site.
The two definitions, as the Act writes them#
Both roles are defined in Article 3, and the wording matters more than the labels suggest.
A provider (Art. 3(3)) is a person or body 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.
A deployer (Art. 3(4)) is a person or body using an AI system under its authority, except in the course of a personal, non-professional activity.
Two things follow immediately. First, "deployer" covers essentially every business running an AI feature on its website — there is no size threshold and no exemption for using someone else's product. Second, the provider definition has two limbs, and the second one — has an AI system developed — catches far more companies than teams expect.
Which role are you? Four common cases#
| What you run | Your role | Why |
|---|---|---|
| Off-the-shelf chat widget, configured in the vendor's dashboard | Deployer | You did not develop it and did not have it developed. The vendor placed it on the market. |
| A bot an agency built for you, shipped under your brand | Likely provider | You had an AI system developed and put it into service under your own name — both limbs of Art. 3(3). |
| A bot your team built on a model API (OpenAI, Anthropic, Mistral) | Provider | You developed the AI system. The model vendor is the GPAI-model provider; the system on your site is yours. |
| A vendor's bot rebranded with your logo and persona name | Deployer, usually | Rebranding alone is not developing. But see the caution below — this is the case worth getting advice on. |
The rebranding row is the genuinely uncertain one. Article 25, which converts a deployer into a provider when it puts its name or trademark on a system, applies to high-risk AI systems, and a customer-service chatbot is normally a transparency-tier system rather than a high-risk one — so Article 25 is not the mechanism that catches you. What can catch you is the Article 3(3) definition itself, if your arrangement with the vendor looks less like buying a product and more like having a system developed for you and putting it into service under your own name. If your bot is materially yours in everything but the code, that is a question for counsel, not for a blog post — ours included.
Which duty lands on which role#
This is the table that resolves most of the confusion, because the four paragraphs of Article 50 do not all point the same way.
| Duty | Falls on | What it requires |
|---|---|---|
| 50(1) Chatbot / AI-interaction disclosure | Provider | Systems that interact directly with people must be designed and developed so people are informed they are dealing with AI. |
| 50(2) Machine-readable marking of synthetic output | Provider | Generative outputs — audio, image, video, text — marked machine-readably and detectable as artificially generated. |
| 50(3) Emotion recognition / biometric categorisation notice | Deployer | People exposed to the system must be informed it is in operation. |
| 50(4) Deepfake and public-interest AI-text labels | Deployer | Visible disclosure that the content was artificially generated or manipulated. |
| 50(5) How all of the above must be delivered | Both | Clear and distinguishable, at the latest at the time of the first interaction or exposure. |
So a website owner running a third-party chat widget is a deployer, and the chatbot design duty is textually on the vendor. Two duties, 50(3) and 50(4), are unambiguously and directly yours, whatever your chat stack looks like. And 50(5) — the how — applies to everything in 50(1) to 50(4).
Why "the vendor handles it" is still the wrong plan#
Four reasons, in the order they tend to bite.
The provider's duty is discharged through a setting you control. Vendors satisfy Article 50(1) by building the capability: a configurable AI-disclosure line, an "AI assistant" label, a pre-chat notice. The provider has shipped a system that can inform the user. Whether it does inform the user on your site depends on the greeting text in your dashboard — and the most common finding in any external check is that the capability exists and is switched off, softened, or overwritten with a friendlier line.
The output is yours regardless of whose duty it was. National market-surveillance authorities enforce against what is on a website. When your chat opens and says nothing about being AI, the object of the complaint is your page under your domain. Sorting out who was obliged to prevent it is a later conversation, and one you have from a worse position without a record.
Two of the four duties never belonged to the vendor. If you publish AI-assisted articles on matters of public interest, or any deepfake-class media, 50(4) is a deployer duty and it is yours. No chat vendor's compliance page covers it. See whether AI-written articles need a label.
Your role can change without you noticing. The line between "configured a product" and "had a system developed" moves when you replace the vendor's model with your own, bolt on retrieval over your own corpus, or commission custom conversation logic. Nobody sends a notification when that happens.
What a deployer should actually do#
Nothing here requires you to resolve the role question first — which is the point. These hold either way:
- Verify the disclosure at first interaction, from the visitor's side, on desktop and mobile separately. Not in the vendor's settings screen: in a private window on the live site. See how to audit a chatbot disclosure.
- Get the vendor's position in writing. Ask which paragraph of Article 50 they consider themselves to satisfy, and how. A vendor that answers precisely is telling you which duties remain yours; a vendor that answers with "we're fully compliant" has told you nothing.
- Handle 50(3) and 50(4) yourself. They are deployer duties and no widget setting addresses them.
- Keep dated evidence of what your site showed. Configuration state is not evidence of what a visitor saw, and a vendor's release notes are not evidence about your site.
The uncomfortable asymmetry#
An authority checking Article 50 does not need your source code, your DPA, or your vendor contract. They open your site, start a chat, and read the first message — the same check a competitor can run before filing a complaint, and the same one we automate. What they cannot see from outside is what your site showed last quarter, and that direction of proof runs the other way: it is on you to evidence it. That is why proving a disclosure was live on a given date is a separate problem from getting the wording right, and why role labels are the wrong thing to spend your remaining time on.
Common questions
If Article 50(1) binds providers, does my company have to do anything?
Yes. Vendors satisfy Article 50(1) by building the capability — a configurable disclosure line, an AI label, a pre-chat notice — and whether it reaches your visitors depends on settings you control. The most common finding in any external check is a disclosure that exists in configuration and is switched off, softened or overwritten. Two further duties, Article 50(3) and 50(4), fall on deployers directly and no chat vendor addresses them.
Does putting our logo and persona on a vendor's chatbot make us the provider?
Usually not by itself. Article 25, which converts a deployer into a provider when it puts its name or trademark on a system, applies to high-risk AI systems, and a customer-service chatbot is normally a transparency-tier system instead. What can catch you is the Article 3(3) definition itself, which covers anyone who has an AI system developed and puts it into service under their own name. If your bot is materially yours in everything but the code, that is a question for counsel.
We built our chatbot on the OpenAI or Anthropic API. What are we?
A provider of the AI system you built, in all likelihood: you developed it and put it into service under your own name, which is what Article 3(3) describes. The model vendor is the provider of the general-purpose AI model; the system running on your site is yours, and the Article 50(1) design duty comes with it.
Which Article 50 duties fall on deployers?
Article 50(3), the notice for emotion-recognition and biometric-categorisation systems, and Article 50(4), the visible labels for deepfakes and for AI-generated text published to inform the public on matters of public interest. Article 50(5), which requires the information to be clear, distinguishable and delivered at the latest at the first interaction or exposure, applies to everything in paragraphs 1 to 4.
Can we rely on our vendor's compliance statement?
Get it in writing and read it precisely. Ask which paragraph of Article 50 the vendor considers itself to satisfy, and how. A vendor that answers specifically is telling you which duties remain yours; one that answers "we are fully compliant" has told you nothing you can use. Either way, the page a regulator opens is on your domain.
Sources and further reading
- Article 3 — Definitions (EU AI Act)
- Article 25 — Responsibilities along the AI value chain
- Article 50 — Transparency obligations
Last updated September 2026. Informational only, not legal advice: this page describes what the text of the EU AI Act says and what an external check can observe, not whether any particular site complies. Corrections welcome at hello@disclosureproof.com.