Article 50 Transparency Looks Easy. The Engineering May Not Be.

Update — 12 June 2026: The Code of Practice on Transparency of AI-Generated Content has been published. It is voluntary, but its mandatory measures are what market surveillance authorities will check compliance measures against.

Update — 11 May 2026: The AI Act Omnibus deal reached at the May trilogue moves the 2 August 2026 deadline for Annex III high-risk obligations to 2 December 2027, pending formal adoption and publication in the Official Journal. The Article 50 deadline to mark AI-generated content moves to 2 December 2026. See: EU AI Act High-Risk Deadline Delayed to December 2027.

Update — 8 May 2026: The Commission has published its first official reading of Article 50: draft guidelines on the transparency obligations, open for consultation until 3 June 2026. They are non-binding (only the Court of Justice can give an authoritative interpretation), but they are how market surveillance authorities will approach enforcement from 2 August 2026, and this article now reflects them. The sharpest clarifications: who counts as “interacting directly” with an AI system, how the “obvious AI” exception is actually tested, and that Article 50(2) is two obligations (marking and detection), not one. A companion Code of Practice on marking and labelling AI-generated content has since been published (see the update above).

Article 50 is the article most teams think they can ship in an afternoon. Add an “AI” badge to the chatbot, write a sentence in the help centre, done. That covers the first paragraph. It doesn’t cover the real obligation. The chat label is a UI element. The real obligation is structural: it applies on every channel where the system can talk to a person, it has to be machine-readable for synthetic content, and it has to reach people in physical spaces who never see a screen. Teams treating this as a copy task will find that the obligation lives in the system architecture, not on the marketing site.

The transparency requirements piece covers the four obligations at a survey level. This piece is about what they actually take to implement in a way that survives an inspection.

What Article 50 actually requires

Article 50 is the entirety of Chapter IV. Four distinct obligations, each with its own subject and its own bar.

Article 50(1). Providers of AI systems “intended to interact directly with natural persons” must design and develop them so the people involved are informed they’re interacting with an AI, “unless this 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.”

Article 50(2). Providers of AI systems, “including AI systems that are general-purpose AI systems,” generating synthetic audio, image, video or text content, must ensure outputs are “marked in a machine-readable format and detectable as artificially generated or manipulated.” The technical solutions must be “effective, interoperable, robust and reliable as far as this is technically feasible.”

Article 50(3). Deployers of emotion recognition or biometric categorisation systems must inform the people exposed and process the personal data in line with the GDPR.

Article 50(4). Deployers of AI systems that generate or manipulate image, audio or video content “constituting a deep fake” must disclose that the content has been artificially generated or manipulated. For text published “with the purpose of informing the public on matters of public interest,” similar disclosure applies, with a carve-out where the content has undergone human review or editorial control and a natural or legal person holds editorial responsibility for the publication.

Article 50(5). The information must be provided “in a clear and distinguishable manner at the latest at the time of the first interaction or exposure” and must meet applicable accessibility requirements.

Article 50 disclosure duties apply from 2 August 2026 and the deadline to mark AI-generated content is 2 December 2026, regardless of risk classification. The Omnibus moved the high-risk deadline to December 2027 and cut the content-marking grace to three months, but left the general Article 50 disclosure date where it was. Article 50 has no carve-out for “limited risk” simply because the system isn’t high-risk elsewhere. All four obligations are also unusually easy for a regulator, journalist, or competitor to verify externally.

”Interact directly” is wider than chat

The first thing teams underestimate is the scope of “interact directly with natural persons.” Customer-service chatbots are the obvious case. But:

