Deepfake and Voice-Clone Simulations: Consent, GDPR Art. 9 and EU AI Act Art. 50

What makes a deepfake simulation legally different from a phishing email

A deepfake simulation uses an AI system to imitate the face or voice of a real, identifiable person, usually a senior manager, and presents that imitation to employees as if it were genuine. A phishing email simulation only imitates a sender address and a writing style. That difference brings in three bodies of law that a normal phishing test barely touches.

• Personality and image rights of the person being imitated. In Germany these include § 22 of the Art Copyright Act (KUG), under which a person's likeness may only be distributed or shown publicly with their consent, and the general right of personality, which courts have extended to a person's voice.
• Data protection for the voice samples, video footage and trained model of that person, and for the behavioral data of the employees who receive the call or join the meeting.
• The EU AI Act, because the content is "AI-generated or manipulated image, audio or video content that resembles existing persons [...] and would falsely appear to a person to be authentic or truthful". That is the definition of a "deep fake" in Article 3(60) AI Act.

For the technical side, see our explainer on how voice and video deepfakes are made.

Two groups, two legal questions

The most common mistake in internal reviews is to treat "consent" as one question. It is two. The executive whose voice is cloned is in a very different position from the accounts payable clerk who receives the call, and the legal tools that fit one group often do not fit the other.

