A real person's photo avatar reading a script: YouTube disclosure

If you build a Sume avatar from a real person's photo and give it a script, the video can show that person saying words they never said. YouTube's help page lists that case, making a real person appear to say or do something they did not, among the content creators must disclose.

What YouTube's page says

As read on 2026-10-08, YouTube requires disclosure when AI makes a real person appear to say or do something they did not do, or generates a realistic scene that did not occur. Labels appear in the video player for photorealistic content and in the expanded description for non-photorealistic content.

How it maps to Sume avatars

Sume creates avatars from a prompt, structured props or a reference photo (photo, a public HTTPS image_url). A props or prompt avatar has no real person behind it. A photo avatar does, and the scripted speech is words that person may not have said.

The docs for creation and talking video describe inputs and limits; they do not set a consent or disclosure policy, so that decision stays with you and the platform where you publish.

• Photo of yourself, saying your own script: lowest risk, still consider a label.
• Photo of someone else: get their written permission before creating the avatar.
• Public figure: do not.
• Invented presenter from props: describe it as AI-generated in the post.

Practical steps

Keep a record of who agreed to what, keyed by the avatar handle. Put the disclosure where the platform asks for it, and add a short on-screen line if the clip could be mistaken for a real testimonial. Check the page above before publishing, since platform rules change.

Practical notes

Job lifecycle. Every Sume avatar request is job-backed. You submit, store the job id, and poll GET /v1/jobs/{id}/status until it completes, then read GET /v1/jobs/{id}/result. The shared lifecycle also lets you wait with sync or subscribe mode for a limited time instead of polling, and the result carries Sume-hosted artifacts rather than provider URLs, so you never handle a provider queue id. Plan your client around the job, not around a single blocking response.

Media inputs. Any media field, whether product_image, scene.image_url or an avatar image_url, must be a fetchable public HTTPS URL. Sume rejects localhost, private-network and non-HTTPS addresses before it submits anything, so a broken link fails fast instead of consuming a render. Host reference images where Sume can fetch them and keep them available until the job finishes.

Reading results. A completed result can include public media.sume.com video artifacts, and for avatar videos also public-safe preview fields such as preview_image_url and scene_previews. You can list or read finished videos with GET /v1/avatar-videos and GET /v1/avatar-videos/{id}. Store the job id and the video id together so a billing line can be traced back to a creative.