ISHIGHRISK AI
Analysis

Meeting the Article 50(2) marking duty

Article 50(2) wants marking that is effective, interoperable, robust and reliable. What that means in practice, and which systems the December date helps.

Published Regulation (EU) 2024/1689, as amended by the Digital Omnibus
In short

If your generative system was placed on the EU market before 2 August 2026 you have until 2 December 2026 to mark its output; if you place it from 2 August 2026 onwards the duty attaches at placement with no transitional relief at all, which is the trap for any generative feature shipped this autumn. Article 50(2) prescribes no technique, only that marking be effective, interoperable, robust and reliable as far as technically feasible, given content-type limitations, implementation costs and the generally acknowledged state of the art. In practice that rules out both a proprietary scheme nobody else can read and a metadata-only scheme that a routine re-encode strips, which is why the Code of Practice expects at least two layers. Text is the weakest case technically and the state of the art does not support marking short free-form outputs at all.

Which date is yours

There are two populations and the answer differs completely between them. Establish which one you are in first.

2 Aug 2026Systems placed on the EU market on or after this date owe Article 50(2) marking from the moment of placement. There is no transitional relief for them.
2 Dec 2026Generative systems already placed on the EU market before 2 August 2026 must be marking output by this date.

The transitional period runs four months, per recital 38 of Regulation (EU) 2026/1744, which grants "a transitional period of four months for providers who have already placed their systems on the market before the 2 August 2026". A three-month figure circulates in secondary summaries and is wrong. Work from the date rather than the month count.

The trap is the second population. A team that ships a new generative feature in September or October 2026 gets no grace whatever: the duty applies on placement, and every unmarked output from that point is exposure. Older products carrying a legacy pipeline get the four months, new ones built after the rules were known get none, which is why "the marking deadline moved to December" is such an expensive thing to hear as a general reprieve. The rest of Article 50 gives no cover either, because 50(1), 50(3) and 50(4) all applied on 2 August 2026 as drafted. The amending regulation moved one limb of Article 50 only.

The four criteria, and the qualifier

Article 50(2) obliges providers of systems generating synthetic audio, image, video or text to ensure the outputs are marked in a machine-readable format and detectable as artificially generated or manipulated. It names no technique. It sets four adjectives: the technical solutions must be effective, interoperable, robust and reliable.

Each one rules something out, and the exclusions are the useful part.

  • Effective excludes marking that is optional, off by default, or applied at the interface rather than at generation. A mark the API path skips because only the web app implements it is not effective.
  • Interoperable excludes a proprietary scheme that only your own detector can read. The point of machine-readable marking is that a platform, a journalist or an authority can test a file without asking you.
  • Robust excludes marking that ordinary handling removes. Content is re-encoded, cropped, screenshotted and re-uploaded as a matter of routine, so a scheme stripped by a single platform upload is not robust in any useful sense.
  • Reliable excludes a detector that answers inconsistently. False negatives on your own unmodified output and false positives on human-made content both fail the criterion, and the false positive is the more damaging of the two.

All four are qualified by Art 50(2)itself: they bind only as far as this is technically feasible, taking into account the specificities and limitations of the various types of content, the costs of implementation and the generally acknowledged state of the art. That qualifier is real relief, particularly for text, and it is also the part most likely to be over-read. It is indexed to the state of the art, which moves, so a feasibility judgement is only good as at the date it was made. An undated "not technically feasible" is an assertion. A dated note naming the techniques you evaluated and why each fell short is evidence.

The editing exceptions, read narrowly

Two editing categories sit outside the duty. Systems performing an assistive function for standard editing are excepted, as are systems that do not substantially alter the input data provided by the deployer, or the semantics of that data. There is a separate carve-out for systems authorised by law to detect, prevent, investigate or prosecute criminal offences.

Both editing limbs describe the same situation: a system that helps with content the deployer already has, rather than one that manufactures content the deployer did not have.

Inside the exceptionOutside it
Auto-levels, white balance, denoise, sharpeningGenerative fill and outpainting beyond the original frame
Crop, rotate, resize, format conversionObject removal and background replacement
Spelling and grammar correctionExpanding bullets into paragraphs of new prose
Audio noise reduction and level normalisationVoice conversion and synthetic re-speaking of a recording
Subtitle formatting and timingTranslation-and-lip-sync that puts new words in a real mouth

The exception is read narrowly for a structural reason. It sits inside a transparency provision whose purpose is that people and systems downstream can tell synthetic content apart, and an exception broad enough to cover anything a product team calls "editing" would swallow the rule, because most generative features ship inside an editor. The second limb also carries a limit that is easy to miss: it turns on input data provided by the deployer, so a system generating from a prompt alone has no input content to leave unaltered and cannot reach that limb at all.

