EU AI Act Article 50: what your AI product has to disclose

You added a chat assistant to your site. Or you generate product photography through an API. Or you publish posts that a model drafted and you tidied up. Since 2 August 2026, the European Union’s transparency rules for AI systems have applied to all three [1]. They are not the high-risk machinery that most of last year’s coverage was about. They are one article, Article 50, carrying four short disclosure duties, and they were drafted to catch ordinary software rather than frontier labs.

The uncomfortable part is where the duty lands. It usually sits on you rather than on the vendor whose model you are calling, and the compliance date that matters most this autumn is not the one that got the headlines. None of what follows is legal advice, and none of it is aimed at people building hiring, credit scoring, biometric identification or medical triage tools. Those sit in the high-risk regime, which Article 50 explicitly leaves untouched [1] and which asks for far more than a disclosure notice.

Article 50 reaches you through your users, not your address

The Act applies to providers placing AI systems on the Union market “irrespective of whether those providers are established or located within the Union or in a third country” [2]. It also applies to providers and deployers based in a third country “where the output produced by the AI system is used in the Union” [2]. There is no revenue floor and no headcount floor anywhere in that. A two-person studio in Toronto with paying customers in Berlin sits inside the same article as a company with a compliance department.

The stakes are set in Article 99, which puts Article 50 infringements in the middle penalty tier, up to 15 million euros or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher [4]. Small and medium enterprises, including start-ups, get the inverse rule: for them the fine is the lower of those two figures rather than the higher [4]. Member States report the fines they issue to the Commission [4].

Those numbers are ceilings, not price lists, and a solo operator is not the target of a 15 million euro penalty. The realistic risk is duller and more likely. Someone asks you to explain how your product handles AI disclosure, and you have nothing written down. That is a bad afternoon for a company with a legal team and a worse one for a company without.

Putting your name on someone else’s model makes you its provider

Article 3 defines a provider as anyone who develops an AI system, or has one developed, and “places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge” [3]. Read the last clause slowly. Training a model is not the trigger. Your name on the thing is the trigger, and free products count.

A deployer, by contrast, is anyone “using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity” [3].

Run your own product through that. If you wire Claude, ChatGPT or Gemini into a support assistant and ship it as YourCompany Assistant, you are the provider of that assistant, and the provider duties in Article 50(1) and 50(2) are yours. The model vendor is also a provider, of its own system. That does not transfer your obligation, it only means some of the plumbing you need may already exist. If instead your team uses a bought tool internally, or you run a third party’s branded widget on your site under their name, you are the deployer, and 50(3) and 50(4) are the paragraphs to read. If you are using ChatGPT to draft your own emails, that is personal non-professional activity and falls outside the deployer definition entirely [3].

Most real products contain more than one party, which is why the Commission’s guidelines spend time clarifying who does what across the value chain [6]. It is worth doing that mapping once, feature by feature, and keeping the result. A product can easily be a provider of one system and a deployer of another.

The four disclosures, and which two are probably yours

Article 50(1) is a provider duty. AI systems intended to interact directly with people must be designed so those people are informed they are interacting with an AI system, unless that is “obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use” [1].

Article 50(2) is also a provider duty, and it is the expensive one. Providers of AI systems generating synthetic audio, image, video or text must ensure the outputs are “marked in a machine-readable format and detectable as artificially generated or manipulated” [1]. The technical solution has to be “effective, interoperable, robust and reliable as far as this is technically feasible” [1]. There is a carve-out where the system performs “an assistive function for standard editing” or does not substantially alter the input data or its semantics [1]. Spell-check and auto-levels are out of scope. A model that writes the paragraph or fills in the background is in.

Article 50(3) is a deployer duty covering emotion recognition and biometric categorisation systems, which most small operators do not run [1].

Article 50(4) is the deployer duty most likely to catch a publisher. Deploy a system that generates or manipulates a deep fake and you must disclose that the content is artificially generated or manipulated [1]. A deep fake is defined as image, audio or video content resembling real people, places, entities or events that “would falsely appear to a person to be authentic or truthful” [3]. For evidently artistic, creative, satirical or fictional work the duty narrows to disclosing that generated content exists [1]. And where you publish AI-generated text to inform the public on matters of public interest, you must disclose that too, unless the text “has undergone a process of human review or editorial control and where a natural or legal person holds editorial responsibility” [1]. That exception is the reason to name an editor rather than to argue about whether your blog counts.

