AI Avatar Disclosure: Build a Consent and Provenance Register

An enterprise AI avatar needs three separate controls: documented authority to use the identity, clear disclosure to the audience and traceable provenance for the resulting content. A consent video alone does not provide all three.

The practical answer is to maintain an avatar rights register that connects every likeness, voice, source asset, model version, permitted role, channel, territory, expiry date, disclosure treatment and revocation action. If a team cannot query that register before generation or live inference, it cannot reliably know whether a particular use is authorised.

This is newly urgent in Europe. Article 50 of the EU AI Act has applied since 2 August 2026, introducing transparency obligations for certain interactive AI systems and AI-generated or manipulated content. The exact obligations depend on whether an organisation is a provider or deployer, what the system produces and how it is used. This guide is an operating framework, not legal advice.

Consent, disclosure and provenance answer different questions

These controls are often compressed into the word “consent”, which creates gaps at procurement and go-live.

Consent: are we authorised to do this?

Consent or another valid legal and contractual basis covers the use of a person’s appearance, voice, performance and source material. The permission needs a defined purpose. Approval for an internal training presenter does not automatically authorise a public sales agent, political message, multilingual advertisement or permanent digital representative.

Disclosure: does the audience understand what this is?

Disclosure tells a viewer or participant that the person is synthetic or that they are interacting with AI. It must work in the experience itself, not only in buried terms. A disclosure can be accurate while the identity use is unauthorised; equally, a fully consented avatar can still be misleading if the audience believes it is the real person speaking live.

Provenance: can we demonstrate what happened?

Provenance links an output to its generating system, source ingredients and material changes. It supports audit and detection, but it does not prove that a statement is true or that every underlying right was valid.

Treat the three as linked evidence, not interchangeable badges.

What changed on 2 August 2026

The European Commission’s current guidance on AI-generated content transparency explains that Article 50 applies from 2 August 2026. It describes obligations including explicitly informing people when they interact directly with certain AI systems, machine-readable marking of AI-generated or manipulated content by providers, and disclosure by deployers in specified contexts such as deepfakes.

Not every avatar output is automatically a deepfake, and not every organisation has the same role. A company may be a deployer in one workflow and a provider in another. The Commission and AI Board have also assessed the voluntary Code of Practice on Transparency of AI-Generated Content as a practical compliance instrument, while stressing that adherence is not conclusive proof of compliance.

For an enterprise buyer, the useful response is not a generic “AI-generated” watermark added at export. It is a control model that survives live interaction, recorded clips, translated versions, API distribution and future model upgrades.

Build an avatar rights register with seven linked records

A spreadsheet of signed releases is rarely enough. The register should be machine-queryable and connected to the systems that create, serve and publish the avatar.

1. Identity subject

Record the represented person, the method used to verify them, authorised representatives, contact route and ownership of the approval. Separate this from customer identity or biometric authentication systems.

2. Source assets

Inventory every recording, photograph, voice sample, script and performance used for capture, training, testing or evaluation. Store its origin, creator, collection date, licence, retention treatment and approved processing purpose.

Facial and voice material is personal information. Where data is technically processed for biometric recognition, additional rules may apply. The UK Information Commissioner’s Office says organisations using biometric recognition must identify an appropriate lawful basis and a separate condition for special-category processing; explicit consent is likely to be appropriate in many cases, but suitability depends on the circumstances. Avatar creation and biometric recognition are not automatically the same processing activity, so document the actual purpose rather than applying the label casually.

3. Permitted-use matrix

Translate the agreement into fields a system can enforce:

• approved role and subject matter;
• audience and age restrictions;
• live, recorded and interactive uses;
• internal, public, advertising and editorial channels;
• languages, territories and jurisdictions;
• prohibited topics, products and endorsements;
• start, review and expiry dates; and
• whether subcontractors or customers may generate outputs.

A free-text contract remains the legal source, but this policy representation makes pre-generation checks possible.

4. Model and derivative lineage

Connect the identity to every visual model, voice model, persona configuration, fine-tune, translated voice and derivative. Record versions and deployment locations. Our guide to updating on-premise avatar systems explains why the complete stack needs a version manifest rather than a single model number.

5. Disclosure policy

Define what the audience sees or hears before interaction, during a session and in exported content. Record the wording owner, language variants, visual treatment, machine-readable marking method and exceptions approved by counsel.

6. Distribution and approval history

Log who requested an output, which policy decision allowed it, which model produced it, where it was published and who approved release. For a live agent, record deployment and configuration events rather than attempting to approve every sentence in advance.

7. Revocation and incident state

A right that can be withdrawn needs a technical status, effective time, scope, owner and response plan. “Email the video team” is not a revocation control.

Turn a contract into a generation decision

