EU AI Act Article 50: The Transparency Rules That Are Live Now

Why this is suddenly urgent and was not last month

For two years the EU AI Act conversation was dominated by the high-risk control set, and almost everything written about it pointed at 2 August 2026 as the date everything landed. That is not what happened.

The Digital Omnibus on AI, in force since 27 July 2026, deferred the high-risk obligations: standalone Annex III systems moved to 2 December 2027 and product-embedded Annex I systems to 2 August 2028. It deferred Article 50 by exactly nothing. So the obligation that most teams were treating as the minor one, the transparency rules, is the obligation that is actually enforceable today, and the one everybody spent two years preparing for is now a 2027 problem.

The result is a genuine compliance gap. Article 50 applies to ordinary products, not to exotic high-risk ones. If you ship a chatbot, generate images, draft text for publication, or analyse faces or voices, it applies to you. The scope is far wider than the high-risk annexes and the awareness is far lower.

A necessary disclaimer, and I mean it: I am an engineer, not a lawyer. Classification and legal sign-off belong with your counsel. What follows is the builder's reading, which is what you need in order to know what to put in the sprint.

The four obligations, and who carries each

Article 50 is four distinct rules, not one. Two land on the provider, meaning whoever places the AI system on the market. Two land on the deployer, meaning whoever uses it in their own operations.

That split is the part teams get wrong. A startup building a product on the OpenAI API is normally the provider of its own AI system and the deployer of it at the same time, which means all four can apply simultaneously. Calling someone else's model does not shift a single one of these onto the model vendor; they carry the separate general-purpose AI model obligations, and you carry these.

50(1): the AI disclosure, which is the easy one

Article 50(1) requires that a natural person interacting with an AI system is informed of that fact, at the latest at the point of first interaction. For a chatbot that means a clear label or an opening message. It must be clear and distinguishable and meet applicable accessibility requirements, which rules out the obvious dodges: grey text in a footer, a faint watermark behind the conversation, or a disclosure that flashes past on load.

There is one exemption and it is narrower than it sounds. Disclosure is not required where AI involvement is obvious from the point of view of a reasonably well-informed, observant and circumspect person. A widget labelled "AI assistant" sitting inside a product page probably qualifies. A support chat that opens with "Hi, I'm Sarah" emphatically does not, and giving a bot a human first name is the fastest way to convert an easy compliance item into a clear breach.

Engineering effort: a few hours. There is no grace period on this one, so if it is not shipped it should be this week's work.

50(2): machine-readable marking, which is the hard one

This is where the real work is, and where the 2 December 2026 date applies. Article 50(2) requires providers of systems that generate synthetic audio, image, video or text to ensure the output is marked in a machine-readable format and detectable as artificially generated or manipulated. The marking must be effective, interoperable, robust and reliable, taking implementation cost and the state of the art into account.

A visible caption in your interface does not satisfy this. That is the single most common misreading and it is worth being blunt about: a rendered label is not machine-readable, it is not attached to the file, and it does not survive a download. The obligation is about the artefact, not about your interface.

The Act names no specific technology. In practice, three layers together are the defensible implementation, and no single one of them satisfies all four adjectives on its own.

1. Provenance metadata. C2PA Content Credentials are what the industry has converged on: cryptographically signed provenance embedded in the file, stating what generated it and when. This is the interoperable layer, because other systems can read it without any agreement with you.
2. An invisible watermark. Metadata is stripped by re-encoding, by screenshotting, and by most social platforms. A perceptual watermark survives more of that, which is the robustness layer.
3. A server-side provenance log. A record of what your system generated, when, and for whom, queryable after the fact. This is the layer that answers a regulator or a customer when both of the others have been stripped, and it is the cheapest of the three to build.

For synthetic text, this is genuinely unsettled: robust, interoperable text watermarking is not a solved problem at the state of the art, and the Act's cost and state-of-the-art qualifier is doing real work there. The pragmatic position I take with clients is to implement the provenance log unconditionally, because it is cheap and it is the evidence layer, and to apply metadata and watermarking where the modality supports it.