• Voice agents, including AI phone systems and IVR replacements, are the same obligation in a harder modality. A voice greeting that sounds human is exactly the situation 50(1) was written for. The disclosure has to be audible, at the start of the call, in the same channel.
• AI features inside a larger product carry the obligation even though the wider product isn’t “an AI system”. A chatbot in your app, a voice assistant, a generative feature the user invokes and reads the output of: the feature is the AI system, and the obligation runs with it. But the draft guidelines draw a line the article text leaves implicit. The interaction has to be direct. Where a human sits in the middle, say a support agent using an AI tool to draft a reply they then review and send, the customer is exposed to the AI output through a person, and 50(1) does not apply. Your internal support copilot isn’t a 50(1) disclosure case. The moment the AI talks to the customer itself, it is.
• AI agents are in scope when they’re built to interact with the people instructing them, and potentially with others, while carrying out a task. Where you can’t reliably predict whether an agent will end up talking to a real person, the guidelines say to build it to disclose itself in every situation where that’s likely. An AI agent that autonomously emails a customer is covered, and the email needs the disclosure.
• Embedded chat on third-party sites, like widgets dropped into customer sites by a SaaS provider, make the provider responsible for disclosure even when the deployer controls the surrounding UI. You can’t ship a widget that looks human and rely on the deployer to add a label.
• Mixed human–AI flows, such as a chat that starts with a bot and hands off to a human or vice versa, must disclose AI at the points where AI is operating. A flow that silently swaps a human reply for a generated one is exactly the deception the article exists to prevent.

The Article 50(5) timing rule is the trap. “First interaction or exposure” means in the channel the user is actually using, at the moment they start using it. Not a footer that appears two clicks in. Not a paragraph in the privacy notice. Not a banner the user has already dismissed.

The “obvious AI” exception is a trap

The 50(1) carve-out for obviousness reads as a permission slip and will almost never be one in practice. The standard is “a reasonably well-informed, observant and circumspect natural person, taking into account the circumstances and the context of use.” That’s a higher bar than “a tech-literate user spotting a chatbot UI.”

A modern voice agent isn’t obviously AI. A chatbot using first-person empathy and conversational pacing isn’t obviously AI. A long-form drafted reply to a customer email isn’t obviously AI. The architectural assumption “everyone knows what a chatbot is now” isn’t what the standard says. The user is the test. The deployer doesn’t get to decide whether the disclosure was obvious enough.

The draft guidelines give this exception a structure it didn’t have before. You assess it in two steps. First, define the target audience the system is built for, plus any wider audience that’s reasonably foreseeable, which matters when the system is open to the general public. Second, ask how well-informed, observant and circumspect an average member of that audience is. The benchmark is borrowed from EU consumer protection law’s “average consumer”. A specialist or professional audience raises the bar; an audience that includes children, elderly users, or people with disabilities lowers it, because the law expects less of them.

The guidelines then list what they’d accept and what they wouldn’t:

• Obvious enough to skip disclosure: a code-assistance chatbot used only by professional developers; non-playable characters in a video game; a diagnostic tool used only by trained clinicians.
• Not obvious, so disclosure is required: a robotic companion pet that mimics a real animal; AI avatars in immersive VR or AR using realistic faces or voices; a chatbot in an online helpdesk where users may take the replies for a human’s.

There’s also a regulatory incentive problem. Disclosure is cheap. The exception is a legal argument. An auditor reviewing a chatbot with no disclosure has to be persuaded. An auditor reviewing one with a clear “AI assistant” label has nothing to argue about.

Synthetic content is a provenance problem

The 50(2) machine-readable obligation is where the engineering work hides. “Marked in a machine-readable format” is not a visible label. It’s metadata embedded in the file itself, so that the systems consuming the content (search engines, browsers, social platforms, fact-checkers) can detect it.

Two technical traditions are converging on this.

Content provenance metadata. The C2PA standard (Coalition for Content Provenance and Authenticity), backed by Adobe, Microsoft, the BBC, and others. Cryptographically signed manifests attached to images, video, and audio describing how the content was produced and modified. Resilient against benign re-encoding when pipelines are aware of it. Fragile against deliberate stripping.