The practical test is not "is this feature in an editing product?" but "could a viewer who trusted the output be misled about what was really there?" Sharpening a photograph does not change what the camera saw. Removing a person from it does.

What the state of the art supports, by modality

Two families of technique are in general use. Cryptographically signed provenance metadata, of which C2PA is the widely known open specification, attaches a manifest recording how the content was produced. Invisible watermarking embeds a detectable signal in the content itself, in pixels, in the audio spectrum, or in the token choices a language model makes.

Their weaknesses are complementary. Provenance metadata is interoperable by design and fragile: it lives beside the content, so re-encoding, screenshotting and most upload pipelines discard it. Watermarking survives handling far better and is harder to verify independently, because detection commonly requires the provider's own detector, which is the interoperability gap the second criterion aims at. Neither family alone covers all four criteria for most content types, which is the technical reason multi-layered marking exists.

ModalityWhat is availableKnown failure modesPractical read
ImageSigned provenance manifest plus pixel-domain invisible watermarkManifest stripped by re-encode, screenshot and most upload paths; watermark degrades under heavy crop, downscale and repeated compressionTwo layers, and the most mature case
VideoContainer-level manifest plus frame-level watermarkingTranscoding rewrites the container and drops the manifest; frame marks survive better but cost more to embed and detect at scaleAssume the container metadata never reaches the viewer
AudioFile-level manifest plus spectral-domain watermarkRe-recording through speaker and microphone, lossy compression, pitch and speed shiftsWatermark carries the load, manifest carries the label
Text, long formSampling-based statistical watermarks, plus document-container metadataParaphrase, translation, copy-paste into a plain text field; signal falls with output entropyWeakest modality, where the feasibility qualifier bites
Text, short or low entropyLittle that meets all four criteriaToo few tokens to carry a detectable signal; code and structured output leave almost no free choice to encode intoThe Code's 200-token exemption recognises this

The honest position on text

Text is where the gap between the statutory ambition and the available techniques is widest, and pretending otherwise helps nobody. Statistical watermarking works by biasing which tokens a model selects, so the signal is a function of how much freedom the model had. A long, discursive answer offers plenty. A two-sentence reply, a product description, a JSON payload or a block of code offers almost none. Paraphrasing, translating or retyping the output removes what signal there was, and none of that requires intent to evade.

This is what the qualifier in Article 50(2) is for: the specificities and limitations of the various types of content are named in the provision itself, and text is the clearest case of limitations that are structural rather than a matter of effort. That does not put text out of scope, because it is expressly in scope. It means a provider who marks long-form text with the best available technique, attaches provenance metadata where a document container exists, and documents why short free-form output is not markable, is in a defensible position. A provider that has done nothing and assumes text is exempt is not.

The Code of Practice as the de facto route

The Code of Practice on transparency of AI-generated content was published in final form on 10 June 2026. It is voluntary, and adhering to it is not compliance with Article 50(2) as a matter of law. It matters anyway, because it is the only detailed articulation of what the four adjectives mean in engineering terms, which makes it the likely de facto route to demonstrating you met them.

Four features of it drive design decisions.

  1. Multi-layered marking. At least two layers where a single technique cannot meet all four statutory criteria on its own. For image, video and audio that is effectively always, which is why a manifest plus a watermark is the working default rather than a belt-and-braces option.
  2. The 200-token exemption.Free-form text under 200 tokens is exempt from the Code's expectations. That is the Code drawing the line the state of the art forces, not a statutory exemption from Article 50(2), and the distinction is worth keeping straight in your documentation.
  3. The closed-physical-product exemption. Generative systems embedded in closed physical products are exempt, on the same logic: where the output never enters a distribution chain, machine-readable marking has nothing to protect.
  4. Detection interoperability from 2 February 2027.The Code's watermark-detection commitment begins on that date. It is voluntary and not a statutory deadline, so it does not appear on the statutory timeline. It is still the point at which the second criterion stops being satisfiable by promise, because a detector nobody outside your company can run is a non-interoperable scheme.

Marking is not the deployer disclosure

Article 50(2) is a provider duty and it is machine-facing. Article 50(4) is a deployer duty and it is human-facing. Conflating them produces two errors: a provider that thinks a visible "AI-generated" caption discharges 50(2), and a deployer that thinks its vendor's watermark discharges 50(4).

