The Final EU AI Transparency Code Raises the Bar for Generative Audio

The final Code of Practice turns AI-content transparency from a broad obligation into a technical system: marking, detection, metadata, testing, interoperability, and evidence. For generative audio companies, adding a watermark is only the beginning.

This article provides a technical interpretation of the Code of Practice and is not legal advice.

The EU AI Act has already established the direction of travel: providers of AI systems that generate or manipulate synthetic audio, images, video, or text must ensure that their outputs are marked in a machine-readable format and detectable as artificially generated or manipulated.

The final Code of Practice on Transparency of AI-Generated Content now provides a much clearer picture of what implementing those requirements may involve.

The main takeaway is simple:

AI transparency is not a label added at the end of the generation pipeline. It is infrastructure that must connect generation, provenance, detection, testing, and governance.

For generative audio providers, this raises both a technical challenge and an opportunity. The challenge is that audio does not remain inside a clean model environment. It is compressed, streamed, filtered, enhanced, re-recorded, and transmitted through networks. The opportunity is that companies able to make provenance survive those conditions can become an essential layer in the AI voice ecosystem.

The Code makes Article 50 operational

Article 50 of the AI Act creates the legal obligation. The Code of Practice provides a practical framework that providers may use to demonstrate how they are addressing it.

The Code does not itself guarantee compliance, and providers remain responsible for their own legal assessment. But it is likely to become an important reference point for companies, customers, auditors, and market-surveillance authorities.

For generative audio systems, the central requirement is that outputs must be:

• marked in a machine-readable format;
• detectable as artificially generated or manipulated;
• supported by technical solutions that are effective, reliable, robust, and interoperable, as far as technically feasible.

The Code also makes an important distinction between mandatory commitments and optional recommendations. Measures described using “will” are treated as required for a signatory following the Code, while measures described as “encouraged” or “may” provide recommendations or flexibility.

This means that providers should not approach the Code as a request to simply “add a watermark.” They need to think about the complete lifecycle of the mark: how it is inserted, how it is detected, who can verify it, how results are presented, and how the system continues to work as models and standards evolve.

The expected system has more than one layer

For most audio, image, and video content that can be distributed online, the Code concludes that no single marking technique currently provides enough effectiveness, reliability, robustness, and interoperability on its own.

The expected architecture is therefore multi-layered.

Layer 1: Digitally signed metadata

Where an audio format supports metadata, the Code expects providers to record whether the content was AI-generated or manipulated.

This information should be digitally signed and, where time information is available, time-stamped in a tamper-evident manner. The Code also encourages richer provenance information, such as the AI system, provider, model version, and generation timestamp, provided that privacy-sensitive or commercially sensitive information is handled appropriately.

Layer 2: Imperceptible watermarking

The Code also expects an imperceptible watermark to be embedded within the content in a way that makes it difficult to separate from the media.

The watermark is intended to complement metadata—not replace it.

Metadata can provide rich and interoperable provenance information, but it can be removed when content is exported, transcoded, uploaded to a platform, or passed through a system that does not preserve it. A watermark is carried by the media signal itself and can continue to provide evidence after the metadata layer disappears.

Metadata explains where content came from. A watermark helps that proof survive when metadata disappears.

The Code allows companies to use a third-party provider for marking and detection. However, using an external technology vendor does not transfer the AI provider’s overall responsibility for ensuring that its system’s outputs are appropriately marked and detectable.

For audio, robustness is the real test

Embedding a signal into clean, studio-quality audio is not the hardest problem.

The real test begins after the audio leaves the model.

Generated speech may be:

• compressed and recompressed;
• converted between codecs;
• resampled;
• filtered;
• denoised or enhanced;
• pitch-shifted or time-stretched;
• played through a speaker and recorded again;
• streamed through VoIP;
• transmitted through a cellular or narrowband telephone network;
• deliberately modified in an attempt to remove or copy the mark.

The Code treats reliability and robustness as related but different requirements.

Reliability concerns how accurately the marking and detection system works under nominal conditions, across different speakers, languages, audio lengths, and content types. Providers should be able to characterize their false-positive and false-negative rates rather than relying only on a few successful demonstrations.

