The transparency obligations in Article 50 of the EU AI Act, Regulation (EU) 2024/1689, apply from 2 August 2026. Most of what has been written about them is either a summary of the whole regulation or a legal analysis written for people who already know the regulation. This is neither. It is a plain reading of what Article 50 asks a publishing team to do.
What changed, and when
The AI Act entered into force in 2024. Its obligations do not all start at once. They phase in on a schedule set out in the regulation itself, and 2 August 2026 is the date the transparency obligations in Article 50 begin to apply.
Nothing about the rule is new as of that morning. The text has been public since 2024. What changes is that the obligation is now live, so the question shifts from what the rule will say to what you can show about your own content.
Who Article 50 binds
The article splits duties across two roles, and the split matters because most teams reading this fall squarely into one of them.
Providers are whoever puts the AI system on the market. If you build or supply a generative model or a product built on one, the marking duty is yours: output has to be machine-readable as artificially generated or manipulated.
Deployers are whoever uses such a system and publishes the result. A marketing team running campaign copy through a model is a deployer. So is an agency producing client assets, a publisher generating illustrations, and an in-house content function drafting with assistance. If you publish the output, the disclosure duty is yours.
In practice almost everyone in a content or marketing role is a deployer and not a provider. That is worth being clear about internally, because teams often assume the obligation belongs to the vendor whose tool they are using.
What counts as AI content
Wider than most people expect. Article 50 reaches synthetic audio, image, video and text. It is not limited to the obvious generated illustration.
Two categories get named specifically. Deep fakes, meaning image, audio or video content that has been generated or manipulated to resemble real people, places or events, carry a disclosure duty on the deployer. So does AI-generated or manipulated text published to inform the public on matters of public interest.
That last category catches more corporate publishing than it first appears to. A market commentary, a piece on regulatory change, an explainer on a public health or consumer safety topic: these are not obviously journalism, and they can still sit inside a duty written around informing the public.
What labelling actually means
Two things get conflated here, and separating them is most of the work.
The first is machine-readable marking. This lives in the artefact. A downstream system, a platform, a verification tool, another model, has to be able to read the file and determine that it was artificially generated or manipulated. This duty sits with providers.
The second is disclosure a person can see. This is the notice at the point somebody encounters the content. It has to reach them when they meet it, not sit in a policy document three clicks away. This duty sits with deployers.
A visible notice does not discharge the machine-readable requirement, and machine-readable marking does not by itself tell a reader anything. They are different obligations, aimed at different audiences, and a team that has done one has not automatically done the other.
The part almost everyone misses
A label is a statement about content. It is not a record of what was made, by whom, or when.
That distinction is invisible right up until somebody has a reason to test the statement, and the somebody is rarely a regulator. It is far more often a client running a procurement questionnaire, a counterparty in a contract dispute, or a platform asking you to substantiate a declaration you made months ago.
At that point the label is no longer the answer. It is the thing being questioned. What gets asked for next is evidence: which version was published, what touched it between draft and publication, and when that was true. Those questions are answered by a record, not by a notice you control and can edit.
Most teams reach for what they already have: file modified dates, an email thread, project management history, cloud version history. Each of those is held by the party making the claim, and each can be changed by that party. They are useful internally. They are weak the moment their value depends on somebody else believing them.
What to sort out before Monday
Three questions, in order. None of them require a legal opinion to start on.
What did we publish? Not what is on the page now. What actually went out, in which version, on which date. If nobody can answer that for a piece from three months ago, that is the first gap.
What touched it? Which parts were generated, which were edited by a model, which were written by a person. In most teams the honest answer is that a model helped somewhere in the process and a human authored the result, which is a perfectly respectable thing to declare.
Can we show that? Not assert it. Show it, to somebody who has no reason to take your word for it and no access to your systems.
If the answer to the third question is no, that is worth fixing before it is asked rather than after. A dated, independently verifiable record of what was published and how it was produced closes the gap, and it is a great deal easier to create at the time of publication than to reconstruct a year later.
