Voice cloning under the EU AI Act, a 2026 compliance brief

The EU AI Act came into force on 2 February 2025. Most of the act phases in over the following 24-36 months, but the obligations that touch voice cloning landed almost immediately. This post is a compliance brief for product and legal teams: what the EU AI Act actually requires of voice-cloning vendors and their customers, where the act intersects with the GCC's identity-misuse statutes, and what a defensible compliance posture looks like in 2026.

We are not a law firm; this isn't legal advice. This is a description of the rules as we read them, written by a vendor that has had to ship into the regulatory regime and document the controls. Use it as a starting point for a conversation with your own counsel, not as a substitute.

What the EU AI Act actually says about voice cloning

The act is risk-tiered. The four tiers are unacceptable-risk (banned outright), high-risk (heavy compliance obligations), limited-risk (transparency obligations), and minimal-risk (no specific obligations). Voice cloning sits primarily in the limited-risk and high-risk tiers depending on use case:

Voice cloning generally: limited-risk. The act categorises AI systems that "generate or manipulate image, audio, or video content constituting a deep fake" as a transparency-obligation tier. Article 50 of the act requires that any synthetic audio (including cloned voices) is labelled as artificially generated and that users interacting with such content are informed.
Voice cloning of public figures or for impersonation: high-risk to unacceptable-risk depending on context. Article 5 prohibits AI systems that "deploy subliminal, manipulative, or deceptive techniques" to materially distort behaviour. A cloned voice used to impersonate a public figure for fraud or manipulation falls in here.
Voice cloning in critical sectors (law enforcement, border control, education, employment): high-risk. The compliance overhead jumps significantly: conformity assessments, registration in the EU AI database, post-market monitoring.

Most commercial voice cloning (audiobook narration, voice agents for customer service, branded podcast hosts, dubbing) falls in the limited-risk tier. The transparency obligations are what apply to the majority of customers.

The Article 50 transparency obligations, unpacked

The act requires that synthetic audio is labelled as artificially generated in a clear and distinguishable manner at the latest at the time of the first interaction or exposure. The relevant operational interpretations:

Voice agents must disclose that the voice is AI-generated, not human, before substantive interaction begins. The convention emerging in practice is a 5-15 second introductory line ("Hi, you've reached the AI assistant for [brand]. I'll do my best to help, and you can ask for a human at any time."). The disclosure has to be in the language of the conversation; for Arabic agents, the disclosure is in Arabic.
Audiobooks narrated by cloned or catalogue AI voices must carry a disclosure in the publisher's metadata and a spoken introductory disclosure at the start of the audiobook. Storytel, Audible, and the regional Arabic distributors are progressively requiring this in their submission requirements.
Dubbed content (film, TV, video) where the dub is AI-generated has a softer obligation: the credits or metadata must indicate AI dubbing was used. There's no requirement for in-content disclosure in real-time.
Internal voice-cloning use (corporate L&D, internal podcast for employees) doesn't have the public-facing disclosure obligation, but the consent obligation (separate from Article 50) still applies to the source narrator.

The act's enforcement allows fines up to 3% of global annual turnover for transparency violations. Larger penalties (up to 7%) apply to violations of the prohibited-use categories in Article 5.

The EU AI Act doesn't directly govern the consent obligation for cloning a person's voice; that's covered by the GDPR (the cloned voice is biometric data, which is special-category personal data under Article 9) and by the relevant national identity-protection statutes.

The operational rules:

Voice samples used for cloning are biometric data. They require explicit consent under GDPR Article 9, plus a lawful basis under Article 6.
Consent must be informed: the source narrator has to know what their voice will be used for, who will use it, and for how long.
Consent must be revocable: the source narrator can withdraw consent at any time, and the controller (the vendor or the customer, depending on the architecture) must stop using the cloned voice and delete the source samples.
Cross-border transfers are restricted: if the voice samples are processed outside the EU/EEA, you need a transfer mechanism (Standard Contractual Clauses, an adequacy decision, or one of the GDPR Article 49 derogations).

The combined effect: a voice-cloning workflow has to capture explicit, informed, revocable consent, store it as a non-repudiable record, and operate in a data-residency context that respects the source narrator's jurisdiction.

How the EU regime intersects with GCC law

For products operating in both the EU and the GCC, three GCC-specific instruments matter:

UAE Federal Decree-Law 34/2021 (the cybercrimes law) covers identity misuse including unauthorised voice synthesis. Penalties include imprisonment and fines for using a cloned voice to impersonate someone without consent.
Saudi Arabia's PDPL (Personal Data Protection Law) governs personal-data handling generally; voice samples are covered as personal data. Cross-border transfer rules are stricter than GDPR in some respects (data localisation defaults).
The GCC's pending unified AI framework: the GCC Standardization Organization (GSO) has been drafting a regional AI standard since 2024. Drafts indicate it will largely mirror the EU AI Act's risk tiers; final adoption is expected in 2026-2027.