Robustness concerns what happens after the content is transformed. The Code explicitly calls for testing against normal processing operations, desynchronization, the analogue hole, localized changes, and adversarial copying, removal, regeneration, or modification of markings.

That does not mean a watermark must survive every theoretically possible transformation. All signal-based systems have physical limits. A transformation severe enough to destroy the information-bearing parts of an audio signal can also destroy the watermark.

The Code recognizes this reality through the concepts of technical feasibility, the specific characteristics of the content, implementation cost, and the generally acknowledged state of the art.

But providers still need evidence. It will not be enough to say that a watermark is “robust.” They will need to define:

• the conditions under which it was tested;
• the length of audio required for a reliable decision;
• expected false-positive and false-negative rates;
• known failure conditions;
• how performance changes after realistic attacks and distribution paths.

Detection does not need to be perfect in every instant

One especially important point for live audio is that reliability should be measured over an appropriate detection window.

Watermark detection is probabilistic and content-dependent. Silence, very quiet speech, highly distorted audio, or an extremely short sample may contain insufficient information for a confident decision.

The Code itself recognizes that error rates can vary with the length, size, diversity, and semantics of the content. It does not require a perfect result from every individual frame of audio.

A responsible system should therefore state its detection conditions clearly:

Detection is aggregated over a minimum duration and reported with a defined confidence and error rate.

That is more technically honest and more useful than promising instant, perfect detection from every 20, 80, or 100 milliseconds of audio. DeepMark’s internal research similarly treats temporal aggregation as the appropriate way to recover reliable decisions after difficult transformations.

The hard part is not adding a mark. It is making the mark useful after the real world touches the audio.

Detection becomes a product, not an internal research tool

One of the Code’s most significant implications is that detection cannot remain a private script used only by the model provider’s engineering team.

Providers are expected to make a detection solution available to relevant parties, which may include:

• customers and deployers;
• third-party integrators;
• end-users exposed to generated content;
• regulators and market-surveillance authorities;
• independent researchers;
• media and fact-checking organizations;
• civil-society groups.

The detection mechanism may be offered through a public specification, downloadable software, a library, or a cloud API.

Where the general public may be exposed to the content, the Code expects the detection solution to be available to the public. Where content remains inside a controlled professional environment with safeguards against wider distribution, access may be more restricted.

The result must also be understandable. A detector should not merely return a raw probability, bit sequence, or internal model score. The Code expects the result to clearly indicate whether the finding came from metadata, watermarking, forensic detection, or another technique. Where more information is available, the result may also include provenance details or the part of the content that was identified as generated or manipulated.

A practical result might say:

• AI-generated marking detected
• No marking detected
• Inconclusive
• Method: imperceptible audio watermark
• Provider or system: available to authorized users
• Detection timestamp and signed report available

The Code also expects users to be able to request a digitally signed detection result containing at least a hash of the submitted content, an identifier for the detection solution, and a timestamp.

Public verification does not mean publishing the detector

A public detection requirement does not necessarily mean that providers must disclose:

• model weights;
• raw decoded payloads;
• decision thresholds;
• attack-sensitive implementation details;
• private certificates;
• internal forensic tools.

The Code explicitly recognizes that access may need cybersecurity controls where unrestricted use could compromise the security of the underlying marking and detection techniques.

A sensible architecture is therefore tiered:

• Public users receive a simple marked, not detected, or inconclusive result.
• Enterprise customers receive richer provider, model, agent, or certificate information where authorized.
• Regulators and approved experts receive signed evidence and forensic detail under controlled access.
• Internal teams retain raw diagnostics and security-sensitive information.

This approach gives users meaningful verification without unnecessarily exposing the mechanism to attackers.

Privacy matters when people submit audio for detection

Audio often contains personal, confidential, or regulated information. A detection service may receive customer-support calls, financial conversations, medical discussions, voice biometrics, or other sensitive material.

The Code therefore places strong requirements on detection services that require uploaded content.

Providers should:

