Consent for a cloned voice is a recording, not a checkbox

The deal was worth $340,000 a year and the customer had one ask: their voice agent should sound like Marta, their head of support, whose voice every one of their field technicians already knew from onboarding calls. The customer had three recorded webinars, about ninety minutes of clean audio, and they were happy to send the files. Legal reviewed the request in a day and came back with one line: get consent.

The product manager implemented that as a checkbox on the voice upload screen, reading "I confirm I have the speaker's permission to clone this voice", with the timestamp and the uploading user's ID written to the audit log. That satisfied the literal instruction and it is worth being precise about what it established. It recorded an assertion by the customer's IT administrator, who has no particular knowledge of what Marta agreed to, about a permission that may or may not exist, in a system Marta has never seen. If Marta objects six months later, the artefact you can produce is a row saying that someone else clicked something.

The checkbox does one real thing, which is to move contractual liability onto the customer. That is worth having and it is not the same as authorisation. It does not prevent the harm, it does not help you answer Marta, it does not survive a regulator asking how you verified the claim, and it fails completely in the case that matters most — where the uploader is the adversary. Anyone who can obtain ninety minutes of a public figure's speech can tick a checkbox about them.

What the cloning mode changes about the risk#

Building a synthesiser that sounds like one particular person is voice cloning: the model is conditioned on recordings of that person so that it reproduces their timbre — the grain of the voice that makes it recognisable independently of the words — along with their accent, pacing and habitual intonation, on text they have never said. Two modes of voice cloning are in common use, and they carry different quality and different exposure. Instant cloning conditions a general model on a short reference sample at inference time; professional cloning fine-tunes weights on a much larger corpus. ElevenLabs' own writeup, Voice cloning: how it works, is the clearest primary source on the split.

Ninety minutes of webinar audio puts Marta's request squarely in the professional tier, which is the tier where a cloned voice authorises a wire transfer over the phone. The engineering consequence of that is not that professional cloning needs a stricter checkbox; it is that the gate has to produce evidence from the speaker, because the whole value of the output is that it is indistinguishable from her.

The artefact that carries authorisation#

What actually establishes that Marta agreed is a recording of Marta agreeing, made for this purpose, tied to this request, and stored with the sample it authorises. The mechanism is a verification statement: your system generates a sentence at request time, containing a random phrase and the current date, and the speaker records themselves reading it.

"My name is Marta Oyelaran. On the ninth of August 2026 I authorise
 Ardent Logistics to create and use a synthetic copy of my voice.
 My verification phrase is: copper lantern fourteen."

Three properties make that recording load-bearing rather than ceremonial. The random phrase is generated by you, seconds before, so an old recording cannot be replayed against a new request. The date is spoken aloud, so the audio itself carries its own timestamp rather than relying on a database column an insider could edit. And the speaker's identity is asserted in their own voice, which lets you check it against the training sample automatically.

That check is a speaker verification model — an x-vector or ECAPA-TDNN embedding, the same family of models used for voice biometrics — comparing the verification statement against the uploaded corpus. Cosine similarity above a threshold means the person who read the statement is the person in the samples.

from speechbrain.inference import EncoderClassifier
import torch, torch.nn.functional as F

verifier = EncoderClassifier.from_hparams("speechbrain/spkrec-ecapa-voxceleb")

def check_statement(statement_wav, sample_wavs, threshold=0.72):
    stmt = verifier.encode_batch(statement_wav).squeeze()
    sims = []
    for s in sample_wavs:
        emb = verifier.encode_batch(s).squeeze()
        sims.append(F.cosine_similarity(stmt, emb, dim=0).item())
    median = torch.tensor(sims).median().item()
    return {"median_similarity": round(median, 3),
            "passes": median >= threshold,
            "per_sample": [round(x, 3) for x in sims]}

You also have to check that the spoken phrase matches the one you issued, which is what the recogniser from the previous topic is for, and that the recording was submitted inside a short window — ten minutes is generous — so that the phrase cannot be sent to someone else to read.

Be honest about the limit of this. A verification statement is itself audio, and audio can be synthesised, so a sufficiently motivated attacker with a good clone of Marta can produce a statement that passes speaker verification. Anti-spoofing countermeasures of the AASIST family detect synthetic artefacts and catch a useful fraction of that, and they are an arms race rather than a solution. What the verification statement does is raise the cost of abuse from "tick a box" to "already possess a high-quality clone and defeat a spoof detector", and route the request through a channel the real speaker controls. The second part matters as much as the first: send the verification request to Marta's own verified email or phone number, obtained independently of the uploader, so that consent arrives from her rather than about her.

Provenance is a record you can query in eighteen months#

The consent record has to answer questions that arrive long after the voice was created, usually from someone unhappy. Storing a boolean does not answer any of them.

