For two years, the question that has hung over the EU AI Act’s transparency provisions has been deceptively simple: how, exactly, are we supposed to do this? Article 50 tells providers to mark AI-generated content in a “machine-readable format” and tells deployers to label deepfakes “clearly.” It does not tell anyone which technology counts as machine-readable, what a sufficient label looks like, or how robust a watermark must be before a regulator considers it adequate. On June 10, 2026, the European Commission and the European AI Office answered that question - or at least gave the first concrete, government-blessed answer - by publishing the final Code of Practice on Transparency of AI-Generated Content, also referred to as the Code of Practice on marking and labelling AI-generated content.
The timing is not accidental. Article 50 becomes binding on August 2, 2026, roughly seven weeks after the Code’s publication. Compliance teams that have spent the year waiting for clarity now have a playbook - and a very short runway to implement it. This article explains what the Code requires, how it relates to the binding law, the difference between provider marking duties and deployer disclosure duties, the technical mechanisms it endorses, and the timeline every organization deploying generative AI in the EU needs to plan against, including the transitional grace period that runs to December 2, 2026.
The binding obligation: what Article 50 actually requires
The Code is guidance. Article 50 is law. Before discussing the Code, it is worth being precise about the underlying obligation, because the Code’s entire structure mirrors the statute.
Article 50 imposes transparency duties that apply broadly - not only to high-risk AI systems - and they take effect on August 2, 2026. The four core provisions are:
- Article 50(1) - AI interaction disclosure (provider duty). Providers of AI systems intended to interact directly with people, such as chatbots and virtual assistants, must design those systems so that a natural person is informed they are interacting with AI, at the latest at the time of first interaction. There is a narrow exception where it would be obvious to a reasonably well-informed, observant and circumspect person that they are dealing with a machine.
- Article 50(2) - machine-readable marking of synthetic output (provider duty). Providers of generative AI systems must ensure that their outputs - across text, audio, image and video - are marked in a machine-readable format and detectable as artificially generated or manipulated. The marking solutions must be effective, interoperable, robust and reliable as far as technically feasible. Assistive editing functions that do not substantially alter input, and systems lawfully authorized for criminal-offense detection, are carved out.
- Article 50(3) - emotion recognition and biometric categorization (deployer duty). Deployers of these systems must inform the people exposed to them.
- Article 50(4) - deepfakes and public-interest text (deployer duty). Deployers who use AI to generate or manipulate image, audio or video content constituting a deepfake must disclose that the content is artificially generated or manipulated. Deployers who publish AI-generated or AI-manipulated text to inform the public on matters of public interest must likewise disclose that fact - unless the content underwent human review with editorial responsibility for its publication.
The Code of Practice addresses the two provisions where the “how” was most contested and most technical: Article 50(2) for providers and Article 50(4) (read together with the labelling specifics carried in 50(5)) for deployers. It does not attempt to resolve every disclosure question under 50(1) or 50(3); its center of gravity is marking synthetic media and labelling deepfakes and public-interest text.
This split tracks a real division of responsibility. Providers build the marking into the content at generation. Deployers make it visible to the public at publication. The two duties are sequential, and a failure at either end breaks the chain. For the broader picture of what else lands on August 2, see our August 2, 2026 sixty-day countdown synthesis.
What the Code is - and what it is not
The single most important thing to understand about the Code of Practice is that adherence is voluntary. The Commission’s FAQ states it plainly: “Adherence to the code of practice is voluntary.” Signing it creates no new legal obligation, and refusing to sign it is not itself a violation of anything. The binding obligation is Article 50, and it applies to every provider and deployer in scope whether or not they ever read the Code.
So why sign? Because the Code is the closest thing to a safe-harbor map the AI Office is willing to draw before harmonized standards exist. By signing, providers and deployers “signal their intention to adhere to its commitments” and gain, in the Commission’s words, “a streamlined way to ensure and demonstrate compliance with Article 50(2) and Article 50(4) of the AI Act,” along with “greater predictability, legal certainty across the EU and reduced administrative burdens.” The Code explicitly “does not replace the AI Act”; it provides “a practical framework for signatories to demonstrate compliance.”
In practical terms, an organization that implements the Code’s mechanisms has a documented, government-recognized basis for arguing it met the statutory standard - a meaningful advantage when the underlying text uses elastic words like “effective,” “robust” and “clearly distinguishable.” The Code does not grant a formal legal presumption of conformity the way a harmonized European standard eventually will; it is softer than that. But until those standards arrive, it is the best available evidence of good-faith compliance, and the AI Office has signaled that future enforcement will look at adherence.
This is the same logic that drove participation in the General-Purpose AI Code of Practice for foundation-model providers: a voluntary instrument that becomes the de facto compliance benchmark precisely because it is the only detailed guidance in the field. The Transparency Code is its analogue for the marking-and-labelling obligation, and many providers will find themselves signing both.
Who can sign. Any provider or deployer of a generative AI system with current or planned EU operations is eligible. The mechanics are deliberately low-friction: complete the signatory form and email it, signed by a person authorized to bind the organization, to the AI Office’s transparency mailbox. There is no application gauntlet - signing is a declaration of intent to comply, not a certification.
The two marking mechanisms (plus an optional third)
The heart of the Code, and the part compliance and engineering teams will spend the most time on, is Section 1, which addresses provider marking duties under Article 50(2). The Code endorses two core mechanisms and one optional supplement.
1. Digitally signed metadata
The first and primary mechanism is recording provenance information directly in the content’s metadata: an attestation of whether the content is AI-generated or manipulated, cryptographically signed and timestamped “in a secure and tamper-evident manner.” In practice this means provenance credentials of the kind defined by the C2PA (Coalition for Content Provenance and Authenticity) standard - the same Content Credentials approach already shipping in major image and video tools. The Code does not name C2PA in its binding text, but it describes the standard’s defining features, and industry observers have noted that C2PA is at present effectively the only deployed technology meeting the Code’s criteria for tamper-evident, signed, interoperable metadata.
Metadata-based marking has one well-known weakness: metadata is easy to strip. A screenshot, a re-encode, or a copy-and-paste can destroy a C2PA manifest. The Code addresses this directly by layering obligations on providers beyond simply writing the metadata. Providers should preserve existing provenance markings rather than discarding them when AI-generated content is fed back in as input, and should prohibit the intentional removal of markings in their terms of service.
2. Imperceptible watermarking
Because metadata is fragile, the Code’s second core mechanism is imperceptible watermarking - signals embedded into the content itself (the pixels, the audio waveform, the token distribution of generated text) that survive transformations metadata cannot. A watermark travels with the content even after a screenshot or a format conversion, which is exactly the resilience metadata lacks.
The two mechanisms are complementary rather than alternative. Metadata is rich, human-auditable and standardized but brittle; watermarking is robust but lower-bandwidth and, depending on modality, harder to make both imperceptible and reliable. A serious implementation under Article 50(2) will generally use both: signed metadata as the primary, detailed provenance record and an imperceptible watermark as the durable fallback when metadata is lost.
3. Optional fingerprinting with a registry
The third mechanism is optional: fingerprinting combined with a logging registry. Here the provider computes a fingerprint (a perceptual hash) of generated content and logs it to a registry database, so that content can later be checked against the registry to determine whether it originated from that provider’s system. This is more operationally demanding - it requires running and maintaining queryable infrastructure - which is why the Code treats it as a supplement rather than a baseline expectation.
Detection and interoperability
Marking is useless if no one can read it. The Code therefore requires providers to make detection available free of charge to the public, through one of several routes: an open specification, downloadable software, or a cloud-based API. It also pushes toward interoperability so that verifiers do not have to query every provider’s bespoke system individually - the target being a publicly available, interoperable industry standard (again pointing toward C2PA-style ecosystems), with interoperability expectations articulated on a timeline running into early 2027.
Deployer duties: labelling deepfakes and public-interest text
Where Section 1 is about machines marking content invisibly, Section 2 is about humans seeing a visible label. It operationalizes the Article 50(4) deployer obligations.
Deepfakes. A deployer who uses a generative AI system to produce a deepfake - AI-generated or manipulated image, audio or video that resembles real persons, objects, places or events and would falsely appear authentic - must disclose that the content is artificial. The Code offers concrete presentation patterns: persistent visual labels on images, an opening disclaimer for video, an audible notice for audio. Crucially, the deployer is expected to make the underlying provenance marking visible - to surface the provider’s machine-readable marking in human-perceptible form, using standardized EU icons the Commission has published for the purpose. Disclosure must be clear and distinguishable, provided at the latest at the time of first exposure. Tiny footer text, a label that flashes for an instant, or a disclosure buried in terms and conditions will not satisfy the standard.
There is a meaningful creative-works exception: for evidently artistic, satirical, fictional or analogous works, disclosure is limited to indicating that generated or manipulated content exists, in a manner that does not hamper the display or enjoyment of the work. Content that is plainly fantastical - dragons, impossible physics - falls outside the deepfake definition entirely because it does not falsely appear authentic.
Public-interest text. A deployer who publishes AI-generated or AI-manipulated text to inform the public on matters of public interest must disclose its artificial origin. The key carve-out is editorial: if the text underwent genuine human review and a person or organization holds editorial responsibility for its publication, the labelling obligation falls away. Superficial or cursory sign-off does not count; the human review must be substantive.
Chatbot disclosure. While the chatbot duty sits in Article 50(1) (a provider design obligation) rather than 50(4), it belongs in any practical compliance picture: users must be told when they are interacting with an AI system such as a chatbot, at the latest at the time of first interaction, unless it is obvious. Deployers operating customer-facing conversational AI should confirm that the disclosure their provider built in is actually surfaced in the deployed product, and not suppressed by a custom front end.
The timeline, including the December 2 transition
The dates are where many organizations will either find relief or get caught out.
- June 10, 2026 - The final Code of Practice is published; the signatory window opens.
- August 2, 2026 - Article 50 transparency obligations become legally binding and enforceable. From this date, generative AI output must be machine-readable-marked, deepfakes and public-interest text must be labelled, and users must be told when they are talking to a chatbot.
- December 2, 2026 - End of the transitional period for systems that were already placed on the market or put into service before August 2, 2026. Pre-existing generative AI systems get this additional window to bring their marking into compliance, rather than having to be retrofitted overnight on August 2.
That December 2 transition is the practical hinge for most existing deployments. A model or service that was live before August 2 is not instantly unlawful on August 2 if its marking is not yet in place; it has until December 2 to implement compliant marking. New systems launched on or after August 2 enjoy no such grace and must mark from day one.
This deferral is best understood alongside the broader recalibration of AI Act deadlines under the Digital Omnibus package, the Commission’s mid-2026 simplification effort that pushed several Annex III high-risk timelines outward and aligned a number of sub-obligations. The Article 50 marking transition to December 2 sits in that same family of targeted phase-ins. We covered the larger deadline restructuring in our analysis of the Digital Omnibus AI Act deadline deferral. One caution: elements of the Omnibus remained at the provisional-agreement stage as of mid-June 2026, so teams should track formal enactment rather than treat every reported extension as settled law.
Enforcement carries teeth. Breaches of the Article 50 transparency obligations are subject to administrative fines of up to 15 million euros or 3% of total worldwide annual turnover, whichever is higher.
Implementation checklist for compliance teams
The window between publication and the binding deadline is measured in weeks. A focused program should cover the following:
- Inventory every generative AI system you provide or deploy in the EU. Separate the two roles - you may be a provider for some systems and a deployer for others, with different duties attaching to each.
- Classify each system against Article 50. Does it generate synthetic media (50(2) marking)? Does it power a chatbot or interactive assistant (50(1) disclosure)? Do you publish its deepfake output or public-interest text (50(4) labelling)?
- Decide your marking architecture for provider systems. Plan for signed, tamper-evident metadata (C2PA-style Content Credentials) plus an imperceptible watermark for durability. Evaluate fingerprinting/registry only where the use case justifies the operational cost.
- Stand up free public detection. Choose your route - open specification, downloadable tool, or cloud API - and align toward an interoperable industry standard rather than a proprietary silo.
- Update terms of service to prohibit intentional removal or stripping of markings, and ensure your pipelines preserve, rather than discard, existing provenance metadata.
- Design visible labels for deployer use cases. Adopt the Commission’s standardized EU icons, place labels so they are clear and distinguishable at first exposure, and define how you surface them across image, video, audio and text. Build disclaimers into your publishing workflow, not as an afterthought.
- Document your editorial-review process for AI-assisted public-interest text, so you can demonstrate the substantive human review that relieves the labelling duty - and recognize where that review is too thin to qualify.
- Confirm chatbot disclosure is surfaced in every customer-facing conversational product at first interaction.
- Map the December 2, 2026 transition across your inventory. Tag which systems pre-date August 2 (and may use the grace period) versus which launch after (and must comply immediately).
- Decide whether to sign the Code, and if so, route the signatory form through someone authorized to bind the organization. Capture your reasoning either way for the compliance file.
- Track vendor obligations. If you deploy third-party generative AI, confirm by contract that the provider marks output in a machine-readable way - because your deployer-side labelling obligation depends on a provider-side marking you do not control.
Conclusion
The Code of Practice on Transparency of AI-Generated Content does not change what the law requires; Article 50 was always going to bind on August 2, 2026. What the Code changes is the answerability of the compliance question. For two years “mark it in a machine-readable format” was an instruction without an implementation. Now there is a government-endorsed, two-mechanism answer - signed metadata and imperceptible watermarking, with optional fingerprinting - mapped cleanly onto the split between provider marking and deployer disclosure, and backed by free public detection and a standardized set of EU labelling icons.
For compliance teams the strategic calculus is straightforward. The Code is voluntary, but the obligation it operationalizes is not, and the Code is the most authoritative evidence of good-faith compliance available before harmonized standards land. The transitional runway to December 2, 2026 buys breathing room for systems already in the field, but it is breathing room, not a reprieve. The organizations that come out ahead will be the ones that treat the next several weeks as a build sprint - inventorying systems, wiring in marking, designing labels, and documenting editorial review - rather than waiting for a clarity that, with this Code, has now arrived.
This article is provided for informational purposes only and does not constitute legal advice.