Watermarking. Signal-level marks embedded in pixels, audio samples, or token distribution. SynthID, Meta’s invisible image watermarks, and a growing set of academic schemes for text. More resistant to stripping than metadata, but with known attack surfaces: cropping, compression, paraphrasing for text.

Article 50(2) doesn’t name a standard. It requires marking that’s “effective, interoperable, robust and reliable as far as this is technically feasible,” and Article 50(7) tasks the AI Office with encouraging codes of practice. In practice, if you’re shipping today you need both: C2PA-style manifests for the metadata layer and watermarking for the signal layer, because each covers a failure mode the other doesn’t. Harmonised standards under the EU process will eventually settle on a baseline, but providers shipping into the 2 December 2026 content-marking window can’t wait for them.

The draft guidelines make the point 50(2) is two obligations, not one. You have to mark the content and make it detectable. That means providing a way for someone exposed to the content to run a check and get a human-readable answer to “was this AI-generated?”. A watermark nobody can read back, or a manifest with no detection tool behind it, satisfies half the article. The guidelines define four quality criteria the technical solution must meet (“effective, interoperable, robust and reliable”) and conclude that, at the current state of the art, no single technique hits all four. That’s why a combination is expected rather than optional. They stay deliberately technology-neutral: instead of naming C2PA or any one scheme, they point to families of technique, namely watermarks, metadata, cryptographic provenance methods, fingerprints, and logging, leaving the choice to you.

There’s also an exception worth knowing, because a lot of ordinary product work sits inside it. Where the AI only performs “an assistive function for standard editing” or “does not substantially alter” the input, no marking is required. The guidelines draw the line with examples. Grammar and spell-checking, format conversion, noise reduction, cropping, minor colour correction, red-eye removal, rescaling, video stabilisation: all exempt. Translation, summarisation, adding or removing objects, blurring or altering faces, changing a person’s body shape or skin colour, colourising black-and-white, building composites: all of those change the meaning, and all need marking. Assistive technologies that let people with disabilities communicate, such as synthetic voices, are exempt too, because they don’t alter the substance of what’s said.

For GPAI wrappers, the obligation flows through the provider chain. If you generate images by calling an external API (say, an OpenAI image endpoint), the API provider’s marking is the foundation, but you remain responsible for not stripping it as it passes through your pipeline. Re-encoding a marked image without preserving the manifest, or paraphrasing watermarked text through your own summariser, is precisely the failure mode the obligation is meant to cover.

Provider and deployer obligations are different

Article 50 splits responsibility along the same provider/deployer line as the rest of the Act, and the split confuses teams.

Providers of generative systems must mark the outputs (50(2)). The obligation sits with the entity placing the system on the market, even when their customers are the ones publishing the content.

Deployers publishing deepfakes must disclose that the content is AI-generated (50(4)). The obligation sits with the entity making the publication decision, even where the original provider already marked the file.

Both can apply to the same image. Picture this. Your marketing team uses a third-party image generator for a campaign asset. The image arrives marked by the provider (50(2) satisfied on their side). When your team posts the image on your company website, the deployer disclosure obligation kicks in (50(4)). The mark is for machines. The visible disclosure is for the audience. Both have to be there. This is the same provider/deployer distinction that catches teams under the provider trap, in a different domain.

The deepfake test isn’t “did we use AI”. It’s whether the content “appreciably resembles existing persons, objects, places, entities or events and would falsely appear to a person to be authentic or truthful.” A stylised illustration isn’t a deepfake. A photorealistic image of a real product, location, or person is. The closer the output is to documentary realism, the firmer the disclosure obligation. The artistic-and-satirical carve-out limits the obligation to disclosing the existence of the generated content “in an appropriate manner that does not hamper the display or enjoyment of the work.” It doesn’t eliminate it.