CREATE TABLE voice_consent (
  voice_id            uuid PRIMARY KEY,
  speaker_name        text NOT NULL,
  speaker_contact     text NOT NULL,   -- verified independently of the uploader
  requested_by        uuid NOT NULL REFERENCES users(id),
  cloning_mode        text NOT NULL CHECK (cloning_mode IN ('instant','professional')),
  sample_sha256       text NOT NULL,
  sample_source       text NOT NULL,   -- 'speaker upload' | 'recorded session'
  statement_sha256    text NOT NULL,
  statement_phrase    text NOT NULL,
  statement_recorded  timestamptz NOT NULL,
  verification_score  numeric NOT NULL,
  antispoof_score     numeric NOT NULL,
  scope_products      text[] NOT NULL, -- what this voice may be used for
  scope_expires_at    timestamptz NOT NULL,
  jurisdiction        text NOT NULL,
  state               text NOT NULL,   -- see lifecycle below
  revoked_at          timestamptz,
  revoked_by          text,
  purge_completed_at  timestamptz
);

The two columns people leave out are scope_products and scope_expires_at, and their absence is what turns a consent into a blank cheque. Consent is not a licence. Marta agreeing that her voice may answer routine support questions for her employer's technicians for twelve months is a narrow permission, and it does not extend to marketing, to outbound sales calls, to a different product line, or to the period after she leaves the company. Storing the scope means the question "may this voice say this thing here" has an answer your code can enforce at synthesis time rather than an answer someone has to remember.

Revocation is a state machine with an SLA#

Revocation is the part most often written into a policy document and never into a system, so the policy says the speaker may withdraw consent at any time and nobody knows what would happen if one did.

Each transition needs a defined effect and a deadline. Revocation should disable synthesis within minutes, since that is a flag check on the request path. Deleting the fine-tuned weights and the speaker embeddings is a job with a 24-hour target, because it usually involves a vendor API and your own object storage. Purging cached audio — pre-rendered greetings, prompts baked into IVR flows, TTS results in a CDN — is the one that takes a week and the one people forget, since a revoked voice that still greets every caller from a cache is indistinguishable from no revocation at all.

Already-generated audio needs a decision rather than a reflex. Recordings of past support calls are business records, often retained under a separate obligation, and deleting them to honour a voice revocation may break a different rule. The workable line is that revocation stops new synthesis and purges anything that would still be played to a user, and does not retroactively destroy records of things that were said.

Abuse handling completes the loop, and its distinguishing feature is that the reporter is usually not your customer. Marta, or someone who has never heard of you, needs a way to say "this sounds like me" and get a human response. That requires an intake path that does not require an account, a way to trace a piece of audio back to a voice_id, and an authority to suspend a customer's voice while you investigate. Tracing is where audio watermarking earns its place: a perceptual watermark embedded at synthesis survives MP3 transcoding and moderate re-encoding, and lets you confirm that a clip came from your system and which voice produced it. It degrades under aggressive processing, and detection generally runs on the provider's side, so treat it as an investigative aid rather than as proof.

Where output gets labelled, and where you say no#

Disclosure is a product decision with a legal floor that moves by jurisdiction, and the engineering consequence is small and specific: decide, per surface, whether the synthetic nature of the voice is announced, and build the announcement into the surface rather than into a runbook. For a phone agent that usually means a spoken disclosure in the first turn. For generated audio that leaves your product as a file, it usually means a watermark plus metadata. The EU AI Act's transparency obligations for AI systems that interact with people and for synthetic audio came into application on 2 August 2026, and several US states have voice-likeness statutes — Tennessee's ELVIS Act is the most cited — so the specific text belongs to counsel. What belongs to you is the property that no code path can emit cloned audio without the disclosure attached, which is easier to guarantee if disclosure is a field on the voice record rather than a step in a flow.

Which brings the Marta request to its answer. Three recorded webinars plus a customer's checkbox authorises nothing, and no amount of contract language changes that, so the feature as specified gets refused. What you offer instead has three parts. The customer's admin can initiate a request, which sends Marta a link at an address she confirms; Marta records the verification statement herself and, if she chooses, records a fresh 30-minute sample in a quiet room, which produces a better clone than webinar audio anyway; and the resulting voice carries a scope, an expiry that requires a renewal, and a revocation link that belongs to Marta rather than to her employer. If she declines, or if she is unreachable, the fallback is a stock voice selected to match her characteristics, which the customer will find disappointing and which costs nobody anything.

The awkward case is worth deciding in advance rather than in the moment: Marta leaves the company nine months in. Her consent was hers to give, so the voice does not transfer with her badge, and the honest default is that departure triggers a re-confirmation and the scope expiry does the rest if she does not answer.

A voice that clears this bar is one you are allowed to ship, which leaves the question of whether it is the right one. Choosing between two synthesisers turns out to be a measurement problem with several traps in it, starting with the fact that the script you test on decides the answer before you listen to anything.