EU AI Act Article 50 and Content Provenance

EU AI Act Article 50 and Content Provenance: What the Rules Require and What They Leave Open

Article 50 is the transparency chapter of the EU AI Act. It requires people to be told when they’re dealing with an AI system, requires generative AI outputs to carry machine-readable marks, and requires visible labels on deepfakes and on some AI-written text. Article 50 has applied since 2 August 2026. The only grace period covers systems already on the market before that date, and only for the marking and detection duty in Article 50(2), which they must meet from 2 December 2026.

That’s the rule. Underneath it sits a problem the technology industry has been chewing on for years: how do you attach a trustworthy “where did this come from” signal to a piece of content that will be copied, compressed, screenshotted and re-uploaded? That problem is content provenance, and Article 50 is the first major law to push it into everyday compliance work.

Four duties, two kinds of people

The article is easier to read once you sort the duties by who carries them.

Providers are the companies that build AI systems and put them on the EU market under their own name, wherever they’re based. A provider outside the EU is still covered if the system’s output is used in the EU. Providers have two jobs:

* If the system talks directly to people (a chatbot, an agent, an avatar), design it so users are told they’re talking to AI, unless that’s obvious. This is Article 50(1).

* If the system generates synthetic audio, image, video or text, make sure the output is marked in a machine-readable way and can be detected as AI-generated or manipulated. This is Article 50(2).

Deployers are the people and organisations using those systems in a professional capacity. They also have two jobs:

* Tell people when you’re running emotion recognition or biometric categorisation on them (Article 50(3)).

* Clearly label deepfakes, and label AI-generated or manipulated text published to inform the public on matters of public interest (Article 50(4)).

The “professional” part matters more than it first appears. The Commission’s guidance says personal, non-professional use is outside the Act, but someone who earns money from content on a regular basis, or works freelance, counts as a deployer. A part-time YouTuber who monetises synthetic footage is probably in scope. A teenager making a joke video for friends isn’t.

Information has to arrive clearly and at the right moment too. This is Article 50(5): the disclosure has to be there at the first interaction or first exposure, in a form people can actually perceive.

Where the calendar actually stands

This is the part people keep getting wrong, partly because the Digital Omnibus produced a lot of “AI Act delayed” headlines.

The Omnibus did delay things. Regulation (EU) 2026/1744 entered into force on 27 July 2026 and pushed back most high-risk obligations, but left the transparency rules alone. Stand-alone Annex III high-risk systems now have until 2 December 2027, and product-embedded Annex I systems until 2 August 2028. Article 50 wasn’t part of that deferral.

So the state of play on 29 October 2026 is:

* Disclosure of AI interaction, deepfake labelling and the public-interest text rule have applied since 2 August for systems placed on the market from that date.

* Generative systems that were already on the market on 2 August get until 2 December 2026 to meet the Article 50(2) marking and detection requirement. That’s about a month away as I write this.

* Content generated before 2 August 2026 doesn’t have to be labelled retroactively, though the Commission encourages deployers to do it where they can.

* National market surveillance authorities do most of the enforcing, and fines can reach 15 million euros or 3% of worldwide annual turnover, with proportionality for SMEs.

Marking is a provenance problem wearing a legal suit

Article 50(2) demands marks that are “effective, reliable, robust and interoperable”. That’s four requirements, and the uncomfortable truth, which the Commission openly admits, is that no single technique meets all four today.

The Code of Practice on Transparency of AI-Generated Content, published on 10 June 2026, is the Commission’s answer. It’s voluntary, but providers who sign it can rely on it to demonstrate compliance with legal certainty, while those who don’t must show compliance by other adequate means and may face more information requests. In practice it will become the default playbook.

Its core idea is layering. The first layer is digitally signed, timestamped metadata recording that the content is AI-generated or manipulated. The second is an imperceptible watermark woven into the content itself, meant to survive when the metadata is stripped. Fingerprinting or logging can be added as a supplementary layer, but the Code is explicit that it isn’t sufficient on its own. Free-form text can’t carry metadata, so it’s handled with a single watermark layer.

