Loading
The Article 50 Playbook: A practical guide to Europe's AI transparency rules
·11 min read
Most organizations working through AI Act compliance have spent their time on the risk-classification requirement trying to understand which of their systems fall into prohibited or high-risk categories. They have also worked out what that means for documentation, conformity assessment, and market access.
As of 2 August 2026, Article 50 of the EU AI Act entered into force, marking the next major step in Europe's regulation of artificial intelligence. Article 50 brings the regulation into the places where people actually encounter AI: direct interactions with AI systems and the content they produce.
The provision now reaches into genuinely ordinary commercial activity. Not into experimental uses or frontier deployments, but into customer support channels, content production workflows, and editorial processes that most organisations were already running before compliance became a requirement. But Article 50 does not treat these uses in the same way. What the company has to do depends on how the AI is being used and whether it built the system or is deploying someone else's.
The EU AI Act is 445 pages long. One question it keeps returning to is this: who built the AI, and who put it to work. In other words, the provider/deployer distinction is crucial in how the Act allocates responsibility.
A company that built its own AI system and placed it on the market is a provider. One that uses someone else's system in its own operations is a deployer. In practice, most organisations of any size are both at once, depending on the system under consideration: the company that built its own customer data tool while running its marketing team on a licensed image generator is then sitting in both positions simultaneously, with different obligations in each.
Under Article 50, neither set of obligations substitutes for the other. What the provider builds and what the deployer ships are two different things, and Article 50 treats them that way. So if a company that licenses a chatbot from a third party puts it in front of its customers, it cannot assume the supplier has taken care of everything. Put differently, buying the technology does not transfer the obligation. The company remains responsible for what its customers actually see and hear.
The practical starting point is the interaction itself. Article 50(1) applies to AI systems that interact directly with natural persons. The requirement is that the person be told they are dealing with an AI system, unless this is already obvious from the circumstances. The obligation is the provider's to build into the system and the deployer's to implement correctly, and the disclosure belongs at the start of the interaction, not buried in terms and conditions or in a privacy policy the user is unlikely to have read.
"Obvious from the circumstances" is narrower than it might initially appear. For example, a voice assistant presented under a human name, or a customer support chat interface styled to resemble a human agent, does not qualify for the exception. The question is whether a reasonably attentive user would already understand without being told. In the majority of commercial deployments, the answer is that they would not know, and the disclosure is therefore required.
Article 50(2) moves from the interaction itself to the content an AI system produces. Providers of systems that generate synthetic audio, images, video, or text are required to ensure those outputs carry a machine-readable marking—information embedded in or associated with the file that identifies it as artificially generated or manipulated.
This is not a label visible to the user. It is a technical mechanism designed to persist through ordinary distribution: when a file is downloaded, re-uploaded, compressed, or passed through a platform. Within the technical limits of any given format, the marking is intended to survive that journey. The Commission's Code of Practice on AI content transparency addresses how this framework is meant to work, and NicFab's analysis of the Code offers a useful walkthrough of the technical provenance side.
For providers, the practical testing obligation this creates is easy to underestimate. The question is not whether the marking is present in the file that leaves the system, but whether it survives the journey the file actually takes through formats, platforms, and processing chains. For organisations that receive AI-generated material from suppliers and then handle, edit, or re-encode it before publication, whether the marking is intact by the time the content goes out is not the supplier's problem alone.
Article 50(4) brings two categories into focus for deployers.
The first is deepfakes: AI-generated or manipulated images, audio, or video that could be mistaken for a real depiction of something that did not actually occur—a real person saying something they never said, or doing something they never did. When a company uses such material in its public communications, it is required to disclose the artificial nature of the content to the audience. The deployer must still make the disclosure, even if the provider has already applied a technical marking to the file.
The second concerns AI-generated or manipulated text published to inform the public on a matter of public interest. A company publishing that sort of content has to disclose the AI origin unless the text went through genuine human editorial review, with a person or organisation taking editorial responsibility for the result.
That editorial exception requires more scrutiny than the phrase "human in the loop" might suggest. The Commission's Guidelines, adopted on 20 July 2026—summarised by Bird & Bird shortly after publication—focus on whether the reviewer had the time and opportunity to make substantive changes before publication. An editor who took a generated draft, revised sections, checked the factual basis independently, and exercised genuine judgment before the piece went out is exercising real editorial control. Someone who ran a quick read over a generated article before clicking publish is not. The organisation relying on the exception should be able to demonstrate what the review actually involved.
Visible disclosures and machine-readable marks are not the same thing. The two requirements are easy to conflate, but they do serve different purposes.
The machine-readable marking is there so that platforms, moderation tools, and other downstream systems can detect AI-generated content. The disclosure, by contrast, is there for the person encountering it. A synthetic video can therefore carry both: a technical mark embedded in the file and a visible label telling the viewer what they are watching. One does not replace the other.
For companies that receive AI-generated content from suppliers and then process or distribute it, these two sides can take different paths. The technical marking may pass through several systems before the content reaches the audience, while the disclosure still needs to reach the person who sees it. But both need to be accounted for.
The next date worth keeping in mind is the 2nd of December 2026. While the transparency obligations for deployers apply from 2 August 2026, providers of AI systems already on the market before that date have until 2 December 2026 to implement the machine-readable marking required under Article 50(2). This four-month transition was introduced by the Digital Omnibus on AI, Regulation (EU) 2026/1744. Cobalt's summary of the Digital Omnibus sets out the details. This means that, for part of 2026, the two sides can be working to different deadlines. A deployer may already need to disclose AI-generated content to its audience even though the provider still has time to implement the technical marking. One does not wait for the other.
Example: A hotel uses an AI image generator to create a promotional image for its website. The hotel must disclose that the image was AI-generated from 2 August 2026, even if the provider of the image generator does not have to add its machine-readable marking until 2 December 2026.
The AI vendor may be based in the United States, the United Kingdom or somewhere else entirely. But that address does not by itself tell you whether Article 50 applies. What counts is where the system is being used and where its output reaches people. Content created with an AI tool outside the EU can still fall within Article 50 when it is produced for European campaigns or distributed to people in the Union.
The cross-border nature of the process can make this harder to see. A hotel group, for example, might create campaign imagery with a US-based tool for properties in Germany and France. A supplier outside the EU might generate product content that is then published across European markets. A platform operating outside the Union might generate or distribute AI-generated material that is ultimately shown to people in Member States.
The vendor's location alone therefore gives only part of the picture. You need to follow the system through its use and distribution: who uses it, where the output is used or made available, and who encounters it. Reed Smith's analysis of the territorial questions is useful for the cross-border situations where those lines are less obvious.
Article 50 tells organisations what is required to be transparent. The Code of Practice is where the requirements take a more concrete shape, because it deals with the practical questions that are hard to settle one by one in a regulation written at this level. The final Code was published on 10 June 2026. It is voluntary, but still consequential. For instance, an organisation that follows the Code benefits from a presumption of compliance with the relevant Article 50 obligations, after the European Commission and the AI Board assessed it as adequate for demonstrating compliance. An organisation can use a different approach instead, but it then has to show that its approach achieves the same outcome.
That is particularly relevant once AI-generated material leaves the neat confines of a single system. Such as when a piece of content is generated in one tool, edited in another, passed through a publishing platform, transformed into different formats and eventually distributed by a third party. The regulation establishes the obligation, but it cannot realistically prescribe every technical decision along that path (setting out ways of marking synthetic content, technical methods used, how those marks should remain with the content as it is processed or distributed, and how the approach works when several systems, providers or suppliers are involved).
So the Code is the practical layer between the rule and the systems, tools and workflows that have to make the rule work. It is not a second version of Article 50, nor a separate set of obligations sitting beside it
The most useful way to work through Article 50 is to start with what is already happening inside the organisation. Take the AI tools and systems in use, follow what they produce, and then follow that output as it moves through the business and eventually reaches the outside world.
For each system, a few questions usually tell you most of what you need to know: Is the company acting as provider, deployer, or both? Does the system interact directly with people? Does it generate content, and what kind? Who sees that content, and where? Which part of Article 50 applies, and where in the existing workflow is that requirement actually being handled?
Once you look at the organisation this way, it becomes clear why a single company can have several different positions at the same time. It might license a chatbot for customer support, publish AI-assisted editorial content, and use a separate image-generation tool in its marketing department. The systems may sit in different teams, serve different purposes, but they create different kinds of obligations, even though they all belong to the same organisation.
The regulation becomes much easier to work with once those chains are visible. The challenge is usually not reading Article 50, but finding all the places where it touches the way a company already works. That is the work Actify is built to help with: mapping the AI tools and use cases across organisations, identifying which obligations apply, and turning the missing pieces into a clear, documented action plan.