How AI Video Likeness Consent Should Work

How Consent-Based Likeness Should Work in AI Video

Consent-based likeness in AI video should be a lifecycle, not a one-time upload. A person needs meaningful control over enrollment, identity proofing, purpose, permitted creators, allowed contexts, output visibility, delegation, renewal, revocation, existing media, reporting, appeal, audit, retention, and deletion.

A checked box cannot answer what happens after a synthetic likeness is shared, remixed, downloaded, or misused.

Begin with the identity and purpose

The system must decide how much assurance is needed that the enrollee is the person represented and has authority to grant the requested use. A casual private avatar and a public commercial replica create different consequences.

NIST's current Digital Identity Guidelines cover identity proofing, authentication, federation, fraud, and forged-media threats for government systems. They do not prescribe a consumer cameo feature. They do support treating proofing as a risk decision rather than assuming a selfie is enough.

The enrollment notice should name the product, the data captured, the purpose, the people who may generate, the contexts allowed, how outputs can be discovered, how long the likeness remains active, and what withdrawal can and cannot remove.

Separate the permissions

"My friends can use me" is not one permission. The product should separate who, what, where, and for how long.

The defaults should protect the narrower reasonable expectation. Expanding the audience or purpose should require a new choice.

Make consent specific and withdrawable

Where UK GDPR consent is the lawful basis, the ICO's current consent-management guidance says the request must identify the organization, purpose, activity, and withdrawal right, and that withdrawal must be as easy as giving consent.

Other jurisdictions and lawful bases differ, but the product-design test remains valuable. If the person cannot understand the scope or cannot reverse it without punishment, the control is not meaningful.

flowchart LR
    A["Identity and authority"] --> B["Specific purpose and scope"]
    B --> C["Generate with visible limits"]
    C --> D["Discover, label, and report"]
    D --> E["Renew, narrow, or revoke"]
    E --> F["Handle existing outputs and retained records"]

Design revocation before launch

Revocation can stop new generations. It can remove the likeness from discovery. It can invalidate delegated access and prevent future remixing inside the product.

Existing outputs are harder. Some may remain in another user's private workspace, a public feed, an export, a cache, a backup, or an external platform. The product should state what it can delete, disable, de-index, label, or request another user to remove. It should also state what it cannot retrieve.

A withdrawal record may need to remain so the system knows not to process the likeness again. The reason and lawful basis for that retention should be disclosed.

Give the represented person visibility

The person should be able to see who has permission, what was generated, where it is visible, which outputs were exported when known, and which reports remain open. High-risk uses can require approval before release rather than notice afterward.

OpenAI's launch-era Sora safety record described consent-based characters and provenance controls. The Sora 2 Deployment Safety Hub also acknowledged that layered safeguards can be circumvented. Designed controls reduce risk. They do not guarantee that every output is consensual or harmless.

Build reporting and appeal for both sides

The represented person needs a fast route to report nonconsensual, misleading, intimate, political, harassing, or commercial use. A creator also needs an appeal when a legitimate authorization is incorrectly blocked.

Reports should preserve the relevant evidence without continuing unnecessary public exposure. The owner, response time, emergency route, escalation path, and outcome notice should be defined before launch.

Minors, deceased people, guardianship, employee relationships, intimate content, political persuasion, and coercion need specialized policy. They should not be treated as ordinary toggle settings.

Product consent is not the whole legal answer

The U.S. Copyright Office's AI initiative documents an uneven state-law landscape for digital replicas and recommends federal legislation. The USPTO's current name, image, and likeness guidance distinguishes state NIL rights, trademarks, contracts, and other protections.

A product permission does not settle copyright in source material, false endorsement, publicity rights, privacy, labor agreements, contracts, or another person's rights inside the same scene. [[AI Video Copyright Characters and Style]] maps those separate questions.

Assign accountable ownership

Trust and safety should not own the lifecycle alone. Product defines the controls and defaults. Security protects enrollment and accounts. Privacy defines data handling. Legal maps rights and jurisdictions. Operations handles reports and removals. Engineering implements enforcement and audit. Leadership accepts residual risk.

Measure unauthorized generation attempts, time to revoke, time to remove discoverability, repeat abuse, mistaken identity, appeal outcomes, and whether people understand the scope they granted.

Meaningful likeness consent is not "yes, use my face." It is the continuing ability to understand, constrain, observe, and end a synthetic identity relationship.

This page provides product-design guidance, not legal advice. Rights and obligations vary by jurisdiction and use. Sources were reviewed on July 27, 2026. AI assistance was used for research organization, drafting, and validation. Publication remains unauthorized.