EU AI Act Article 50(2): Synthetic Audio Marking from December 2026

In 31 days — 2 August 2026 — Article 50(1) of the EU AI Act requires every enterprise voice AI deployment serving EU consumers to disclose, at the start of each interaction, that the caller is speaking with an AI system. The compliance community has spent the past several months preparing for that deadline. What very few teams have prepared for is what comes next.

Article 50(2) requires that synthetic audio content — the AI-generated speech your voice agent produces on every call — be marked in a machine-readable way so that automated detection tools can identify it as artificially generated. This obligation applies from 2 December 2026. For existing AI systems (those deployed before 2 August 2026), the European Commission's omnibus simplification package pushed the marking obligation to the December date. For new systems deployed from August 2026 onwards, the obligation applies from go-live.

With 153 days to the December enforcement date, the majority of enterprise voice AI programmes have not yet audited their synthetic audio outputs, engaged their TTS providers on watermarking compliance, or built the evidence pack their legal team will need if an EU supervisory authority comes asking. That gap is what this guide closes. It covers what Article 50(2) actually requires, which voice AI outputs are in scope, what "machine-readable marking" means technically, who is responsible when your TTS provider and your deployment team are different entities — and the 153-day countdown plan to get there.

This guide is published by the team behind Dilr Voice — enterprise voice AI operating across 40+ countries. For a structured compliance review of your existing voice programme, see AI Operating Model consulting or speak to DATS, our five-stage enterprise AI methodology.

Two Deadlines, Two Distinct Obligations

The most common compliance mistake made by enterprise teams right now is treating Article 50 as a single obligation with a single date. It is neither. Article 50 of the EU AI Act contains structurally distinct requirements that apply to different technical capabilities and carry different enforcement timelines.

Article 50(1) — the 2 August 2026 obligation — requires deployers of AI systems that interact with natural persons in real-time to ensure those persons are informed they are interacting with an AI system, unless this is obvious from context or the person has explicitly consented to an AI interaction. For voice AI, this translates to an audible disclosure at the start of each call. Dilr.ai has published detailed operational guidance on this obligation in our Article 50 enforcement countdown guide, our disclosure compliance guide, and our deployer checklist based on the EC draft guidelines published in May 2026. The August deadline is well-understood and, for most programmes, in implementation.

Article 50(2) — the 2 December 2026 obligation — requires deployers of AI systems that generate synthetic audio content to mark that content as artificially generated using machine-readable methods that enable detection tools to identify it. This is a substantively different technical obligation: instead of telling a human (via a disclosure statement), you are marking audio data in a way that machines can verify. The obligation extends beyond real-time voice interactions to all AI-generated audio your systems produce.

The omnibus package agreed by the Council of the EU and European Parliament in May 2026 — which our team analysed in detail in EU AI Act omnibus: what is delayed, what is not — extended specific obligations for existing AI systems. The December date for Article 50(2) reflects this extension for existing deployments. It is emphatically not a blanket delay of all Article 50 obligations. Article 50(1) disclosure requirements still enforce in August. The December date covers the synthetic content marking obligations specifically, and only for systems already deployed before August 2026. If your team read the omnibus headlines as "AI Act compliance has been postponed" and paused preparation, that reading is incorrect for the August obligations and creates a compressed timeline for the December ones.

For completeness, Article 50(3) addresses AI-generated text in journalistic and public-interest contexts — it is not directly relevant to enterprise voice AI programmes, though it matters for broader AI content strategy. Article 50(4) provides limited exceptions where marking would be technically infeasible or would impair the legitimate purpose of the content — a high bar that most enterprise voice AI deployments will not meet.

Who Is in Scope for Article 50(2)

Article 50(2) applies to AI systems that generate synthetic audio content — that is, audio produced by artificial intelligence that depicts or simulates a natural human voice. For enterprise voice AI programmes, scope is broad and largely unavoidable.

Clearly in scope: The real-time TTS voice your agent generates during calls is synthetic audio. Every time your voice agent speaks — whether reading a greeting, asking a qualification question, confirming a booking, or delivering a payment reminder — the audio output is synthetic. Pre-recorded IVR prompts generated using AI text-to-speech are also synthetic audio, as are AI-generated voicemail messages, outbound AI voice messages delivered to recipients asynchronously, and any audio files your programme generates using AI synthesis and delivers to consumers. The voice cloning and deepfake risk guide covers related obligations around AI-generated voice impersonation — these obligations interact with Article 50(2) marking requirements in important ways when synthetic voices resemble real individuals.

Borderline cases: Human voice recordings that have been lightly processed for noise reduction or audio quality improvement are generally not considered synthetic audio under Article 50(2), provided the underlying content remains human-generated. Similarly, audio where the human voice has been digitally compressed or processed for telephony transmission does not typically trigger the marking obligation. The line sits at whether AI has generated or substantially reconstructed the content of the audio — not merely processed a human original.

