AI voice licensing: permissions, royalties, and revocation

An AI voice license is a permission chain

A production-ready AI voice license is a set of contract grants tied to operational controls. There is no universal license that automatically clears the speaker's identity, the recordings used to create a model, model training, generated speech, and every commercial use.

Keep these rights layers separate:

A text-to-speech subscription only grants the rights stated in that service agreement. Ownership of a studio recording does not necessarily give you permission to clone the performer's voice. Consent to record an employee does not necessarily authorize a customer-facing replica. Disclosure that a voice is synthetic does not fill any of those gaps.

The same separation applies to Dasha. Our APIs can create and use a cloned voice, but an accepted API request is a technical event. It does not establish the customer's upstream permission or make every downstream call and publication lawful.

Choose the voice source before drafting the agreement

The right contract starts with the source of the voice. Each option changes the clearance burden and the production controls you need.

A generic voice often has the simplest rights path. A licensed replica can provide continuity or a recognizable brand voice, while adding approvals, reporting, security, and termination work. A celebrity, executive, employee, or customer voice should never enter production as an informal upload.

Put the intended use into the contract

Broad language such as “all media, worldwide, forever” gives an engineering team little guidance about what to allow. A usable agreement translates the commercial deal into fields a system can evaluate.

Define the permitted use

State all of the following:

• Product and audience: the named product, customer or tenant types, internal versus external use, and whether demos or sales material are included.
• Purpose and content: support, entertainment, accessibility, education, advertising, transactional calls, or another defined function.
• Channels and media: phone, browser, mobile app, game, broadcast, podcast, advertisement, social media, or downloadable audio.
• Territory and languages: where the output may be generated, heard, stored, and distributed, plus approved languages and accents.
• Term and renewal: start date, end date, renewal mechanism, notice window, and treatment of existing output after expiration.
• Exclusivity: the exact field, market, character, product, or period covered. Avoid an undefined ban on the performer working with other voice systems.
• Sensitive contexts: rules for political, adult, medical, financial, religious, biometric, impersonation-sensitive, or endorsement-like uses.
• Approvals: which scripts, campaigns, characters, voice changes, translations, and customer deployments need approval, and the response deadline.

California illustrates why specificity matters. For new performances fixed on or after January 1, 2025, Labor Code section 927 can make a digital-replica provision unenforceable when it substitutes for the individual's work, lacks a reasonably specific description of intended uses, and the individual lacked qualifying counsel or union representation.

Separate creation, training, and improvement

Permission to synthesize approved scripts should not silently become permission to improve a general model. Address each operation directly:

• capture and edit source audio;
• create the initial voice model;
• retrain or fine-tune the same voice;
• combine the voice with new languages, accents, emotions, or characters;
• create derived weights or checkpoints;
• use recordings, transcripts, model artifacts, or output to improve another model;
• run human or automated quality evaluation; and
• export or transfer the model between providers.

Define who owns each artifact and who may possess it. If general model improvement is prohibited, pass that restriction through to hosting, speech, analytics, and subcontracting providers.

Control transfer and sublicensing

A production chain may include the performer, producer, voice-model provider, agent platform, cloud host, application owner, enterprise customer, and end user. The agreement should identify which parties may receive what.

Specify whether rights can be assigned, transferred after an acquisition, or sublicensed. Require downstream parties to follow the same use, security, disclosure, reporting, no-training, retention, and deletion limits. A customer-facing platform also needs rules for tenant access. One tenant should not be able to discover, preview, or select another tenant's licensed voice.

Allocate warranties, incidents, and claims

The licensor should identify the rights they control. The licensee should commit to the allowed uses. Providers should commit to their security, retention, training, and deletion obligations. The agreement also needs a process for complaints, disputed ownership, unauthorized synthesis, security incidents, suspension, defense, and indemnity.

Keep the contract testable. “Industry-standard security” is weaker than named controls, access boundaries, notification deadlines, and deletion evidence.

Design compensation around measurable use

There is no universal AI voice royalty rate. Compensation can reflect the recording work, the replica's commercial value, the breadth of the license, actual use, exclusivity, and the opportunity the replica replaces.

