Article 50 of the EU AI Act says what providers and deployers of generative AI must achieve on marking and labelling, but not how, and the voluntary Code of Practice published on 10 June 2026 is the Commission-facilitated answer to the how. The Code turns the short legal duties in Article 50(2) and 50(4) into concrete commitments: at least two layers of machine-readable marking, a detection service that others can query, a route to interoperable detection by 2 February 2027, and common EU icons for labelling deepfakes and public-interest text. This guide explains what the final Code asks of providers and deployers, how it changed across its three versions, how to build and evidence it, and where it sits next to other frameworks. It is written for product security, ML platform, trust and safety, communications and compliance teams. For the underlying legal duties, read the EU AI Act Article 50 Transparency Obligations Guide first; this page goes deeper on the Code itself.
Source note: Code dates are from the Commission's digital strategy pages; detailed commitments (200-token threshold, one million monthly user fee carve-out, 2 February 2027 interoperability date, three EU icons) are from Freshfields and Gleiss Lutz summaries of the final Code, which agree; AI Omnibus dates are from FPF and White & Case. Confirm against the official text before relying on it.
Key takeaways
- Voluntary, but the obvious benchmark. The Code was drafted by independent experts with the Commission facilitating; signing it is optional, yet it is the most detailed public statement of what "effective, interoperable, robust and reliable" marking means under Article 50(2).
- Two layers is the default. Providers commit to at least two machine-readable marking layers, typically signed, time-stamped metadata plus a watermark, where one technique alone cannot meet the Article 50(2) qualities; free-form text and closed physical products are the single-layer exceptions.
- Detection is part of the deal. Providers keep a detection solution for their own outputs, free in principle, always free for regulators, media, fact-checkers and researchers, and interoperable by 2 February 2027 through one of four routes.
- Deployers get icons and placement rules. Three EU icons (fully AI-generated, AI-modified, and a basic icon with an interactive second layer) and placement principles: visible without user action, at the latest on first exposure, with an audible disclaimer for audio-only content.
- Dates differ by role. Deployer duties under Article 50(4) applied from 2 August 2026; provider marking under Article 50(2) for systems already on the market before that date applies from 2 December 2026 under the AI Omnibus.
What the Code is and its legal status
The Code of Practice on marking and labelling of AI-generated content is a voluntary instrument supporting Article 50 of Regulation (EU) 2024/1689 (the AI Act). The Commission's AI Office facilitated it; independent experts drafted it through a multi-stakeholder process, in the same way as the separate EU General-Purpose AI (GPAI) Code of Practice Guide covers the GPAI code. It is not a harmonised standard and does not create obligations on its own. What it offers a signatory is a documented, Commission-recognised way to show how it meets Article 50(2) and 50(4). Organisations that do not sign must still meet Article 50 and should expect to explain why their alternative is equivalent.
| Milestone | Date | What changed |
|---|---|---|
| First draft | 17 December 2025 | Section 1 for providers (marking and detection), Section 2 for deployers (deepfake and public-interest text labelling); a fully AI-generated versus AI-assisted taxonomy; fingerprinting and logging "where necessary" |
| Feedback deadline on first draft | 23 January 2026 | Comments from participants and observers |
| Second draft | 12 March 2026 | Shorter and more flexible; "two-layered" marking of secured metadata plus watermarking; fingerprinting and logging made optional; AI-generated versus AI-assisted distinction dropped; design and placement rules for labels; illustrative EU icon; regimes for artistic works and for text under editorial control |
| Final Code published | 10 June 2026 | Multi-layer marking with stated exceptions, four interoperability options for detection, three finalised EU icons, standalone commitments for human review and artistic content |
| Article 50 applies | 2 August 2026 | Deployer obligations in Article 50(4) apply; not deferred by the AI Omnibus |
| Article 50(2) for existing systems | 2 December 2026 | Transitional marking obligation for generative systems already on the market before 2 August 2026 (AI Omnibus) |
| Interoperable detection | 2 February 2027 | Code commitment: watermark detection must be interoperable |
The AI Omnibus amending the AI Act was adopted by the European Parliament and the Council in June 2026 and published in the Official Journal on 24 July 2026. It also added a new Article 5 prohibition on AI systems that generate child sexual abuse material and non-consensual intimate material, which sits next to, not inside, the marking regime. Commission guidelines on Article 50 have been out for consultation; check the Commission's AI Act pages for whether they are final before relying on any interpretation that depends on them. Track all of these dates in the EU AI Act Implementation Timeline Tracker.
Provider commitments: multi-layer marking
Article 50(2) requires providers of AI systems that generate synthetic audio, image, video or text to mark outputs in a machine-readable format so they are detectable as artificially generated or manipulated, using solutions that are effective, interoperable, robust and reliable as far as technically feasible. The Code's answer is that one technique rarely meets all four qualities, so providers commit to at least two layers.
| Marking layer | Status in final Code | What it protects against | Main weakness |
|---|---|---|---|
| Metadata (provenance manifest) | Core layer; must be digitally signed and time-stamped in a secure, tamper-evident way | Forged or edited provenance claims; gives rich information on generator and edits | Stripped by screenshots, re-encoding and many upload pipelines |
| Imperceptible watermark | Core layer; mandatory for free-form text over 200 tokens | Survives metadata stripping, some cropping and compression | Can be degraded by heavy editing or paraphrase; needs a detector to read it |
| Public watermark (audio, image, video) | No longer a standalone requirement; one of the interoperability options | Lets any party detect marking without a proprietary key | Easier for an attacker to study and remove |
| Fingerprinting | Optional supplementary measure | Matches content to a provider's record even when marks are removed | Requires storing fingerprints of outputs; privacy and storage cost |
| Internal logging | Optional supplementary measure | Lets the provider confirm it generated a given output | Data retention and data protection obligations; only the provider can query it |
- Single-layer exceptions: generative AI embedded in a closed, technically controlled physical product, and free-form text, which cannot carry metadata. Text up to 200 tokens ("very short text") does not have to be watermarked.
- Model-level marking: requirements were softened in the final text compared with the drafts, so check the Code wording before building marking into model weights rather than the serving layer.
- Open standards: the second draft promoted open standards for marking. In practice signed metadata is usually implemented with Content Credentials under the C2PA specification; see the AI Content Provenance and C2PA Guide and, for watermark design trade-offs, the AI Model Provenance and Watermarking Guide. The Code does not mandate a single named standard.
Provider commitments: detection and interoperability
Marking is only useful if someone can check it. The final Code requires providers to maintain a detection solution for content their system generated or manipulated, with interfaces hosted in the EU or implementable locally and compliant with EU data protection law. Detection is free in principle. Providers with fewer than 1,000,000 monthly users may charge a reasonable, fair and proportionate fee once a single user's volume exceeds a reasonable level, where detection has substantial operating costs. Market surveillance authorities, regulators, law enforcement, media, fact-checkers, trusted flaggers, independent researchers and civil society organisations get detection free and without volume limits.
| Interoperability option (by 2 February 2027) | How it works | Best fit |
|---|---|---|
| 1. Industry-standard access method | A publicly available API that routes detection queries to the right provider mechanism | Large providers already exposing APIs |
| 2. Public signpost in content | A publicly readable marker embedded in the content says which detection solution to use | Providers whose watermark needs a proprietary detector |
| 3. Shared consortium detector | A provider-agnostic detection solution run by a signatory consortium, open to others including SMEs | Smaller providers that cannot run their own detection at scale |
| 4. Comparable alternative | Another solution with equivalent interoperability | Novel modalities; must be justified |
Treat the detection endpoint as a public-facing security service. It is an oracle an adversary can query to test whether their removal technique worked, so rate limiting, abuse monitoring and authenticated access tiers for the free-without-limits groups matter. Identity questions follow directly: how do you verify that a requester is a fact-checker or regulator, and which API keys or OAuth clients do those partners hold? Manage those credentials as you would any other non-human identity; see the Human vs Non-Human Identity explainer.
Deployer commitments: labels, icons and editorial control
Article 50(4) requires deployers to disclose deepfakes (image, audio or video content that resembles real people, objects, places or events and would falsely appear authentic) and AI-generated or manipulated text published to inform the public on matters of public interest. The Code makes this concrete.
- Three EU icons: one for fully AI-generated content, one for AI-modified content, and a basic icon supplemented by an interactive second layer. User testing in several Member States found icons with an explicit text label, such as "modified", were clearer and more noticeable. Using the EU icons is voluntary; an equivalent icon or label that meets the design and placement specification is acceptable.
- Placement principles: the label must be recognisable without user action, visible long enough, embedded directly unless an equivalent alternative exists, and perceivable at the latest on first exposure. Visual disclosure covers images, video and published text; audio-only content needs an audible disclaimer.
- Human review of text: the text exception applies where content has undergone human review or editorial control and someone holds editorial responsibility. The Code asks deployers to name the person with editorial responsibility and document the organisational measures that ensure review, without recording each individual review.
- Artistic, creative, satirical and fictional works: a standalone commitment allows disclosure in a way that does not hamper display or enjoyment of the work. Read the Code text for the conditions rather than assuming any creative use is exempt.
- Internal processes (Commitment 2): proportionate internal processes, awareness and literacy measures, and review and feedback mechanisms. This links to the Article 4 duty covered in the EU AI Act AI Literacy Obligations (Article 4) Guide.
- Sector good practice: signatories and associations may publish sector-specific practices, provided they align with the Code.
Decision guidance: sign, align or build your own
| Situation | Reasonable choice | Trade-off |
|---|---|---|
| Provider of a widely used image, video or audio generator | Sign; implement signed metadata plus watermark and option 1 or 2 detection | Public commitments are scrutinised; detection cost at scale |
| Provider of a niche or SME generative product | Sign or align; consider option 3 (consortium detector) to avoid running detection alone | Dependence on a consortium's availability and governance |
| Organisation that only uses third-party generators | Deployer duties only: adopt the EU icons or an equivalent, set editorial review roles | You rely on the provider's marking; check their documentation and contract terms |
| Text-heavy deployer (news, public sector communications) | Use the human review route with named editorial responsibility | Must be able to evidence the review process exists and is followed |
| Provider with a closed hardware product | Single-layer marking may be acceptable under the exception | Document why the product is closed and technically controlled |
Large organisations are often provider and deployer at once, for example a bank that builds an assistant and also publishes synthetic marketing video. Assign each obligation to a named owner rather than to "the AI team". See the EU AI Act Provider vs Deployer Obligations Guide for role tests.
How to implement
- Inventory generative outputs. List every system that produces audio, image, video or text for people outside the organisation, its modality, its role (provider or deployer) and whether it was on the market before 2 August 2026.
- Choose marking layers per modality. For media: signed, time-stamped metadata plus an imperceptible watermark. For text over 200 tokens: a text watermark. Record any single-layer exception and the reason.
- Protect the signing keys. Metadata signatures are only as trustworthy as the private keys behind them. Hold them in an HSM or cloud KMS, scope signing to the generation service's workload identity, and rotate on a schedule. A leaked signing key lets anyone forge provenance.
- Test robustness before launch. Run a test suite of common transformations (re-encoding, resizing, cropping, screenshots, platform uploads, paraphrase for text) and record detection rates per transformation. Repeat after every model or pipeline change.
- Stand up detection. Build or join a detector, decide your interoperability option for 2 February 2027, publish access terms, and create authenticated tiers for regulators, media and researchers.
- Roll out labels as a deployer. Add the EU icon or equivalent to publishing tools, CMS templates and video players; add audible disclaimers for audio. Pilot with one channel, check that labels survive syndication, then extend.
- Set editorial controls. Name the editorial responsible person for public-interest text, document the review process, and keep it in your policy set.
- Plan rollback. If a watermark degrades output quality or a label placement breaks accessibility, revert to the previous release behind a feature flag while keeping metadata signing on, so you never ship unmarked content.
Detection and measurement
Log every marking event (model version, layers applied, signature key ID, timestamp) and every detection query (requester class, result, latency). Watch for spikes in detection queries from a single client, which may be an adversary testing removal.
- Marking coverage: percentage of outputs carrying all intended layers, by modality and model version; target 100 percent.
- Robustness rate: share of marked test items still detected after each standard transformation.
- Detection availability: uptime and median latency of the detection interface.
- Label coverage: share of published deepfakes and public-interest AI text carrying a compliant label at first exposure, measured by sampling.
- Key hygiene: age of signing keys and time to revoke after suspected exposure.
Framework mapping
| Code element | Related framework reference |
|---|---|
| Marking and detection as legal requirements | EU AI Act Article 50(2) and 50(5); NIST CSF 2.0 GV.OC-03 (legal and regulatory requirements understood and managed) |
| Deepfake and text labelling | EU AI Act Article 50(4); Digital Services Act duties for platforms (see the Digital Services Act Security Obligations Guide) |
| Signed, tamper-evident metadata | NIST SP 800-53 SC-12 (Cryptographic Key Establishment and Management), SC-13 (Cryptographic Protection); ISO/IEC 27001:2022 Annex A 8.24 (use of cryptography) |
| Robustness testing | NIST SP 800-53 SA-11 (Developer Testing and Evaluation); NIST AI RMF Measure function |
| Detection service monitoring | NIST SP 800-53 SI-4 (System Monitoring); NIST CSF 2.0 DE.CM-01 |
| Internal processes and literacy | EU AI Act Article 4; NIST CSF 2.0 GV.PO-01; ISO/IEC 42001 AI management system |
Common failure patterns
- Metadata only. Relying on a provenance manifest that the first social upload strips. The Code expects a second layer precisely because of this.
- Unprotected signing keys. Keeping the metadata signing key in an application config file or container image makes every signature forgeable.
- Assuming labels stop fraud. Marking and labelling apply to compliant providers and deployers; criminal deepfakes will not carry them. The Arup deepfake fraud succeeded through a convincing video call, so payment controls and identity verification still matter. See the Deepfake-Resistant Identity Verification Guide.
- Detection as an open oracle. An unrestricted detection API lets attackers iterate removal techniques. Rate limit and monitor.
- Treating editorial review as a tick box. Claiming the human review exception without a named responsible person or documented process.
- Missing the December date. Teams that read only "2 August 2026" may miss that legacy generative systems must be marked from 2 December 2026.
Practitioner checklist
- Inventory every generative output channel with modality, role and market date.
- Decide whether to sign the Code, align with it, or document an equivalent approach.
- Implement at least two marking layers for media and watermarking for text over 200 tokens.
- Hold metadata signing keys in an HSM or KMS bound to a workload identity, with rotation.
- Run and record robustness tests on every model or pipeline release.
- Operate a detection interface with authenticated free tiers and abuse monitoring.
- Choose an interoperability option ahead of 2 February 2027.
- Add EU icons or equivalent labels and audible disclaimers to publishing tools.
- Name editorial responsibility for public-interest text and document the review process.
- Recheck the Commission's Article 50 guidelines and Code pages each quarter.
Standards and references
- European Commission: Commission publishes Code of Practice on marking and labelling AI-generated content
- European Commission: Commission publishes first draft Code of Practice on marking and labelling AI-generated content
- EUR-Lex: Regulation (EU) 2024/1689 (Artificial Intelligence Act)
- Future of Privacy Forum: The AI Act Implementation Timeline, What Changes Under the AI Omnibus
- Freshfields: EU AI Act unpacked, the final Code of Practice on transparency of AI-generated content
- Society for Computers and Law: Second draft of the Code of Practice on marking and labelling
- C2PA: Content Credentials Technical Specification
Related NHI Mgmt Group resources: EU AI Act Article 50 Transparency Obligations Guide · AI Content Provenance and C2PA Guide · Deepfake and AI Impersonation Guide · EU AI Act Compliance Guide. This guide summarises the EU Code of Practice on marking and labelling of AI-generated content as checked on 11 November 2026 and is not legal advice.