The deployer responsibility: The obligation sits with the deployer — the enterprise that integrates the voice AI capability and operates it in customer-facing applications. Even if your TTS provider (ElevenLabs, PlayHT, Microsoft Azure TTS, Google Cloud TTS, or another) is the entity technically generating the audio, you are the party deploying that capability in a consumer context and therefore bear primary responsibility for ensuring marking compliance. Your TTS provider's role is to provide a marking-capable pipeline; your role is to ensure that pipeline is activated and evidenced.

The public-availability threshold: The marking obligation applies to synthetic audio "made available to the public" or to specific natural persons. Audio generated and used purely for internal testing — never transmitted to a consumer — sits outside the scope of 50(2). However, any audio delivered to a caller (including outbound AI voice messages, even to a single recipient) crosses the threshold. Programme teams should not interpret "the public" narrowly here. One-to-one outbound AI voice messages to an individual consumer are in scope.

What Machine-Readable Marking Actually Means

The EU AI Act does not mandate a specific technical standard for synthetic audio marking. Article 50(2) requires marking "in a machine-readable format" and emphasises that it should be detectable by "technical means that are reasonably available." The Commission's draft guidelines published in May 2026 — analysed in our EC Article 50 deployer checklist — confirm that the obligation is to take reasonable technical steps proportionate to current capability, with recognition that technical standards for audio are still maturing. What the guidelines do not permit is doing nothing on the grounds that the standard is unresolved.

In practice, two technical approaches are emerging as compliant pathways for enterprise voice AI.

Digital audio watermarking embeds imperceptible signals within the audio waveform itself. These signals survive typical telephony transcoding (Opus, G.711) and allow automated detection tools to verify that a given audio sample was synthetically generated. The advantage of watermarking for voice AI is that it works for streaming audio — the marking is applied by the TTS provider at generation time, flows through the audio pipeline with the content, and does not require a separate file-level metadata layer. Meta's AudioSeal, developed by FAIR, is an open-source audio watermarking system designed for exactly this purpose. Several major TTS providers have implemented proprietary equivalents or are actively deploying AudioSeal-compatible approaches. Watermarking is currently the most practical path for real-time voice AI call compliance.

C2PA (Coalition for Content Provenance and Authenticity) is an open industry standard for content provenance, developed by a coalition including Adobe, Microsoft, Intel, and the BBC. C2PA version 2.0 extended the specification to include audio content, allowing cryptographic Content Credentials to be attached to audio files. A C2PA manifest records the origin of content, the AI systems involved in its creation, and asserts that it is synthetic. This approach is well-suited for file-based synthetic audio — for example, pre-recorded AI voice messages or AI-generated IVR audio stored as files before delivery. C2PA is less naturally suited to real-time streaming audio, though the specification does allow credential manifests to reference audio content via a content hash, enabling post-generation attestation.

For most enterprise voice AI programmes, the practical answer is a combination: watermarking from the TTS provider covers real-time call audio; C2PA signing covers any pre-generated synthetic audio files (IVR prompts, AI voice messages stored as files). The voice AI auditability guide explores how marking integrates with the broader audit trail that regulators increasingly expect from enterprise deployments in regulated sectors.

One practical challenge deserves attention: audio processing pipeline integrity. Synthetic audio generated by a TTS provider and watermarked at source can have its watermark degraded or stripped by aggressive post-processing — audio compression, re-encoding, transcoding through media servers, or concatenation with other audio segments. The compliance obligation extends to ensuring the marking survives the full pipeline from generation to delivery. Before declaring compliance, test that any marking applied at the TTS layer is still detectable after the audio has passed through every processing stage in your call flow — including your telephony carrier's transcoding, your recording platform's compression, and any audio processing applied to call recordings.

The voice AI data retention guide is directly relevant here: if your programme retains call recordings, those recordings are synthetic audio (in whole or in part, for AI-handled portions) and the marking obligation extends to the retained files. A recording that was marked at generation time but had its watermark stripped by your recording platform's compression creates a retained copy of synthetic audio that is not detectably marked — a compliance gap.

Your TTS Provider vs Your Responsibility

The division of responsibility between TTS providers and enterprise deployers is one of the most commercially sensitive aspects of Article 50(2) compliance, and one where the legal analysis is still developing.

The AI Act places the primary Article 50(2) obligation on deployers — the entities that deploy AI systems in customer-facing applications. Providers of AI models (including TTS providers) have separate obligations under the AI Act (primarily under the GPAI provisions for general-purpose AI models), but Article 50(2) transparency obligations sit with the deployer. This means that even if your TTS provider does not implement watermarking, you as the deployer cannot escape the obligation by pointing to your vendor. You must either ensure your vendor is compliant or take direct steps to apply marking yourself.