“Usage” must have one precise unit. It could mean synthesized characters, generated seconds, delivered minutes, completed calls, published assets, impressions, active users, or attributable revenue. These units are not interchangeable. A minute synthesized during a failed test is different from a minute delivered to a customer, unless the contract says otherwise.

The usage statement should be reproducible from system records. For each chargeable event, retain the voice ID, model version, customer or project, timestamp, channel, quantity, status, and applicable contract version. Give the performer or representative enough aggregated evidence to audit payment without exposing unrelated customer data.

Renewal also needs an explicit rule. Define whether continued use triggers a new term, whether rates change with broader deployment, and whether a dormant model can remain stored between terms.

Make revocation and termination executable

“Revocable” has no single default operational meaning. A contract should distinguish four events:

• Expiration: the agreed term ends.
• Termination for breach: one party ends the agreement after a defined violation and cure process.
• Contractual withdrawal or takedown: the performer can withdraw specified uses under agreed conditions.
• Emergency suspension: synthesis stops while the parties investigate misuse, a security incident, or a rights dispute.

Do not promise an unrestricted revocation right unless the agreement creates one. Likewise, do not assume termination automatically erases model weights or forces already published output offline. The contract must define the consequence for each artifact and use.

Write the wind-down by artifact

Run a controlled termination workflow

1. Suspend new synthesis. Disable the voice in production and test environments, reject new clone or export jobs, and replace it in active agent configurations.
2. Freeze derivative work. Stop fine-tuning, language expansion, evaluation jobs that create new artifacts, and use in general model improvement.
3. Inventory every copy. Enumerate source files, datasets, voice IDs, weights, checkpoints, previews, outputs, caches, backups, and provider-held copies.
4. Apply the output rule. Remove, replace, or preserve previously generated audio according to the contract and applicable law.
5. Notify downstream parties. Send the same suspension and deletion scope to providers, customers, affiliates, and subcontractors within the agreed deadline.
6. Delete or isolate artifacts. Record the system, object, action, operator, timestamp, and any backup expiry that remains pending.
7. Preserve limited evidence. Keep the minimum contract, payment, incident, and deletion records needed to prove what happened.
8. Close only after verification. Obtain provider confirmations, run discovery checks for missed copies, and mark the rights record inactive.

In Dasha, deleting a cloned voice makes it unavailable in the organization's voice library and for new synthesis. That operation is one step in the workflow. It does not by itself prove deletion from source storage, an upstream provider, a training dataset, derived weights, caches, backups, or published output.

Jurisdiction changes the minimum contract

Copyright, personality rights, digital-replica laws, biometrics rules, advertising law, labor law, and collective-bargaining agreements can all apply. The same voice may cross several of them.

United States

The United States has no single enacted federal AI voice license. The U.S. Copyright Office separates copyright in recordings and other expression from protection of a person's identity, voice, or likeness. A copyright license therefore does not settle every digital-replica claim.

Federal proposals are still moving. The NO FAKES Act of 2026, Senate bill S.4591, was placed on the Senate legislative calendar after committee action. It is a bill, not enacted law. Production teams still need to map current state law and any applicable contract or collective-bargaining terms.

Material state differences include:

• California: Civil Code section 3344 covers knowing commercial use of a living person's voice without prior consent, subject to exceptions. Section 3344.1 separately addresses deceased personalities and digital replicas. Labor Code section 927 adds the service-contract rule described above.
• New York: Civil Rights Law section 50 and section 51 generally require written consent for use of a living person's voice for advertising or trade, with separate rules and exceptions elsewhere in state law.
• Tennessee: The ELVIS Act expressly protects voice and reaches specified unauthorized uses and certain technologies, while preserving statutory exceptions.
• Illinois: The Right of Publicity Act addresses commercial use of identity. The Biometric Information Privacy Act separately regulates a voiceprint, including notice, written release, disclosure, and retention duties. Ordinary voice audio is not automatically a voiceprint.