Why two layers? Because metadata is fragile. A screenshot drops it. Many platforms re-encode uploads and drop it too. Watermarks survive more of that abuse but are harder to make robust and interoperable, which is why providers have until 2 February 2027 to make their watermark detection mechanisms interoperable, so content can be checked without running each vendor’s detector in turn. The Code also asks providers to make best efforts to keep existing metadata intact when they process third-party inputs.

Standards like C2PA are the obvious candidates for the metadata layer, since they already define signed provenance claims embedded in media files. The Code describes the kind of layer it wants, so whether a given C2PA implementation qualifies is a question for the provider and its legal team, not something this article can settle.

The visible label is a different job entirely

Machine-readable marking is for software. The deepfake and text rules in Article 50(4) are for humans, and the Commission’s guidance is firm that the two don’t substitute for each other. Deployers can’t simply rely on the provider’s embedded mark to meet their own disclosure duty. The disclosure must be visible or audible and perceivable without special tools.

A deepfake, under the Act’s definition, has to meet three tests. It must closely resemble something that exists or plausibly could, and it must falsely appear authentic or truthful. Context, audience expectations and the message of the content all feed into that last judgement. Background scenes and special effects in an obviously staged film generally won’t qualify. Evidently artistic, satirical or fictional works get a lighter touch: disclosure that doesn’t spoil the work.

For text, the rule is narrower than many people assume. It covers published text meant to inform the public on matters of public interest, such as politics, public health, justice or consumer safety. And there’s an exit: text that has gone through genuine human review or editorial control doesn’t need the label. The Commission defines that as a substantive check by someone with relevant knowledge, or control by a responsible editorial entity, and says a spell-check or grammar pass doesn’t count. A named person must hold ultimate legal responsibility for the publication.

That exit is where a lot of publishers will end up living. It’s also where record-keeping starts to matter.

Where a hash and a timestamp can help, and where they can’t

Let me be direct about the scope here. Certelo is not an Article 50 compliance tool. It doesn’t watermark AI outputs, it doesn’t embed signed metadata, and it can’t tell you whether a file was made by an AI system. Nothing in this section should be read as “Certelo satisfies Article 50(2).”

What Certelo does is narrower. The file stays on your device and the SHA-256 hash is calculated locally. Only that hash is anchored to the Electra Protocol blockchain, so the original file doesn’t need to be uploaded to create the record. Later, anyone holding the same file can recompute the hash and check it against the blockchain record. The result is verifiable evidence that a file with that exact digital fingerprint existed at or before the recorded blockchain time. It says nothing, on its own, about who made the file, who owns it, or how it was produced.

Within that limit, there are at least three places where such a record is useful alongside Article 50 work.

Freezing the version you actually published:

Suppose a small agency publishes a synthetic product video on 14 September 2026 (hypothetical example), with a visible AI disclosure burned into the first seconds. Months later a client asks what exactly went live and whether the label was there. A timestamped hash of the final published file ties a specific, byte-exact version to a point in time. It doesn’t prove the label was legally sufficient. It does take away an argument about which version existed when.

Showing when the reviewed text was the reviewed text:

If you rely on the human-review exception for public-interest text, you may need to show that the review happened before publication, on the version that went out. Hashing the reviewed draft and the final published text and timestamping both gives you a dated trail of the changes. It won’t prove who did the review or that it was substantive. That still needs your internal sign-off records, and the Commission is clear that someone must hold editorial responsibility. The timestamp supports the sequence of events, not the quality of the review.

Pre-August material:

Content generated before 2 August doesn’t need retroactive labelling. If you hold an archive of images or videos from before that date, a timestamp can help show that a given file existed before it. The word “help” is doing real work here: the record shows the fingerprint existed by that time, not that the file was generated then, and not that it was never altered into a similar file later. A file edited afterwards has a different hash. Still, it’s a better position than a “created” date from a file system, which anyone can change.