Before a video renders or a live session starts, the system should evaluate a compact request:

• Which identity and model version?
• Which organisation and operator?
• What role, topic and intended audience?
• Which channel, territory and language?
• Live interaction or recorded output?
• What publication and expiry dates?

The policy service should return allow, allow with conditions, human review or deny, plus the rule version and required disclosure. Store that decision with the output or session.

This is more reliable than expecting every marketer, developer or event producer to reinterpret a rights agreement. It also gives procurement a testable control: submit combinations that should be approved, conditional and prohibited, then inspect the evidence.

Design disclosure for the whole experience

For a real-time avatar, disclosure is a journey rather than one watermark.

Before interaction

Name the experience as AI before the person speaks or turns on a microphone. Explain whether it represents a real individual, a licensed actor, a fictional character or a service persona. Avoid interface language that implies the human is present.

During interaction

Keep a clear, accessible indicator available without obscuring captions or controls. The avatar should be able to answer “Are you real?” directly. If a human takes over, make the change of identity explicit.

After interaction and on export

Preserve an intelligible label when clips are downloaded, embedded or separated from the original interface. Where applicable, attach machine-readable provenance and retain a link to the generating decision.

Accessibility matters here too. Colour alone is not enough; disclosure should work for screen readers, captions, audio-only users and translated interfaces. See our enterprise accessibility tests for AI avatars.

Provenance is evidence, not a truth machine

The C2PA Content Credentials specification provides a way to bind digitally signed, tamper-evident provenance assertions to media. It can help a consumer or platform understand how an asset was created or changed.

It does not decide whether the source agreement was fair, whether a person still consents or whether the avatar’s claim is accurate. An enterprise can reference a rights-register decision in its provenance process, but sensitive contract terms and personal information should not simply be exposed in public metadata.

Design for graceful degradation too. Platforms may strip metadata; live streams may not preserve file-level credentials; screenshots can separate pixels from provenance. Visible disclosure, system records and distribution controls are still required.

A practical revocation runbook

When permission expires or is withdrawn, the response should be scoped and repeatable:

1. Change the rights record to block new generation and live inference.
2. Disable affected avatar, voice and persona endpoints.
3. Stop queued renders, scheduled campaigns and unpublished translations.
4. Quarantine affected models and source assets from production access.
5. Identify distributed outputs and assess removal, relabelling or continued use against the agreement and applicable law.
6. Propagate the status to customers, processors and deployment environments.
7. Record actions, exceptions and completion evidence.

Backups complicate deletion. Rather than promising that every byte disappears instantly, document retention, make restored assets unusable without an active rights record and test that revocation remains effective after disaster recovery.

What private deployment changes

A properly scoped customer-hosted deployment can keep source footage, voice assets, avatar models, inference and the rights register inside the customer’s environment. That may reduce external exposure and give the customer direct control over access, retention and logging.

On-premise hosting does not create permission, satisfy disclosure by itself or prevent an authorised user from generating an unauthorised message. The rights service must sit in the request path, and the operating team must own policy updates, expiry and incidents. The component boundaries in our on-premise avatar stack guide help identify where those controls attach.

What Yepic’s live-persona work demonstrates

At MADFest, Yepic created a consented visual and vocal likeness of Rory Sutherland from smartphone footage captured two days before activation. The resulting persona had a deliberately narrow role: visitors confessed a marketing sin and received a recognisable, playful response. The Rory Sutherland case study shows why identity governance begins with purpose, not photorealism.

That project was a clearly framed event experience, not evidence that every live persona already uses the enterprise rights-register architecture described here. It demonstrates the underlying design discipline: obtain permission, define the role, make the premise legible and constrain behaviour.

Twelve questions for procurement and go-live

1. Can every likeness, voice and source asset be traced to documented authority?
2. Are permitted purposes represented as enforceable policy?
3. Can the system distinguish channel, territory, language and audience?
4. Which party is provider, deployer, controller and processor in each workflow?
5. What disclosure appears before, during and after interaction?
6. How are machine-readable marks created, validated and preserved?
7. Can every deployed model and derivative be found by identity?
8. Does an expired right block inference automatically?
9. How quickly can live endpoints and queued outputs be stopped?
10. What happens to public outputs, backups and customer copies after revocation?
11. Which evidence is available for an audit without exposing sensitive contracts?
12. Who owns the rights register after go-live?

Make identity a governed dependency

Start with one avatar and build the register before scaling languages, channels or customers. Connect approval to generation, disclosure to the experience and provenance to the output. Then revoke a test identity and prove that production, queues, exports and restored backups respect the change.

The trustworthy AI avatar is not merely one created with consent. It is one whose authority can be checked at runtime, whose synthetic nature is clear to the audience and whose history can still be understood after it leaves the original interface.