A licensed voice used in outbound calls creates another layer. The Federal Communications Commission treats AI-generated voices as artificial or prerecorded voices under the Telephone Consumer Protection Act. Voice-owner consent does not authorize the call. Our guide to AI cold-calling rules separates call permission, data processing, recording, and AI disclosure.

European Union

The EU AI Act and the General Data Protection Regulation (GDPR) answer different questions. Since August 2, 2026, AI Act Article 50 has applied transparency and marking duties to specified AI-generated or manipulated content and deepfakes. Under the 2026 amendment, providers of AI systems placed on the market before 2 August 2026 have until 2 December 2026 to comply with Article 50(2)'s marking duty. Those duties do not grant permission to use a person's voice.

The GDPR regulation governs personal data. Voice data becomes special-category biometric data when it is technically processed for the purpose of uniquely identifying a person. A voice recording used only as audio and a voiceprint used for identity matching can therefore receive different treatment. Purpose, lawful basis, transparency, processor terms, transfers, security, retention, and data-subject rights still require their own analysis.

EU member-state copyright, performer, personality, employment, and contract rules can add further requirements. Deployment country and audience matter, even when the model was built elsewhere.

Disclosure is an additional control

A synthetic-content label, spoken AI disclosure, watermark, or provenance record can improve transparency and may be legally required. None substitutes for permission, call consent, recording notice, privacy compliance, or the contractual right to create and deploy the voice.

Implement a rights control plane

A signed agreement cannot stop an out-of-scope API request by itself. Translate the contract into a rights record and enforce it alongside the voice model.

Keep one rights ledger per voice and model version

The record should include:

• voice ID, model version, provider, and storage locations;
• right holders and authorized signatories;
• consent evidence and contract version;
• source-recording and script ownership;
• approved products, customers, purposes, channels, territories, and languages;
• prohibited contexts and required approvals;
• effective date, expiry, renewal, suspension, and notice windows;
• permitted training, fine-tuning, derivatives, transfer, and sublicensing;
• compensation formula and metering source;
• disclosure, watermarking, and provenance requirements;
• retention and deletion rules by artifact; and
• current status, incidents, provider confirmations, and deletion evidence.

Use stable internal identifiers rather than the performer's name in routine logs. Restrict the underlying contract and identity evidence to the people who need it.

Enforce rights in the deployment path

Add controls at each stage:

1. Onboarding gate: accept source audio only when the rights record exists and covers model creation with the chosen provider.
2. Registry gate: bind every deployable voice ID and derived version to the same rights record.
3. Environment gate: keep development, evaluation, demo, and production permissions distinct.
4. Policy gate: check tenant, use case, channel, territory, language, term, and approval before synthesis.
5. Access gate: restrict clone, export, update, and delete operations separately from ordinary synthesis.
6. Metering gate: emit immutable usage events in the payment unit defined by the contract.
7. Expiry gate: block new use automatically at expiration unless an approved renewal is active.
8. Incident gate: provide one suspension control that disables synthesis across agents and environments.
9. Deletion gate: track every artifact and downstream request until verification is complete.

Logs should answer who used which model, under which contract version, for what approved context, and what output or business event resulted. Avoid retaining full audio just to prove a policy decision when structured event fields are enough.

Operate licensed voices in Dasha

Dasha gives technical teams a managed runtime, REST APIs, and a web application for production voice agents. The current voice API can list public and cloned voices, clone a voice from audio, and delete a cloned voice from the organization's library.

Use those surfaces inside your licensing controls:

• map each Dasha voice ID to your rights-ledger record;
• permit cloning only for authorized source audio and providers;
• store approved-use metadata in your control plane;
• restrict which agents and tenants can select the voice;
• meter synthesis in the contract's defined unit; and
• trigger agent reconfiguration, Dasha deletion, provider requests, and evidence collection from one termination workflow.

We provide the production voice surface. You remain responsible for obtaining the necessary rights and defining the policies that apply to your product, customers, calls, and output.

Start with one licensed voice, one real agent, and one revocation drill. Build the agent in Dasha, then prove that your team can trace an output to its rights record and disable every new use on command.