Skip to content

The EU AI Act's Machine-Readable Marking Duty for Synthetic Content

10 min read · updated August 11, 2026

Article 50 of the AI Act contains several different transparency duties that are routinely discussed as one. The first paragraph is about chatbots, the fourth is about deepfakes and is a deployer duty, and the second — the subject of this page — is a technical duty on whoever builds the generative system, and it applies whether or not any human ever sees the output.

What Article 50(2) actually says

Under Regulation (EU) 2024/1689, providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video or text content must ensure that the outputs are marked in a machine-readable format and detectable as artificially generated or manipulated. The provision requires the technical solutions to be effective, interoperable, robust and reliable as far as this is technically feasible, taking into account the specificities and limitations of the types of content, the costs of implementation and the generally acknowledged state of the art, as reflected in relevant technical standards. The text is at EUR-Lex.

Four words carry the obligation. Machine-readable means the mark is for software, not for a person — a visible “made with AI” badge on a webpage satisfies nothing here. Detectable means a third party must be able to establish that the content is synthetic. Outputs means all of them, not the ones you publish. Interoperable means a proprietary mark only your own detector can read is on weak ground, because the point of the duty is downstream verification by people who are not you.

This is a description of the provision and not legal advice. Whether you are a provider within the meaning of Article 3(3), and therefore whether this duty is yours at all, depends on whether you develop and place a system on the market or put it into service under your own name or trade mark — a determination that catches more organisations than expect it. Take advice on your own facts.

Provider, not deployer

The allocation is the thing most worth getting right, because the two duties in Article 50 have different holders, different content, and different remedies if you get them wrong.

  • Article 50(2) — provider. Mark the output machine-readably at generation. Technical, invisible, applies to every output of a generative system.
  • Article 50(4) — deployer. Disclose that content is artificially generated or manipulated, where it constitutes a deep fake; and for text published to inform the public on matters of public interest, disclose artificial generation, subject to carve-outs including where the content has undergone human review and someone holds editorial responsibility. Human-facing, contextual, applies to publication. Covered separately in the deepfake labelling duty.

Two consequences follow that surprise people. A company that fine-tunes an open-weights model and offers it as a product is likely a provider and therefore carries the 50(2) duty itself, rather than inheriting compliance from the original model. And a company that merely calls somebody else’s API to generate images for its own marketing is a deployer: it does not owe 50(2), but it may owe 50(4), and it cannot discharge 50(4) by pointing at the provider’s watermark, because a machine-readable mark is not a disclosure to a reader. On the provider/deployer boundary generally see provider versus deployer.

The exceptions in the second sentence

Article 50(2) carves out systems performing an assistive function for standard editing, and systems that do not substantially alter the input data provided by the deployer or its semantics. The carve-out is narrower than it is often read to be.

A spelling corrector, a colour-balance adjustment or a crop is standard editing. A model that rewrites a paragraph into a different register, or that removes an object from a photograph and inpaints the background, is substantially altering the semantics of the input and is not within the carve-out. The line is about semantic alteration rather than about how much of the pixel data changed, which means the answer for a given feature depends on what the feature does to meaning — and that is the sort of question on which reasonable people will disagree until guidance or a court settles it. It has not been settled.

What counts as machine-readable marking

The Act does not prescribe a technique. Recital 133 lists candidates — watermarks, metadata identifications, cryptographic methods for proving provenance and authenticity, logging methods, fingerprints — and leaves the choice to the provider subject to the effectiveness and interoperability requirements. In practice three families are in use, with different failure modes:

  • Signed provenance metadata. C2PA Content Credentials attach a cryptographically signed manifest describing how an asset was made. Strong on interoperability and verification, weak against stripping: metadata does not survive a screenshot, and most social platforms have historically removed it on upload. See C2PA as a compliance mechanism.
  • Embedded watermarks. A signal in the pixels, the audio waveform or the token distribution, detectable by a matching detector. More robust to re-encoding and screenshots, but detection generally requires the provider’s own detector, which is in tension with “interoperable” unless the detector is made available.
  • Text. The hard case, and the reason “as far as technically feasible” is in the provision at all. Statistical watermarking of generated text degrades badly under paraphrase, and short outputs carry too few tokens to hold a signal. No approach currently claims robust detection of arbitrary short generated text, and a provider relying on the feasibility qualifier should document why — the qualifier is an argument you have to be able to make, not a general excuse.

When it applies, and what is still moving

The transparency obligations in Article 50 apply from 2 August 2026 under the application timetable in Article 113. That date is later than the prohibitions, which applied from 2 February 2025, and later than the GPAI chapter, which applied from 2 August 2025 — see the AI Act timeline.

Two things about the date are genuinely uncertain and should be treated as such. Article 50(7) contemplates codes of practice to facilitate detection and labelling, drawn up with the AI Office, and the harmonised standards that would define “state of the art” for this purpose are being developed through CEN-CENELEC JTC 21 rather than being finished; see the JTC 21 standards work. And the Commission has brought forward proposals to amend parts of the Act’s timetable. A proposal is not law: until an amending regulation is adopted and published in the Official Journal, the dates in the consolidated text are the dates that apply. Check the consolidated text on EUR-Lex rather than any secondary account, including this one.