50(3): emotion recognition and biometric categorisation

If you deploy a system that infers emotions from a face or a voice, or that categorises people biometrically, you must inform the people exposed to it, and you must do so in line with GDPR as well. Note that this is a deployer obligation, so it lands on the company running the system in its operations rather than on whoever built it.

Worth flagging a boundary here that catches people out: emotion recognition in the workplace and in education is not merely a transparency obligation, it is a prohibited practice under Article 5, and prohibitions have applied since February 2025. If you are analysing employee or student sentiment from video or voice, the question is not how to disclose it.

50(4): deepfakes and public-interest text

Two things bundled into one paragraph of the Act, both landing on the deployer.

Deepfakes. Content that appreciably resembles real people, places, or events and would falsely appear authentic must be disclosed as artificially generated. Critically, this applies regardless of intent: there is no exemption for benign or commercial purposes. If you generate on-model fashion imagery using a likeness, synthetic voice for an advert, or a face-swapped product demo, this is your obligation. For artistic, creative, satirical or fictional works the requirement softens to disclosing the existence of generated content in an appropriate manner that does not spoil the work, which is a real accommodation but a narrow one.

Public-interest text. AI-generated text published to inform the public on matters of public interest must be disclosed as AI-generated. The exemption is substantive: the obligation falls away where the content underwent meaningful human review and a natural or legal person holds editorial responsibility for it. So a newsroom with an editor in the loop is in a different position from an automated content pipeline publishing unreviewed.

What to actually put in the sprint

Ordered by deadline and by cost, which conveniently agree.

The provenance log is the item I would push hardest, because it is the cheapest thing on the list and it is the one that answers questions from every direction: a regulator, an enterprise security review, a customer dispute, or a GDPR data-subject request. It is also the same logging you want for observability anyway, so it is rarely wasted work.

How this relates to the rest of the Act

Article 50 is the obligation that is live. It is not the whole Act. The wider builder's guide covers the risk tiers, what the Digital Omnibus deferred and to when, and the high-risk control set that arrives in December 2027. If any of your systems are high-risk, that is a programme of work to start scoping this year rather than that one, and human-in-the-loop design is where most of it begins.

And if you are shipping a moderation or classification system, the overlap with content moderation architecture is substantial: the logging, appeal path, and oversight controls serve both regimes at once.

Frequently asked questions

What does Article 50 require?

Four obligations: disclose AI interaction, machine-readably mark synthetic content, inform people subject to emotion recognition or biometric categorisation, and disclose deepfakes and AI-written public-interest text.

Which fall on the provider and which on the deployer?

50(1) and 50(2) on the provider; 50(3) and 50(4) on the deployer. A startup building on a third-party model is usually both at once, so all four can apply.

When is the deadline?

Article 50 has been enforceable since 2 August 2026 and was not deferred by the Digital Omnibus. Systems already on the market before that date have until 2 December 2026 for the machine-readable marking obligation only.

What counts as a machine-readable mark?

No technology is named. C2PA Content Credentials plus an invisible watermark plus a server-side provenance log is the defensible layered implementation, because no single technique is effective, interoperable, robust and reliable on its own.

Is a visible "generated by AI" label enough?

Not for 50(2). A rendered caption is not machine-readable and does not survive a download. It may help with the separate deepfake disclosure in 50(4).

What are the penalties?

Up to 15 million euros or 3 percent of worldwide annual turnover. National authorities gained inspection powers on 2 August 2026. The more likely near-term cost for a startup is a failed enterprise procurement.

Bottom line

Article 50 is live, it applies to ordinary products rather than exotic ones, and awareness of it is low precisely because everyone spent two years preparing for the high-risk rules that got deferred instead. The disclosure work is hours. The marking work is days, and has a real deadline of 2 December 2026 if your system predates August. The provenance log is cheap and answers more questions than any other single thing you can build.

If you want the engineering done rather than the regulation explained, that is what my EU AI Act compliant development work is. I do the build half and your counsel does the legal half.