This does not mean TTS providers bear no responsibility — it means their responsibility is to you as a customer, not directly to regulators under Article 50(2). Your MSA with your TTS provider should include explicit representations about Article 50(2) compliance if you want commercial protection. The voice biometric data security guide covers the broader contractual framework for AI-generated audio data, including the special category considerations that interact with marking obligations when audio is used for voice biometric analysis.

Questions to send to your TTS provider now — 153 days out:

1. Watermarking implementation: Do you implement digital audio watermarking (AudioSeal, proprietary equivalent) or C2PA audio credentials on synthetic audio you generate? If so, as of what date, and for which API endpoints?
2. Pipeline durability: Has your watermarking been tested to survive Opus at 32 kbps, G.711, and common telephony transcoding? What independent validation exists?
3. Detection tooling: Can you provide a reference detection tool or API endpoint that allows us to verify that a given audio sample carries your marking?
4. Streaming audio specifically: For real-time TTS used in live calls, does watermarking apply at generation time (before streaming to the caller), or is it only available for file-based audio generation?
5. Contractual representation: Are you willing to add a contractual warranty that your audio outputs comply with EU AI Act Article 50(2) from 2 December 2026 for EU-jurisdictional deployments?
6. Documentation for evidence pack: Can you provide a technical whitepaper or compliance statement describing your Article 50(2) approach, suitable for inclusion in our regulatory evidence pack?

If your TTS provider does not respond substantively within four weeks, treat the non-response as a compliance risk. You either need to escalate to a senior commercial contact, evaluate alternative providers who can confirm compliance, or commission your own post-generation marking implementation — a more complex path, but a viable one for file-based audio outputs.

The Compliance Architecture You Need to Build

Article 50(2) compliance for a voice AI programme is not a single configuration change — it is a multi-layer architecture decision spanning your TTS layer, your call processing pipeline, your recording infrastructure, and your evidence documentation. Enterprises that treat it as a provider-level switch will find gaps; those that treat it as a programme-level compliance design will close them.

The compliance architecture starts with a synthetic audio inventory — a structured list of every AI-generated audio output your programme produces, the TTS provider responsible for each, the pipeline through which the audio passes, and whether it is delivered in real-time (streaming) or as a pre-generated file. Most enterprise programmes have more synthetic audio outputs than their compliance team initially assumes: in addition to the live agent voice, they typically have AI-generated IVR hold messages, AI voice outbound notifications (appointment reminders, delivery updates, payment chasers), and AI-generated voicemail drop messages. Each of these must appear in the inventory with its Article 50(2) compliance status confirmed.

The inventory then drives gap analysis: for each output, is marking implemented and verified? Where gaps exist, they require either a provider-level resolution (the TTS provider activates watermarking for that API endpoint) or a deployer-level remediation (your team applies C2PA signing to file-based outputs before delivery, or implements post-generation watermarking using an open-source tool like AudioSeal).

Once marking is implemented, pipeline integrity testing validates that the marking survives end-to-end. This is not optional. The combination of your telephony carrier's codec selection, your call recording platform's compression, and any IVR system's audio processing can strip a watermark that was correctly applied at the TTS layer. The CRM and telephony integration architecture guide covers how to design observable, testable audio pipelines — the same architectural discipline applies to marking integrity testing.

For regulated-industry deployers who need to build voice AI architecture that satisfies multiple regulators simultaneously, Article 50(2) marking should be treated as a design constraint from the outset, not a post-deployment retrofit. See also our general EU AI Act voice AI obligations guide for the broader compliance framework that Article 50(2) sits within, and our AI Operating Model consulting for a structured methodology to address it.

The 153-Day Countdown Plan

153 days is enough time to achieve Article 50(2) compliance for most enterprise voice AI programmes — provided the work starts now. The failure mode is treating December as distant until October, then discovering that provider engagement, DPIA updates, and legal review cannot be completed in six weeks. Here is the day-band plan.

The day-band that most teams will miss is days 31 to 60 — the provider response window. TTS providers are dealing with compliance queries from thousands of enterprise customers simultaneously. Four weeks is a realistic minimum response time; six weeks is common. If you submit your questionnaire in October, you will receive responses in November, leaving days rather than weeks for any remediation work. Starting the provider engagement now is the single highest-value action this guide recommends.

One further consideration for programmes that use multiple TTS providers across different deployment regions or use cases: the inventory and questionnaire process must be run for each provider independently. It is not safe to assume that a compliance confirmation from Provider A covers audio generated by Provider B, even if both use broadly similar TTS approaches. Each provider's watermarking implementation, API endpoints, and contractual position must be confirmed separately.

Want to map your programme's Article 50(2) exposure? Start with Dilr Voice (enterprise voice AI with EU compliance design built in), book an AI placement diagnostic to audit your current synthetic audio outputs, or read our approach to placing AI in regulated enterprise environments.

Written by the Dilr.ai engineering team — practitioners who ship enterprise AI in regulated markets. Follow us on LinkedIn for shipping notes and compliance updates, or subscribe via the RSS feed.