Practically, a voice-cloning vendor operating in both jurisdictions needs to:

Comply with both EU and GCC consent rules (the union of the two, not the intersection).
Apply the more restrictive data-residency obligation when they conflict (typically the GCC localisation rules).
Apply the EU transparency/disclosure rules globally for products distributed in the EU.
Maintain a takedown SLA for both the GDPR Right to Erasure and the GCC equivalents.

What "compliance posture" looks like

A defensible posture for a voice-cloning vendor or customer in 2026 includes the following operational controls:

Consent capture as a non-repudiable record: the source narrator records a consent declaration on video or audio that names the controller, the purpose, and the duration. Stored as immutable evidence.
Watermarking on output: every cloned-voice generation carries a watermark that can be detected by the controller (or by enforcement). The watermark is robust to typical post-processing (re-encoding, light EQ, loudness normalisation).
Audit log on every generation: who triggered the generation, what text was synthesised, what voice was used, what timestamp, what client. Retained for the period the consent covers, plus a defensible retention buffer.
Revocation pipeline: a documented path from "source narrator withdraws consent" to "all uses of the cloned voice are stopped, source samples are deleted, downstream content carrying the voice is flagged for takedown". Tested annually.
Disclosure phrase library: pre-translated disclosure phrases for the languages the product supports, in the registers the product uses (formal vs. conversational). Applied automatically at the start of agent calls and in audiobook intros.
Data-residency policy: source samples and inference logs land in the jurisdiction the product's primary user base sits in. Cross-border transfers are documented and gated by the appropriate transfer mechanism.
Public model card: the vendor publishes the dialect coverage, the corpus methodology, the consent posture, and the watermarking spec on a public model card. This is signalling to procurement teams that the vendor has thought about compliance, not just performance.

Hakim ships all of the above; the /security and /compliance pages document the specific controls.

What customers (not vendors) are responsible for

The EU AI Act splits obligations between providers (vendors who develop or supply AI systems) and deployers (customers who use AI systems in a professional capacity). Voice-cloning customers have their own set of obligations:

Apply Article 50 transparency where it applies: if the cloned voice is used in a public-facing product, the customer is responsible for the disclosure, not the vendor. The vendor provides the disclosure phrase library; the customer is responsible for actually playing it.
Capture end-user consent (different from source-narrator consent): if the product collects voice data from end users for any purpose, separate consent applies under GDPR.
Maintain records of use: which cloned voices are deployed in which products, who can trigger generation, what audit logs are retained.
Cooperate with the vendor's revocation pipeline: if a source narrator revokes consent, the customer has to remove the cloned voice from production within the SLA period.

The split is roughly: the vendor is responsible for consent capture from source narrators and for shipping the technical controls; the customer is responsible for end-user disclosure and for not using the technology in ways that violate Article 5.

What's NOT a Hakim use case

Hakim refuses on principle to:

Synthesise religious recitations (Quranic, Biblical, etc.). Religious texts have their own oral traditions and integrating AI voice into them creates theological and cultural sensitivities we don't think the technology should touch.
Clone voices of public figures without their explicit consent. The default policy is decline-to-serve on cloning requests where the source sample appears to be a public figure, even if the requester claims authorisation.
Clone voices for impersonation in fraud, social engineering, or political manipulation contexts. The consent capture is the firewall against this; we audit the consent records and decline use cases where the consent appears coerced or where the deployment plan violates Article 5.

These are operational policies, not just legal positions. The EU AI Act would let us synthesise some religious content if we labelled it correctly; we choose not to.

A short compliance checklist

If you're shipping a voice-cloning product into the EU and/or the GCC:

Map your use case against the act's risk tiers. Most commercial use cases are limited-risk; document the analysis in writing.
Implement Article 50 disclosure in the languages your product supports. Test the disclosure delivery rate at 100% in production.
Capture source-narrator consent as a non-repudiable record. Not a clickwrap; a recorded declaration.
Stand up a revocation pipeline and test it annually.
Maintain audit logs that survive the consent retention period plus a defensible buffer.
Document data residency. Apply the more restrictive of EU and GCC rules.
Watermark every cloned-voice generation. Verify the watermark survives typical post-processing.
Refuse use cases the act prohibits (Article 5 manipulation, public-figure impersonation without consent). Operational policy is the firewall, not just legal cover.

If you're a buyer evaluating voice-cloning vendors, ask for evidence of all eight controls. A vendor that can't produce evidence on five or more isn't yet ready for commercial deployment in the EU regime.

For Hakim's specific compliance documentation, /legal/dpa is the data-processing addendum; /security covers the operational controls; the voice-cloning consent post covers the consent posture in detail. If you have a question about a specific use case, email hello@tryhakim.ai with the deployment context.