Under 50(4)(a) deployers of AI generating or manipulating image, audio or video content constituting a deepfake must disclose that it is artificially generated or manipulated. A deepfake is defined in Article 3(60) as content resembling existing persons, objects, places, entities or events that would falsely appear authentic or truthful. Where the content is evidently artistic, creative, satirical or fictional, the disclosure is limited to a form that does not hamper the display or enjoyment of the work. Under 50(4)(b) deployers publishing AI-generated text to inform the public on matters of public interest must disclose it, unless it underwent human review or editorial control and a natural or legal person holds editorial responsibility for the publication.

A single synthetic video can carry both duties at once: the provider marks the file so a detector can identify it, and the deployer tells the audience. Neither substitutes for the other. Which role you occupy is less obvious than it looks once fine-tuning and white-labelling enter the picture, and the Article 2 exclusion for free and open-source systems does not help, because it falls away for systems subject to Article 50. The provider and deployer roles page works through the boundary.

An Article 50 breach sits in the middle penalty tier: 15,000,000 euro or 3 percent of total worldwide annual turnover, whichever is higher, with SMEs and start-ups paying the lower under Article 99(6). Those provisions have been enforceable since 2 August 2025 and AI Office enforcement began on 2 August 2026. The tiers are set out on the penalties page.

If you are inside the transitional period, four months is roughly the lead time for getting marking into a generation pipeline and a detector into the hands of the people who need it, so the runway is adequate rather than generous. Inventory every output modality the system really produces, decide the two layers for each one, and record the feasibility reasoning where a modality defeats you. If you are outside it, the duty already applies and the first question is what your exposure has been since placement.

Check your own system

The free classifier walks the same tests in order and tells you which of them your system actually trips, with the article each answer rests on.

Run the triage →

Frequently asked questions

How do I watermark AI-generated content for the EU AI Act?

Article 50(2) prescribes no technique. It requires the output to be marked in a machine-readable format and detectable as artificially generated or manipulated, using solutions that are effective, interoperable, robust and reliable as far as technically feasible. In practice that means signed provenance metadata such as a C2PA-style manifest for interoperability, plus an invisible watermark embedded in the content itself for robustness, because metadata alone is removed by ordinary re-encoding. The voluntary Code of Practice on transparency of AI-generated content expects at least two layers wherever one technique cannot meet all four criteria on its own.

Is C2PA metadata enough on its own for Article 50(2)?

Usually not. A signed provenance manifest is machine-readable and interoperable, which covers two of the four criteria well, but it travels alongside the file rather than inside the content, so a screenshot, a re-encode or an upload pipeline that rewrites the container removes it. Marking that a routine platform upload strips is difficult to call robust. The workable pattern is a manifest for the interoperable label and an in-content watermark for survivability.

Does an AI photo editor have to mark its output?

It depends on what the edit does. Article 50(2) excepts systems performing an assistive function for standard editing, and systems that do not substantially alter the input data provided by the deployer or the semantics of that data. Auto-levels, denoise, crop and sharpening sit comfortably inside that. Generative fill, background replacement, object removal and anything that inserts content which was never in the frame change the semantics of the image and are outside it.

Does Article 50(2) marking apply to text?

Yes. The provision covers systems generating synthetic audio, image, video or text, so text output is in scope for the provider marking duty. The technical position on text is weaker than on the other modalities, because paraphrase, translation and a copy-paste into a plain text field defeat most schemes, and short outputs carry too little signal to mark at all. The Code of Practice exempts free-form text under 200 tokens from its own expectations, but that is the Code's threshold rather than an exemption from Article 50(2) itself.

What is the difference between Article 50(2) and Article 50(4)?

Article 50(2) is a provider duty to mark output in a machine-readable format at the point of generation, so that a detector can tell the content was artificially generated. Article 50(4) is a deployer duty to tell people: to disclose deepfake image, audio or video content, and to disclose AI-generated text published to inform the public on matters of public interest. They can both attach to the same file, and discharging one does not discharge the other.

Is the Code of Practice on transparency of AI-generated content mandatory?

No. It was published in final form on 10 June 2026 and it is voluntary. It matters because it is the only detailed articulation of what effective, interoperable, robust and reliable mean in practice, which makes it the de facto yardstick for Article 50(2). It sets multi-layered marking as the default, exempts free-form text under 200 tokens and generative systems embedded in closed physical products, and its watermark-detection interoperability commitment begins on 2 February 2027.

This article is analysis, not legal advice. It reflects Regulation (EU) 2024/1689 as amended by the Digital Omnibus, Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force since 27 July 2026, as that text stood at the last site review on 4 August 2026. Final classification for ambiguous cases needs qualified counsel.