The Code of Practice is a voluntary framework that helps organizations demonstrate compliance with Article 50 of the EU AI Act, which sets transparency obligations for AI‑generated and manipulated content

Art 50 of the EU AI ACT –  Transparency obligations for providers and deployers of certain AI systems.

.

The European Union’s Second Draft Code of Practice on Transparency of AI‑Generated Content sits at a critical intersection: it translates legal obligations under the AI Act into concrete technical and operational expectations for those who design, build, and deploy generative AI systems.

Read narrowly, the Code is about labelling and marking. Read properly, it is about systemic trust: how law, engineering, and governance must work together to ensure that synthetic content remains identifiable, verifiable, and accountable at scale. 

This post examines the Code through a dual lens:

• as a legal advisor, concerned with legal certainty, proportionality, and enforceability; and
• as an AI engineer, concerned with feasibility, robustness, interoperability, and lifecycle realities.

From a legal perspective, Article 50 of the AI Act responds to a clear market failure: individuals can no longer reliably distinguish AI‑generated content from human‑created content, with consequences for democracy, consumer protection, and fundamental rights.

From a technical perspective, the problem is equally clear: there is no single reliable signal that can identify AI‑generated content across modalities, transformations, platforms, and adversarial contexts.

The Code acknowledges both realities. It does not pretend that compliance can be achieved through a single watermark, label, or detector. Instead, it mandates a layered, system‑level approach grounded in today’s state of the art, while remaining adaptable to future advances. 

1.1 Multi‑Layered Marking Is Not Optional — It Is a Design Principle

Legally, providers of generative AI systems are responsible for ensuring that outputs are marked in a machine‑readable way and are detectable as AI‑generated or manipulated.

Technically, the Code is explicit: no single marking technique is sufficient today.

As a result, the Code requires a multi‑layered marking strategy, typically combining:

• • Cryptographically signed metadata (where formats allow it)
  • Imperceptible watermarks embedded in content
  • Optional fingerprinting or logging mechanisms as supplementary safeguards

For engineers, this is a strong signal: marking must be treated as core infrastructure, not an add‑on. It belongs in model pipelines, inference layers, export workflows, and downstream integrations—not in post‑hoc patches.

1.2 Detection Is Part of the Legal Obligation

From a legal standpoint, marking without detection is meaningless. The AI Act requires that information be accessible to natural persons.

Accordingly, providers must:

• • Offer free detection mechanisms (APIs or tools)
  • Ensure results are clear, understandable, and accessible, including for persons with disabilities
  • Support use by regulators, deployers, researchers, media, and civil society

From an engineering view, this implies that detection tools must be:

• • Maintained throughout the system lifecycle
  • Privacy‑preserving by design
  • Robust against content transformations and abuse

Detection is not merely a feature—it is part of the provider’s regulatory interface with society. 

The Code operationalises Article 50 through four technical‑legal quality requirements:

1. 1. Effectiveness — People can meaningfully distinguish AI content
   2. Reliability — Low false positives and negatives across use cases
   3. Robustness — Resistance to editing, compression, paraphrasing, and attacks
   4. Interoperability — Compatibility across providers, platforms, and tools

Legally, these function as compliance criteria.
Technically, they function as design constraints.

The Code explicitly recognises operational limits (e.g. real‑time video), but it also makes clear that such constraints cannot be used to avoid compliance. This is a classic proportionality test, translated into engineering terms.

If Section 1 is about machines talking to machines, Section 2 is about machines talking to people.

2.1 Clear Disclosure of Deepfakes and AI‑Generated Public‑Interest Text

Deployers must disclose when content is:

• • A deepfake (AI‑generated or manipulated audio, image, or video), or
  • AI‑generated or manipulated text published to inform the public on matters of public interest

As a legal practitioner, the key phrase is “clear and distinguishable at the latest at first exposure.”
As an engineer, this translates into UX, timing, placement, and modality‑specific constraints.

The Code provides detailed guidance for video, audio, images, text, and live content—recognising that disclosure is not one‑size‑fits‑all. 

The proposed EU‑wide “AI” icon is legally significant and technically pragmatic.

• • Legally, it supports the need for an harmonisation across Member States
  • Technically, it allows for evolution, second‑layer information, and accessibility adaptations

Importantly, the Code avoids over‑specification. It defines minimum design and placement principles, not pixel‑perfect rules—leaving room for innovation while ensuring recognisability.

2.3 Artistic and Editorial Exceptions: Law Meets Human Judgment

The Code carefully preserves:

• • Artistic, creative, satirical, and fictional expression, and
  • Editorial freedom where human review and responsibility exist

From a legal perspective, this reflects Charter‑level rights.
From a systems perspective, it introduces process requirements, not technical ones: documentation, review workflows, and accountability.

This is a reminder that not all compliance problems are solved in code—some are solved in governance.

Perhaps the most important insight of the Code is structural: Transparency is not the responsibility of a single actor.

Providers, model developers, deployers, platforms, and authorities are expected to cooperate across the value chain, using shared standards, shared infrastructure, and shared detection mechanisms where possible.

For legal practitioners, this raises evidently the questions of liability allocation and reliance.
For engineers, it raises questions of interoperability, APIs, and standard adoption.

The Code does not resolve all of these tensions—but it creates a common technical‑legal language in which they can be addressed. 

From both a legal and engineering standpoint, the Draft Code of Practice is notable for what it does not do:

• It does not mandate immature or prototype technologies
• It does not assume perfect detection
• It does not ignore operational constraints

Instead, it sets directional obligations, measurable quality criteria, and governance expectations that are realistic today and extensible tomorrow.

For organisations building or deploying generative AI in the EU, the message is clear:

Transparency must be engineered, governed, and communicated—not merely declared.