There are limits worth stating bluntly:

> A hash is exact. Re-encode a video, add metadata, or run it through a platform that recompresses it, and you have a new file with a new hash. That’s relevant because the Code’s signed metadata changes the bytes. If you want a record of both the pre-marking original and the marked output, hash and timestamp both.

> Anyone can timestamp any file. A blockchain record of an AI image’s hash says nothing about whether the person who made it is the person who requested it.

> A timestamp isn’t a watermark. It doesn’t travel inside the content, so a stranger who finds the image online can’t extract anything from it. It works the other way round: you start from a file you hold and verify it against the record.

That last point is the cleanest way to think about how this relates to C2PA and watermarking. Signed metadata and watermarks travel with the content and answer “what does this file say about itself?” An external anchored hash answers a different question: “did this exact file exist by this date?” They’re complementary, and neither replaces the other. The Code’s “fingerprinting or logging” layer is the nearest relative of what a hash record does, but it’s a provider-side measure for verifying outputs of that provider’s system, and the Code says it can’t stand alone.

If you want the mechanics of timestamping itself, our explainer on trusted timestamping covers it, and the piece on hashing and GDPR deals with the privacy question people usually raise first.

A sensible order of operations for a small publisher

You don’t need a compliance department to get the basics right. A workable sequence:

1- Work out which role you play for each tool you use. Most small teams are deployers of other companies’ systems and providers of nothing.

2- Check whether your content falls under the visible-label rules: realistic synthetic image, audio or video of real-seeming people, places or events, or AI-written public-interest text without editorial control.

3- Put the label where people see it first, not in a footer or a metadata field.

4- Ask your AI vendors how they’re meeting Article 50(2) and whether they’ve signed the Code. If they’re a legacy system, ask what their plan is for 2 December.

5- Keep a dated record of what you published and what review took place. A timestamped hash of final files can be one part of that.

Knowledgebase

Does Article 50 apply to text written with AI help?

Only in a narrow case. Providers must mark generated text outputs under Article 50(2), and deployers must label published AI text on matters of public interest unless it has undergone human review or editorial control. Standard editing assistance and most ordinary business writing fall outside the label duty.

Do I have to label content made before August 2026?

No. The Commission says retroactive labelling isn’t required, though it encourages it where practical.

Is a blockchain timestamp the “machine-readable mark” Article 50 asks for?

No. The mark has to be embedded in or attached to the AI output by the provider, so detection tools can read it. A blockchain timestamp is an external record of a file’s hash. It can support a record-keeping practice, but it doesn’t do the marking job.

Is C2PA mandatory?

The Act doesn’t name it. The Code of Practice asks for digitally signed, tamper-evident metadata, and existing standards such as C2PA are the natural fit, but your provider is responsible for how it meets the requirement.

Who enforces Article 50 and what are the penalties?

Mostly national market surveillance authorities. The AI Office has a limited role, mainly for systems built on general-purpose models where the same entity supplies model and system, and for systems integrated into designated very large platforms. Fines can reach 15 million euros or 3% of worldwide turnover.

What if my file is modified after I timestamp it?

Then its SHA-256 hash changes, and it will no longer match the original record. The timestamp still evidences the original version, but it says nothing about the modified one.

Summary

Article 50 is mostly about visible honesty with audiences and, for providers, about embedding signals in outputs. Provenance technology is the plumbing behind the second part, and it’s still unfinished. The Commission itself says no single technique does everything. Treat any vendor who says otherwise with suspicion.

For publishers, the useful part is plain: know your role, label what needs labelling, and keep records of what you released. If one of those records is a locally computed hash anchored to a public blockchain, you can create a timestamp for a file with Certelo without uploading the file itself. Just be clear with yourself and your clients about what that record shows, which is when a fingerprint existed, and nothing more.

This article is general information, not legal advice. Article 50 obligations depend on your role, your tools and your content. Check your situation with a qualified EU lawyer.