Person who is cloned (often an executive)Employees who are testedWhich dataVoice recordings, video footage, the trained voice or face model, scripts spoken in their nameWho was contacted, how they responded (reported, verified, complied), timingTypical legal basis to assessConsent, because personality rights (KUG, right to one's own voice) usually require it anywayLegitimate interest (Art. 6(1)(f) GDPR) or, in Germany, a works agreement (§ 26(4) BDSG); consent of the tested staff is rarely workableRole of consentCentral: scope, duration, purpose limitation, withdrawalUsually not the basis, because a simulation that needs prior agreement from each target loses its pointRights and dutiesWithdrawal at any time (Art. 7(3) GDPR), deletion of the model, informationInformation about the program, access requests, co-determination where a works council existsDocumentationSigned consent, model inventory, deletion logDPIA decision, works agreement or balancing test, debrief records

The table is our own structuring, not a legal standard. In practice you need one documented answer per column, and the evidence for each comes from different people.

Is a voice clone biometric data under GDPR Art. 9?

A voice clone is personal data, but it is special-category biometric data under Art. 9 GDPR only if it is processed "for the purpose of uniquely identifying a natural person". Synthesizing a voice to imitate someone is not obviously that purpose. Adding speaker recognition or face recognition changes the answer.

The legal text sets two hurdles. Article 4(14) GDPR defines biometric data as personal data "resulting from specific technical processing" of physical, physiological or behavioral characteristics "which allow or confirm the unique identification" of a person. Article 9(1) then prohibits processing "biometric data for the purpose of uniquely identifying a natural person" unless an exception applies, such as explicit consent under Art. 9(2)(a).

The European Data Protection Board applies a purpose test. In its Guidelines 3/2019 on video devices (paragraphs 75–76), it names three criteria: the nature of the data, the means of processing, and the purpose of uniquely identifying a person. In its Guidelines 02/2021 on virtual voice assistants (paragraph 31), the EDPB states that "voice data is inherently biometric personal data", and that an Art. 9 exception is needed when such data is processed for the purpose of unique identification or is otherwise special-category data.

Our reading: we found no supervisory authority guidance that says directly whether training a synthetic voice to imitate someone falls under Art. 9. Under the EDPB purpose test, there are good arguments that it does not, because the goal is imitation, not identification. Not everyone agrees. Writing for Legal Tribune Online, lawyers Georg Manthey and Simon Liepert classify the voice as biometric data protected under Art. 9 without that distinction.

For a simulation program, the safe design is to treat the cloned person's voice and face as if Art. 9 applied: get explicit consent from that person, record it in a form that would satisfy Art. 9(2)(a), and keep the voice model out of any identification or authentication system. This is not legal advice.

Consent from the person being cloned

For the person whose voice or face is cloned, consent is the realistic legal basis, and it has to hold up in an employment relationship. That is harder than it sounds, because the EDPB considers employee consent valid only in exceptional cases.

In its Guidelines 05/2020 on consent (paragraphs 21–22), the EDPB says it is "problematic" for employers to rely on employee consent, and that employees "can only give free consent in exceptional circumstances, when it will have no adverse consequences at all whether or not they give consent". Its Example 5 (paragraph 23) describes a film crew in an office: staff who decline are moved to equivalent desks and not penalized in any way.

Applied to a voice clone, that means:

• No pressure, no consequences. The executive must be able to say no without any effect on their role or standing. Our reading is that senior managers who sponsor the security program are in a better position to give free consent than junior staff, but the test does not change. Document that a refusal was a real option.
• Specific scope. Name the purpose (security simulations for this organization), the channels (phone, video meeting), the duration and who can generate content with the model.
• Withdrawal at any time. Under Art. 7(3) GDPR, withdrawing consent must be as easy as giving it. Plan for what withdrawal triggers: stop using the model, delete it and the training samples, confirm deletion in writing.
• No reuse. The model must not be used for internal videos, marketing or anything else outside the simulation without a separate decision.

In Germany, § 26(2) BDSG adds formal requirements for employee consent: it must be given in writing or electronically, and the employer must inform the employee in text form about the purpose and the right to withdraw. Where special-category data is involved, § 26(3) requires that the consent refer explicitly to that data. The German data protection authorities confirm the form requirement in their short paper no. 20 on consent (DSK, as of 23 September 2026).

Two further points for German employers. First, the Court of Justice of the EU ruled in Case C-34/21 (30 March 2023) that national employee data rules which only repeat the general GDPR conditions do not qualify as "more specific rules" under Art. 88 GDPR and must be disregarded; processing is then governed directly by the GDPR. German employers should therefore not build a simulation program on the general clause in § 26(1) BDSG without checking it against that ruling. Second, personality rights apply in parallel to data protection: the German Federal Court of Justice held in its "Marlene Dietrich" judgment (I ZR 49/97, as summarized by LTO) that the voice is protected as a feature that makes a person recognizable. Data protection consent and personality-rights consent can sit in one document, but both should be covered. This is not legal advice.

Legal basis for testing employees

For the employees who receive a deepfake call or meeting invitation, consent is usually the wrong tool. A legitimate interest under Art. 6(1)(f) GDPR, or in Germany a works agreement under § 26(4) BDSG, are the bases most programs assess. Neither applies automatically.

A legitimate interest needs a documented balancing test. A deepfake of a known executive puts more pressure on employees than a generic phishing email, so the balancing has to account for that: realistic but not humiliating scenarios, no individual sanctions based on a single interaction, quick debriefing, and data minimization in reporting. National employment law can add requirements.

Whether a data protection impact assessment (DPIA) is required depends on the actual processing risks, and a program with cloned voices of identifiable people is a strong candidate. Our DPIA template for phishing simulations walks through the checks.

In Germany, where a works council exists, a simulation platform that records how individual employees respond is likely subject to co-determination under § 87(1) no. 6 BetrVG, which covers technical systems designed to monitor employee behavior or performance. A works agreement can then also serve as the legal basis under § 26(4) BDSG. Our works agreement template lists the clauses that matter most; for deepfakes, add the scenario exclusions and the deletion rules for voice models. This is not legal advice.

EU AI Act Art. 50(4): disclosing deepfakes since 2 August 2026

Since 2 August 2026, deployers of AI systems that generate or manipulate deepfake image, audio or video content must disclose that the content is artificially generated or manipulated. The duty comes from Article 50(4) AI Act and applies from the date set in Article 113. It contains two exceptions: use authorized by law to detect, prevent, investigate or prosecute criminal offences, and a lighter regime for "evidently artistic, creative, satirical, fictional or analogous" works. Neither fits an internal security simulation.

Timing is set by Article 50(5): the information must be provided "in a clear and distinguishable manner at the latest at the time of the first interaction or exposure".

The European Commission's guidelines on Article 50, published on 20 July 2026, add detail. Formally they are the approved content of a draft Commission communication (C(2026) 5054), so they are guidance, not binding law. The paragraphs most relevant to simulations:

• Disclosure must be perceivable (para. 117). Labels should be visible or audible and understandable without technical tools. Deployers "cannot rely on the machine-readable marking" that providers embed under Art. 50(2).
• Earlier is allowed, later is not enough (para. 143). Deployers may inform people before the first exposure. The guidelines also say the obligation applies "to each output" for each person exposed to it.
• No blanket research exclusion (paras. 21–22). The exclusion for scientific research covers systems used solely for that purpose, and testing in real-world conditions is not covered by the exclusion for pre-market testing.
• Transparency does not make a use lawful (para. 25), and GDPR applies on top (para. 127). If the deepfake relates to an identifiable living person, the deployer must also meet data protection law, including an appropriate legal basis.

We found no exception for security training or simulations in the Act or the guidelines. A 2026 amendment from the Digital Omnibus package added a transition period until 2 December 2026, but only for the providers' machine-readable marking duty in Art. 50(2), as the consolidated text of Article 111(4) shows. The deployer duty in Art. 50(4) was not postponed.

The tension with realism. A common design for simulations is to reveal the deepfake only in the debrief after the call. We do not think the wording of Art. 50(5) obviously covers that, because the debrief comes after the first exposure. Options your legal team can assess:

1. Program-wide advance notice. Employees are told in writing, before the program starts, that it will include AI-generated voice and video of real colleagues, without saying when. Paragraph 143 allows earlier information, but whether a general notice satisfies a duty that applies "to each output" is open.
2. Disclosure inside the content. An audible statement or visible label at the start of the call or meeting. This is the clearest route under Art. 50, at a cost in realism. It can still test whether staff follow the verification process when an instruction is unusual.
3. Personas that resemble no existing person. A synthetic voice that does not imitate a real person may fall outside the Art. 3(60) definition, though the definition also covers existing "entities", and the guidelines treat resemblance as a case-by-case assessment.
4. Codes of practice. Under Art. 50(7), deployers can adhere to a code of practice to demonstrate compliance. The Commission published the voluntary Code of Practice on marking and labelling of AI-generated content on 10 June 2026.

Two further questions are often missed. Who is the deployer? The guidelines (para. 12) tie the role to deciding whether and how an AI system is used. Our reading is that this usually points to the customer organization, though a vendor that designs and runs campaigns on its own may share the role. Do live AI voice personas trigger Art. 50(1) as well? A persona that holds a conversation is likely an AI system "intended to interact directly with natural persons". That duty sits with the provider: people must be informed they are dealing with an AI system unless this is obvious, and for telephony the guidelines (section 3) suggest a spoken statement at the start.

Our assessment: Art. 50 does not ban deepfake simulations, but it changes how they must be designed. Decide the disclosure model with counsel before the first campaign and record the reasoning. This is not legal advice.

A design checklist for lawful deepfake simulations

Use this checklist before the first deepfake or voice-clone campaign. Each line needs an owner and evidence you could show an auditor, a works council or a supervisory authority.

CheckOwnerEvidenceConsent of each cloned person: scope, channels, duration, withdrawalDPO with HRSigned consent (written or electronic), information in text formDeletion concept for voice and face models and training samplesSecurity lead with vendorDeletion procedure, deletion confirmation after withdrawal or program endStorage location and access to modelsSecurity leadData processing agreement, access list, hosting locationNo use of models outside the simulationProgram ownerContract clause, written internal ruleAI Act disclosure model (advance notice, in-content label or both)LegalLegal memo, notice text, label wordingDebrief after every deepfake interactionAwareness leadDebrief content, timingDPIA decisionDPODPIA or documented screeningLegal basis for testing employeesDPO, works council where one existsBalancing test or works agreementExcluded scenarios (for example: health, family emergencies, dismissal, pay)Works council, HRScenario list in the works agreementOpt-out route and contact person for distress or complaintsHRPublished contact, process description

Deepfake simulation examples by role

A deepfake simulation is only defensible, legally and ethically, if it tests a clear defensive behavior. The table shows example scenarios (fictional, for planning) with the response each one should train. None of them needs a sensitive pretext such as health or a family emergency.

RoleScenario and channelBehavior testedDesired responseMetricAccounts payableEmail about an urgent supplier payment, then a call with the cloned CFO voice approving itPayment approval under authority pressureHang up, call the CFO back on the directory number, report email and callVerification rate, report rateIT service deskCall from a cloned executive voice asking for an MFA reset while "traveling"Identity check before account changesFollow the documented identity check, refuse the reset until it passesShare of calls where the check was appliedExecutive assistantsShort video meeting with a cloned manager asking for a confidential file to be shared externallyData release on an unusual channelConfirm the request through a second, known channel before sharingVerification rate, time to reportFinance leadershipVoicemail from a cloned CEO voice about a confidential acquisition and a new bank accountSecrecy as a pressure tacticEscalate through the agreed approval process, report the voicemailReport rate

Define the measures before the campaign. Verification rate = employees who verified through an independent, known channel ÷ employees who actually received the call or meeting (not everyone on the target list). Report rate = employees who reported ÷ the same recipients. Whether someone "recognized" the deepfake matters less than whether they followed the process, because good clones will not always be recognizable.

How revel8 runs deepfake simulations

revel8 runs deepfake simulations as part of its multi-channel Awareness Playlist: lifelike video clones that join live meetings, AI personas that place live calls and leave voicemails, and chains that start in the inbox and escalate to a call. Personal OSINT used for personalization is collected only with consent, and the platform is hosted on STACKIT in Germany. For reporting, revel8 states that its risk monitoring is works-council conform, without individual surveillance.

Hosting location and product design do not make a program compliant on their own. The consent of cloned persons, the legal basis for testing staff and the Art. 50 disclosure model remain decisions for your organization. If you compare vendors, our overview of deepfake awareness training platforms lists what each one documents publicly.

To see how a deepfake simulation runs with a data protection and works council setup, book a demo.