Join our Newsletter — 33% off our NHI Course
Home› Guides› EU Code of Practice on Marking and Labelling…
Guide AI Regulation & Law

EU Code of Practice on Marking and Labelling AI-Generated Content Guide: Multi-Layer Marking, Detection and Deepfake Labels

PDF for newsletter subscribers · free to read online

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 11 November 2026 15 min read
On this page

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.

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.

MilestoneDateWhat changed
First draft17 December 2025Section 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 draft23 January 2026Comments from participants and observers
Second draft12 March 2026Shorter 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 published10 June 2026Multi-layer marking with stated exceptions, four interoperability options for detection, three finalised EU icons, standalone commitments for human review and artistic content
Article 50 applies2 August 2026Deployer obligations in Article 50(4) apply; not deferred by the AI Omnibus
Article 50(2) for existing systems2 December 2026Transitional marking obligation for generative systems already on the market before 2 August 2026 (AI Omnibus)
Interoperable detection2 February 2027Code 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 layerStatus in final CodeWhat it protects againstMain weakness
Metadata (provenance manifest)Core layer; must be digitally signed and time-stamped in a secure, tamper-evident wayForged or edited provenance claims; gives rich information on generator and editsStripped by screenshots, re-encoding and many upload pipelines
Imperceptible watermarkCore layer; mandatory for free-form text over 200 tokensSurvives metadata stripping, some cropping and compressionCan 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 optionsLets any party detect marking without a proprietary keyEasier for an attacker to study and remove
FingerprintingOptional supplementary measureMatches content to a provider's record even when marks are removedRequires storing fingerprints of outputs; privacy and storage cost
Internal loggingOptional supplementary measureLets the provider confirm it generated a given outputData 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 worksBest fit
1. Industry-standard access methodA publicly available API that routes detection queries to the right provider mechanismLarge providers already exposing APIs
2. Public signpost in contentA publicly readable marker embedded in the content says which detection solution to useProviders whose watermark needs a proprietary detector
3. Shared consortium detectorA provider-agnostic detection solution run by a signatory consortium, open to others including SMEsSmaller providers that cannot run their own detection at scale
4. Comparable alternativeAnother solution with equivalent interoperabilityNovel 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

SituationReasonable choiceTrade-off
Provider of a widely used image, video or audio generatorSign; implement signed metadata plus watermark and option 1 or 2 detectionPublic commitments are scrutinised; detection cost at scale
Provider of a niche or SME generative productSign or align; consider option 3 (consortium detector) to avoid running detection aloneDependence on a consortium's availability and governance
Organisation that only uses third-party generatorsDeployer duties only: adopt the EU icons or an equivalent, set editorial review rolesYou 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 responsibilityMust be able to evidence the review process exists and is followed
Provider with a closed hardware productSingle-layer marking may be acceptable under the exceptionDocument 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Set editorial controls. Name the editorial responsible person for public-interest text, document the review process, and keep it in your policy set.
  8. 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 elementRelated framework reference
Marking and detection as legal requirementsEU 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 labellingEU AI Act Article 50(4); Digital Services Act duties for platforms (see the Digital Services Act Security Obligations Guide)
Signed, tamper-evident metadataNIST 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 testingNIST SP 800-53 SA-11 (Developer Testing and Evaluation); NIST AI RMF Measure function
Detection service monitoringNIST SP 800-53 SI-4 (System Monitoring); NIST CSF 2.0 DE.CM-01
Internal processes and literacyEU 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

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.

PDF for subscribers

Take this guide with you

Every section, table and checklist in one PDF, with links to the sources and related guides. Subscribe to our weekly NHI & AI Identity Journal and we’ll email you a download link.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 11 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org

PDF Downloads for Newsletter Subscribers

Get the guide

Enter your details and we’ll email you a download link.

The full guide is free to read online. The PDF is a thank you for subscribing.

Fill in all fields marked * and tick the PDF box to continue.