The draft guidelines tighten this. “Existing” doesn’t mean a real, named person. It’s enough that the subject “can exist or could have existed in reality”, so a realistic but invented person counts. What drops out is anything that obviously couldn’t be real: the guidelines’ own examples include a sphinx flying over the Eiffel Tower, mice arguing about cheese, and a cartoon of a historical scene. The deployer’s intention is irrelevant: content doesn’t stop being a deepfake because you meant no harm. And the assessment looks at the actual audience rather than a hypothetical average viewer: if children or less digitally-literate users are likely to see it, the bar for “would falsely appear authentic” drops. The artistic and satirical carve-out is narrow, too. It’s lost the moment the content serves a primarily commercial or informative purpose. A deepfake ad showing invented customers enjoying your product is not exempt creative work.

Emotion recognition and biometric categorisation

Article 50(3) lands hardest on operational deployments. The notification is owed in the physical world, often to people who never see a screen.

The scope is bounded by Article 5. Emotion recognition in workplaces and educational institutions is prohibited outright, with narrow exceptions for medical and safety purposes. Call-centre sentiment monitoring of employees, classroom attention tracking, retail-staff “engagement” analytics. These aren’t Article 50 disclosure problems. They’re Article 5 prohibitions. Notifying the employee doesn’t legalise the system.

What remains under 50(3): emotion recognition in customer-facing contexts (caller sentiment for service-quality routing, voice-stress analysis for fraud), biometric categorisation in physical spaces (retail demographic analytics, audience measurement), and similar systems where the affected people are users or visitors rather than workers or students.

The draft guidelines add two things. Almost every emotion recognition system is also classified as high-risk unless it’s outright prohibited under Article 5, so the 50(3) notice sits on top of the full high-risk requirements, not instead of them. And biometric categorisation triggers 50(3) whether or not it’s high-risk. The notice is owed to everyone exposed, children included, and the form is flexible (writing, a standardised icon, an audible message, or a combination), as long as it reaches people at or before first exposure. The worked examples are concrete: a pop-up before a game launches, telling the player their face and emotions will be captured; a visible notice at every entrance to an exhibition room where visitors’ faces are read to estimate age group.

The notification has to actually reach them. A footer in a privacy policy doesn’t. Signage at the entrance of a monitored space, an audible disclosure at the start of a call, a notice within the app where the categorisation happens. The question to design against is how does the affected person learn about this before the processing begins? Because the obligation is on the deployer, the design responsibility can’t be outsourced to the provider of the analytics tool.

The GDPR runs in parallel. Biometric data is special-category data under GDPR Article 9, which means a separate lawful basis is required regardless of the AI Act notification. An organisation that has solved Article 50(3) and not solved the GDPR question has solved one of two problems.

Documentation expectations

Article 50 doesn’t produce a single dossier the way Annex IV technical documentation does, but the records that survive an inspection are concrete:

• The disclosure design for each interactive system: channel, wording, placement, and the test that confirms the disclosure fires on first contact.
• The marking pipeline for any generative output: the format used (C2PA manifest, watermark scheme), the CI verification step confirming outputs carry the mark, and the policy for any re-encoding step that might strip it.
• The deployer disclosure decision for any synthetic content publication: who signed off, against what test of “deepfake,” with what visible mark on the published asset.
• The notification design for any emotion or biometric categorisation system: placement, wording, and evidence that affected people actually receive it (signage photos, call-opening recordings, in-app screenshots).
• The interaction with Article 26 deployer obligations where the deployer is also responsible for record-keeping and staff instructions.

A policy that asserts disclosure happens, with no evidence showing it does, has the same hole as the Article 12 logging problem in a different domain. The fix is the same: tests, in CI, that confirm the system behaves as the policy claims.

Common traps

The disclosure that disappears after the first message. A bot greets with “I am an AI assistant” and then everything looks human from the second message onward. The label has to persist. It’s a property of the channel itself, and the opening line alone doesn’t satisfy it.

The voice agent that sounds human and discloses on the website. The channel is the call. The disclosure has to be in the call.

