Article 50 transparency obligations: what has applied since 2 August 2026

Who this guide is written for.

• Product teams running a chat, an assistant or a voice channel backed by a model
• Editorial and marketing teams publishing images, video and text made with AI
• Companies that deployed an assistant in a support channel, their own or a partner's
• Product compliance owners who received contradictory messages from the market about the deadlines

What moved and what did not

Regulation (EU) 2026/1744, the digital omnibus, entered into force on 27 July 2026 and postponed compliance deadlines for high-risk systems. It did not postpone the transparency obligations in Article 50.

What it did add is the transition the market talks about least: providers of generative systems placed on the market or put into service before 2 August 2026 have until 2 December 2026 to meet the technical content-marking duties. For most teams that is the date actually sitting in the calendar.

Three duties translated into engineering work

Article 50 describes an outcome, not an implementation. Below is what follows from it for a product, split into where it shows up, how it is done, and how it is verified.

What to do with content already published

Start from the fact that takes the pressure out of this work: material generated and published before 2 August 2026 does not have to be marked retroactively. The duty covers what you produce now, and generative systems placed on the market before that date have until 2 December 2026 to comply with the technical marking requirements.

Marking older material retroactively is therefore your call, not a requirement. It earns its keep where the material could be taken as a record of a real event, and there it is worth deciding deliberately rather than deferring. The order of work that holds: inventory first, then priorities, then a decision recorded somewhere it can be found again.

• Inventory: what was generated, when, with which model, and where it now lives
• Priority for material showing a person and for anything that could be taken as a record of a real event
• Re-mark where the channel allows replacement without losing the address and where you decide it is worth it
• For assets that cannot or need not be marked retroactively: a recorded decision with a rationale and a date, so the question does not reopen every quarter
• A generated-asset register with checksums, so the next change does not start from zero

Where this goes wrong, and what we do about it.

1. 1
   The machine-readable marking is stripped in transit

   Content Credentials and XMP metadata survive the export from the authoring tool, and are then removed by the first step of the publishing path that re-encodes the file: a CDN converting images to WebP, compression inside the CMS, or an upload to a social platform. The team sees a correctly marked file in the repository and treats the matter as closed, while the asset in production carries nothing.

   What we do about it

   We verify the marking at the end of the path, on the asset fetched from its production URL, not on the file in the tool. We leave a test that repeats this on every deployment and reports the gap. Where a channel strips metadata and that cannot be changed, we add a human-readable label and record the decision in the asset register.

   What stays with you: marking conformance report per channel, plus a verification test wired into your deployment process
2. 2
   The disclosure buried in the terms of service

   The statement that a user is talking to an assistant ends up in the privacy policy or in a tooltip, because the team does not want to spoil the first impression. The duty is about information given in a clear and distinguishable manner at the latest at the first interaction, so whether the duty is met depends on where the statement appears. On top of that it is usually missing from the entry point nobody remembers: the partner integration, the voice channel, the automated email reply.

   What we do about it

   We put the disclosure in the first message and as a persistent label in the conversation header, then walk every entry point into the system, partner surfaces included. Each entry point gets a status and a screenshot. The list of entry points stays with you, so when a new channel is added it is clear what has to be checked.

   What stays with you: inventory of entry points with a status and a screenshot for each
3. 3
   A caption on the image instead of marking the content

   The team adds a line of text in the corner of an image and treats it as satisfying the machine-readable requirement. The caption is cropped by the first video frame or by a thumbnail in a social feed, and no machine will read it anyway. It fails in the other direction too: metadata in a file is not a label a person can see or hear, so on its own it does not satisfy the disclosure required for deepfakes.

   What we do about it

   We separate the two requirements and implement both, each with the technique that fits it: a label readable by a person, and marking readable by a machine. For every content type, image, video, audio and text, we write down exactly what appears and where. The result is checked with a C2PA reader and by visual review, separately.

   What stays with you: marking specification per content type, with verification results from both methods
4. 4
   The vendor says it marks content and nobody checked

   The model vendor's documentation mentions watermarking or Content Credentials, so the item leaves the list. In practice the marking can depend on the model version, on the call mode and on which endpoint you use, and your integration may predate the feature or bypass it. The claim lives in the vendor's documentation, not in your artifact.

   What we do about it

   We sample your actual integration, per model and per call mode, and check what really comes out. Differences from the documentation are recorded with a date and a model version and escalated to the vendor. Whatever the vendor does not add, we mark on your side rather than waiting for their release.

   What stays with you: sampling results with date, model version and call mode
5. 5
   The market talks about a delay, so the team defers everything

   The headline about the AI Act being postponed concerns high-risk systems, but it lands in the plan as a single sentence: we have until 2027. The transparency duties arrived on time and apply to products that are live now. The plan is built from the headline rather than from the table of deadlines, and the difference only becomes visible when somebody outside asks about a specific feature.

   What we do about it

   We hand over a deadline table with the legal basis for each row and map it onto your systems, stating for each one what applies now and what applies later. The summary fits on one page, so it can go to the board without translating a regulation. We update it whenever the legal position changes.

   What stays with you: one-page deadline summary per system, with the legal basis next to every line

What stays with you.

• Inventory of the points where a user meets an AI system, with a status and a screenshot
• Marking specification per content type: image, video, audio, text
• Verification test that checks the marking on the published asset, wired into your deployment process
• Generated-asset register with model, version, date and checksum
• Deadline summary per system: what moved, what did not, and what follows for you
• List of questions for counsel wherever the decision is interpretation rather than engineering

How we work.

1. 1
   1. Inventory of touchpoints and assets

   We walk every entry point into a conversation with the system and every channel that publishes generated content. The output is a list with statuses, not an opinion.

   Days 1-3
2. 2
   2. Specification and fixes

   We agree what appears in the interface and how each content type is marked, then implement the changes together with your team.

   Week 1-2
3. 3
   3. Verification in production

   We check the marking on assets fetched from production URLs, channel by channel, and leave a test that repeats the check on every deployment.

   Week 2
4. 4
   4. Handover and review at model change

   We hand over the specification, the register and the test. We come back when a model or vendor is swapped, because that is when marking most often disappears quietly.

   Week 2-3, then at every model change

The rest of this cluster.

Where this turns into a service.

What this page is, and what it is not.

We are an engineering team, not a law firm. This page covers how to perform the obligation in a product and how to verify that it works, not how the article should be read for your case. Scope boundaries, in particular around published text and the exceptions in Article 50, are settled by counsel: yours, or our legal partner. Dates and instrument numbers are published together with their sources.

Where the dates and numbers come from.

• Regulation (EU) 2024/1689 (AI Act), consolidated text on EUR-Lex
• Polish Ministry of Digital Affairs: what changed in the AI Act on 2 August 2026
• Pinsent Masons: law delaying EU high-risk AI rules finalised
• Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026 item 1003)
• Regulation (EU) 2026/1744 (Digital Omnibus on AI), text on EUR-Lex