A notice and a machine-readable mark do different jobs
Trace the actor, the output and the evidence needed to evaluate a marking method.
AI-assisted learning visualization · schematic article explanation
Article 50 assigns different tasks to providers and deployers. Identify the system and intended use before deciding which paragraph applies.
Article 50 of the EU AI Act contains several different transparency duties. Paragraph 2 requires providers of AI systems that generate synthetic audio, image, video or text to ensure outputs are marked in a machine-readable format and detectable as artificially generated or manipulated. Its technical solutions must be effective, interoperable, robust and reliable as far as technically feasible, taking account of content limitations, implementation costs and the acknowledged state of the art. The paragraph also contains exceptions, including certain assistive editing and law-enforcement uses.1
Article 50 has applied since 2 August 2026. Regulation (EU) 2026/1744 added a narrow transition: providers of qualifying generative systems placed on the market before 2 August 2026 must comply with paragraph 2 by 2 December 2026. This date does not postpone the other Article 50 duties.2
Match the duty to the actor
| Paragraph | Actor | Core duty |
|---|---|---|
| 50(1) | Provider | Design a system intended for direct interaction so a natural person is informed of the AI interaction, unless obvious in context |
| 50(2) | Provider of a generative system | Machine-readable marking and detectability of covered synthetic outputs, subject to the paragraph's conditions |
| 50(3) | Deployer | Inform persons exposed to covered emotion-recognition or biometric-categorisation systems |
| 50(4) | Deployer | Disclose certain deepfakes and AI-generated text published to inform the public on matters of public interest, subject to specific exceptions |
Paragraph 5 requires the information in paragraphs 1–4 to be clear and distinguishable, and provided at the latest at first interaction or exposure. Paragraph 4 does not generally require the disclosure to be embedded in the media file itself. Nor does using a third-party API always settle who the provider of a downstream system is; role allocation depends on the actual system and deployment.1 The self-hosting guide explains that distinction.
Three technical approaches
Provenance metadata such as a signed C2PA manifest records assertions about a file and its history. The signature can reveal tampering when the manifest remains available. A distribution pipeline can also drop metadata; a missing manifest alone does not establish that content is human-made. C2PA specifies soft-binding mechanisms to help reconnect content to provenance when the ordinary binding is lost.3
Embedded watermarks introduce a signal in generated pixels, audio or token choices that a corresponding detector can test. Google documents that SynthID Text detection becomes less reliable after substantial rewriting or translation and works better on longer, varied passages.4 Detection is statistical; a positive result is not proof of authorship, and a negative result is not proof of human origin.
Post-hoc detectors attempt to classify content without relying on a mark inserted by its generator. Their accuracy depends on the tested distribution, transformation and adversary. They are not interchangeable with a provider's Article 50(2) marking duty.
These approaches can complement one another. Article 50(2) does not mandate a named watermark product, require immunity to every hostile edit, or say that C2PA alone is sufficient or insufficient in all deployments. Compliance needs a system- and content-specific technical assessment against the statutory criteria and applicable guidance.
What attack papers actually show
Jovanović, Staab and Vechev showed in the schemes and experimental settings they studied that a black-box attacker could approximate watermark behaviour for under US$50 in API costs and achieve average spoofing and scrubbing success above 80%.5 This is evidence of a serious failure mode for those text watermark schemes; it does not prove that every deployed watermark in 2026 has the same cost or success rate.
Saberi and colleagues analysed image detectors and watermark schemes under diffusion purification and model-substitution attacks. Their paper reports a trade-off between evasion and spoofing errors for the low-perturbation schemes under its attack model, and practical attacks on selected higher-perturbation schemes.6 It does not determine whether a particular provider meets Article 50(2). The legal phrase “as far as technically feasible” requires attention to the state of the art and to the circumstances of the content; an attack result is one input to that assessment, not an automatic finding of non-compliance.
Practical checks
A provider should identify which of its systems and outputs fall under paragraph 2, test marking and detectability on realistic content and normal transformations, document known limits and revisit the choice as standards and guidance develop. A deployer should separately check paragraph 3 and 4 disclosure duties and verify the provider's marking information where relevant. For a directly interactive system, the provider should check paragraph 1 and the person responsible for the user experience should test whether the notice actually reaches users. Document the role decision, implementation and exceptions rather than promising that all generated content can always be detected.
Legal and technical sources checked on 29 September 2026. This is general information, not individual legal advice.
Footnotes
-
AI Act Article 50, paragraphs 1–5; the Service Desk notes its displayed text may not yet incorporate Omnibus changes. ↩ ↩2
-
Regulation (EU) 2026/1744, Article 1(39)(b), inserting Article 111(4). ↩
-
C2PA Technical Specification 2.4, including manifests and soft bindings. ↩
-
Google, SynthID Text documentation. ↩
-
Jovanović, Staab and Vechev, “Watermark Stealing in Large Language Models”, ICML 2024. ↩
-
Saberi et al., “Robustness of AI-Image Detectors: Fundamental Limits and Practical Attacks”, ICLR 2024. ↩