• treat submitted content as privacy-sensitive;
• protect it in transit and at rest;
• process it only for detection;
• minimize the amount of personal data collected;
• retain it only for the time needed to run detection;
• immediately delete the verbatim content afterward under a zero-retention policy;
• apply safeguards against misuse and unauthorized access.

Where technically feasible, the Code encourages providers to process a non-semantic derivative rather than requiring the full original content.

For many enterprise audio applications, local or customer-controlled deployment may therefore be preferable. The detector can operate inside the customer’s environment without the underlying calls leaving its infrastructure.

Live voice needs a different architecture

The Code was written to cover audio broadly, but live voice introduces a specific engineering problem.

For an exported audio file, the two-layer model is relatively straightforward:

1. attach digitally signed metadata to the file;
2. embed an imperceptible watermark into the audio samples.

Both layers can initially travel together.

A live phone call is different.

Audio may move through a sequence of streaming systems, RTP or WebRTC infrastructure, VoIP providers, contact-center platforms, telecommunications networks, and cellular devices. There may be no persistent file container capable of carrying signed metadata through the complete path.

In that environment, a practical architecture is:

1. create a signed certificate or provenance record outside the audio channel;
2. assign it a compact identifier or cryptographic reference;
3. embed that reference continuously into the generated speech;
4. transmit the audio through the call;
5. detect and resolve the reference on the receiving side.

In a file, metadata and watermarking can travel together. In a live call, the watermark becomes the durable pointer to the provenance record.

The rich metadata stays in a protected registry. The watermark does not need to carry a company name, phone number, customer identity, or full certificate. It can carry an opaque reference that is useful only when resolved through an authorized verification service.

This keeps the in-audio payload small, improves robustness, and reduces privacy risk.

This architecture is DeepMark’s technical interpretation of how the Code’s multi-layer objective can be applied to live voice. It should not be presented as the only legally acceptable implementation, because the Code does not prescribe a complete real-time telephony architecture.

Interoperability may be harder than embedding

Another important requirement is interoperability.

The long-term objective is that users should not need to understand every provider’s proprietary watermark or run hundreds of unrelated detectors to identify marked content.

The Code proposes a staged approach. Initially, providers should use established standards for metadata and publish information explaining how their other marking mechanisms can be accessed.

For watermark detection, signatories are expected to implement an interoperability mechanism by 2 February 2027. Possible approaches include:

• a common industry API that routes detection requests;
• a public signpost indicating which detector should be used;
• a shared detector operated by a provider consortium;
• another solution offering comparable interoperability.

The mechanism must also avoid damaging other embedded watermarks and include safeguards against misuse.

This creates a difficult lifecycle problem.

Watermark detectors are generally tied to the embedding technique that produced the mark. When a provider releases a new generation of an embedding model, the old detector may no longer be sufficient.

The Code requires a detection mechanism for every implemented marking technique. It also says that when a detection solution is retired, its replacement should provide the same or better capability and remain backward-compatible with previously marked content. Legacy content cannot simply become unverifiable because a provider updated its model.

Without careful design, providers could end up operating a growing fleet of detectors for every model generation.

DeepMark is researching detector architectures that can preserve compatibility across multiple generations of embedding models. The goal is to allow the latest detector to continue recognizing content marked by earlier embedders, reducing operational complexity and supporting long-term verification.

This remains an active research area and should not be described as fully solved until it has been measured across production model generations.

The four requirements define the real product bar

The Code organizes the technical quality bar around four concepts.

Effectiveness

Can relevant users access the verification system and understand what the result means?

This includes the interface and communication around the detector, not only the underlying model accuracy.

Reliability

How often does the system produce the right answer in nominal conditions?

Providers should measure false positives, false negatives, and performance across diverse content, not only showcase successful examples.

Robustness

Does the marking survive realistic processing, distribution, and adversarial behavior?

For audio, this includes codecs, filtering, enhancement, resampling, time and pitch changes, network transmission, playback and re-recording, and malicious removal attempts.

Interoperability

Can other actors discover, access, and interpret the correct detection mechanism without building a bespoke integration for every provider?

These properties interact.