Stripping provenance in the pipeline. Marked images go through a CDN that re-encodes them for thumbnails, losing the manifest. Marked text gets paraphrased by a summariser further down your stack, removing the watermark. The mark survives only as long as your pipeline preserves it.

Treating “obvious” as a default. If the disclosure costs nothing to add and the exception costs an audit argument, the cost-benefit always points one way.

Confusing the provider mark with the deployer disclosure. A C2PA manifest on a marketing image is the provider’s compliance. A line under the post saying “image generated with AI” is the deployer’s. Both are required. One doesn’t satisfy the other.

Notifying employees when the analytics are prohibited. Adding a sign to the call-centre wall doesn’t legalise emotion recognition on workers. The Article 5 prohibition isn’t a disclosure obligation.

Footer-only notices for biometric categorisation in physical spaces. The affected person is in the building. They’re not on the website.

Disclosure at the end instead of the start. The guidelines are explicit that a notice in a video’s end credits, or at the close of a call, fails 50(5). And because people join a live stream late or scroll into content midway, the obligation runs per viewer and per output. For a live broadcast that means disclosing at the start and then persistently, not once.

Accessibility-blind disclosures. Article 50(5) requires conformity to applicable accessibility requirements. A visual-only label fails for a screen-reader user. An audio-only disclosure fails for a deaf user. The disclosure design has to clear the same accessibility bar as the rest of the product.

How the guidelines change your compliance route

Two practical things come out of the enforcement section. First, there’s a defined easy path: adhere to the Code of Practice on Transparency of AI-Generated Content — now published — and you get a straightforward way to demonstrate compliance under 50(2), (4) and (5), and if you do fall short, your adherence counts as a mitigating factor when a fine is set. Skip the code and you can still comply by “other adequate means”, but expect more requests for information and to have to show your working with a gap analysis. If the code is not judged adequate, the Commission can still impose common rules by implementing act.

Second, on timing. Article 50 applies from 2 August 2026 regardless of when your system was placed on the market, and there’s no high-risk-style grandfathering, since transparency stacks on top of everything else. The one carve-out under discussion sits in the Omnibus proposal, which would give the 50(2) marking and detection duty a transitional period for generative systems already on the market before 2 August 2026. Content generated and published before that date wouldn’t have to be marked retroactively. That proposal isn’t settled law yet, so treat it as planning guidance, not a reprieve.

What to do now

If you’re a provider or deployer with AI in customer-facing channels:

1. Audit every channel. List every place your system talks to a person: web chat, voice IVR, embedded widgets, mobile app, in-product features. For each, document the disclosure that fires at first interaction.
2. Add disclosure to the channel layer. A label on the homepage doesn’t satisfy 50(1) for a voice call. Make disclosure a property of the conversation itself, in whatever modality the conversation is happening.
3. Wire marking into the generation pipeline. Every synthetic output your system produces should carry a C2PA manifest, a watermark, or both. Add a CI test that fails the build if a sampled output comes through unmarked.
4. Check your re-encoding paths. Anywhere an image is resized, a video is transcoded, or text is paraphrased later in your stack, confirm the mark survives. This is where 50(2) compliance quietly leaks.
5. Map 50(3) notifications to physical spaces. If your deployment uses cameras, microphones, or sentiment analysis in a physical environment, design the notification for the people in that environment (signage, audible cues, app messages), not a privacy policy update buried two pages deep.

Article 50 is unusually easy to verify and unusually easy to underestimate. A regulator doesn’t need to subpoena documentation to find a violation. They call the support line, send a test message, look at a marketing image. Penalties for transparency breaches reach €15 million or 3% of global turnover, and the breaches themselves are the easiest in the Act for an inspector to evidence. The obligations look like UI work and turn into engineering work the moment the system has more than one channel, the moment generated content moves through any pipeline, the moment a notification has to reach a person who isn’t online.