Article 50(5) sets the timing for all of it. The information has to arrive “in a clear and distinguishable manner at the latest at the time of the first interaction or exposure”, and it has to meet the applicable accessibility requirements [1]. A clause in your terms of service is not first exposure.

Machine-readable marking is a purchasing decision before it is an engineering one

If you ship a generator under your own name, 50(2) is yours, but you are almost certainly not going to build a watermarking scheme. The actual work is checking what your vendor emits and whether it survives the trip to your user.

Take OpenAI’s published position as the worked example. Supported images generated with ChatGPT, Codex and the OpenAI API carry both C2PA metadata and SynthID watermarks [8]. The same document carries two caveats you should copy into your notes. Coverage “can vary by product, model, export path, file type, and when the content was created” [8]. And the metadata can be “removed by platforms, editing tools, or file conversions” [8]. OpenAI also states plainly that provenance signals “are not a guarantee that content is accurate, unedited, legally owned, or presented in the correct context” [8].

So do two things. Get the answer in writing for every generating model you call, including which output formats and which export paths are covered. Then test your own pipeline end to end. Generate an image, run it through your resize step, your WebP conversion and your CDN, download it back the way a customer would, and check whether the credential is still attached. If your image pipeline strips metadata, you have taken a marked output and shipped an unmarked one under your own name [3]. That is a self-inflicted gap and it is cheap to close once you know it exists.

Text is where this gets thin, and the article does not exempt text [1]. If your product generates prose for someone else to publish, treat the marking question as open and document what you did about it.

The date that still matters is 2 December 2026

Article 111 carries a transitional provision that most summaries skip. Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content that were placed on the market before 2 August 2026 “shall take the necessary steps in order to comply with Article 50(2) by 2 December 2026” [5].

That is the deadline worth putting in a calendar right now. If your generator predates 2 August 2026, the marking duty has a stated compliance date rather than an immediate one, and you have the rest of the year to use. Two things it does not do. It does not cover 50(1) or 50(4), which are already live. And it does nothing for anything you shipped after 2 August 2026, which was expected to comply on arrival [5].

The Code of Practice is the cheapest way to show your work

Article 50(7) gives the Commission a route to encourage codes of practice for marking and labelling generated content [1]. That produced the Code of Practice on Transparency of AI-Generated Content, published in final form on 10 June 2026 after a drafting process that began in November 2025 [7]. The Commission and the AI Board have confirmed the code is “an adequate voluntary tool” for demonstrating compliance, while signing it stays optional [7]. Roughly 190 organisations had signed by the end of July 2026 [7].

It is organised the way the article is. One section covers providers, on marking outputs in machine-readable formats and keeping generated content detectable. The other covers deployers, on labelling deep fakes and disclosing AI-generated text on matters of public interest that has not been editorially reviewed [7]. It also points at an EU set of icons for labelling generated content, which is more useful than it sounds when your alternative is designing a disclosure badge from scratch [7].

Signing is not the only route. The guidelines are explicit that an organisation choosing not to adhere to the code may demonstrate compliance through other adequate means [6]. But writing your own equivalent means writing your own equivalent, and defending it later. For a team of three, adopting a code that 190 organisations already accepted is the cheaper path by a wide margin.

What still goes wrong

The marking duty degrades the moment content leaves your control. C2PA-style credentials live in metadata, and metadata is removable by platforms, editing tools and file conversions [8]. A user who screenshots your generated image now holds an unmarked copy, and nothing in your stack prevents that. Article 50(2)‘s qualifier, “as far as this is technically feasible” [1], is the clause everyone is leaning on, and neither the article nor the guidelines convert it into a threshold you can test against. Do the available work, keep the evidence, and accept that the standard is currently one of effort rather than outcome.

The “obvious” exception in 50(1) is a judgment call dressed as a legal standard [1]. A widget labelled AI assistant on a support page is probably obvious to a reasonably observant person. A voice agent answering your phone line in a natural voice probably is not. Most products sit somewhere between those two, and the guidelines offer definitions, exemptions and worked examples [6] without removing the judgment. At the margin you are still deciding, and the useful discipline is writing down why you decided it, dated, before anyone asks.

Finally, the honest limits of a checklist. Article 50 is the shallow end. If your product touches employment, credit, biometrics, essential services or elections, Chapter III’s high-risk obligations are the larger problem and Article 50 does not displace them [1]. And penalties are set by national authorities under Article 99 [4], which means the practical enforcement picture will vary across member states for some time. Treat this guide as the map of what the text requires, then get advice sized to what you actually ship.