Increasing watermark payload capacity may reduce the amount of energy available per bit. Increasing robustness can affect perceptual quality. Reducing latency may reduce available context. Supporting additional attacks may require larger models or longer detection windows.

No approach maximizes payload, robustness, quality, detection accuracy, and latency simultaneously without trade-offs.

The product challenge is not to pretend those trade-offs do not exist. It is to choose and document them according to the deployment environment.

For a telephone call, robustness to narrowband codecs may be more important than a large payload. For a high-quality exported audio file, perceptual quality and metadata interoperability may take priority. For a forensic workflow, detection speed may matter less than confidence.

Where DeepMark fits

DeepMark provides the embedded marking and detection layer for generative audio systems.

Our technology is designed to insert an imperceptible, machine-readable signal directly into generated speech and detect it after the audio has passed through real distribution channels.

Depending on the use case, the signal can:

• indicate that the audio was generated or marked by an authorized system;
• carry a compact multi-bit identity;
• identify or reference a provider, model, AI agent, or session;
• resolve to an external signed certificate or provenance record.

DeepMark’s role can include:

Embedding

Integrating zero-bit or multi-bit marking into the generation or post-processing pipeline, including real-time and streaming workflows.

Detection

Providing the mechanism that determines whether a valid DeepMark mark is present and, where applicable, recovers or resolves its payload.

Robustness evaluation

Testing against codecs, compression, filtering, transmission, network conditions, re-recording, and other realistic transformations.

Deployment

Supporting SDK, API, customer-cloud, VPC, on-premises, or other infrastructure models depending on security and operational needs.

Provenance integration

Connecting an in-audio reference to signed metadata, certificates, registries, or C2PA-style provenance records.

Compliance evidence

Helping providers document detection performance, error rates, robustness tests, known limitations, model versions, and verification workflows.

DeepMark does not replace a provider’s legal analysis, metadata strategy, user-facing disclosure obligations, internal governance, or complete compliance process.

It provides the specialized technical infrastructure needed to make generated audio machine-readably marked, and verifiable.

Our own internal mapping against the final Code distinguishes between capabilities already available in the watermarking and detection layer and surrounding product work still required across the industry, including public detection access, signed reports, zero-retention controls, metadata infrastructure, and interoperability.

What should generative-audio providers do now?

Companies should not wait for the deadline to begin defining their architecture.

A practical starting point is to:

1. Map your role.
   Determine whether you are an AI-system provider, model provider, deployer, or more than one of these.
2. Map every output path.
   Include downloadable files, streaming APIs, browser audio, contact-center systems, VoIP, and telephone networks.
3. Define the marking architecture for each path.
   File-based audio and live calls may require different implementations.
4. Choose the metadata and provenance layer.
   Determine what will be recorded, signed, time-stamped, and exposed to different audiences.
5. Integrate watermarking close to generation.
   The mark should be applied before the content leaves the controlled generation environment.
6. Define the detection audiences.
   Decide what the public, customers, integrators, regulators, and internal teams should be able to see.
7. Test the real distribution path.
   Clean WAV files are not enough if the output will ultimately pass through VoIP, cellular networks, or social platforms.
8. Measure and publish meaningful performance characteristics.
   Include the required detection duration, false-positive rate, false-negative rate, and known failure conditions.
9. Plan for model updates and legacy content.
   A new watermarking model cannot make previously generated content unverifiable.
10. Document limitations honestly.
    Avoid claims such as “permanent,” “unremovable,” “100% accurate,” or “detected in every frame.”

The watermark is where the difficult work begins

The final Code of Practice makes one point especially clear: transparency for AI-generated content is becoming an engineering discipline of its own.

It combines:

• machine-readable marking;
• signed provenance;
• accessible detection;
• privacy and security;
• measurable reliability;
• real-world robustness;
• model-lifecycle support;
• interoperability;
• continuous testing and documentation.

For audio, watermarking is the layer that stays with the signal after other information disappears.

But a watermark is only useful when it remains detectable after the audio is compressed, streamed, transmitted, edited, or attacked—and when the resulting evidence can be clearly understood and trusted.

Marking generated audio is the starting point. Making that mark survive the real world is what turns it into infrastructure.