As of June 12, 2026, a Seedance 2.0 human-face job is a route and consent decision before it is a prompt decision. Fictional human characters can be ordinary creative work; your own face or an authorized actor's face needs a verified real-human workflow; public-figure, impersonation, and non-consensual likeness requests should stop before prompt writing. Start with the face request itself: classify it as create, verify, switch route, handle rejection, or stop before uploading portrait assets.
| Face request | First verdict | Safe next step |
|---|---|---|
| A fictional person or generic human-looking character | Create | Keep the prompt generic and avoid implying a real person's identity. |
| Your own identifiable face | Verify | Use a route that supports real-person verification and keep the verification record. |
| An actor, employee, client, or talent | Verify with consent | Get authorization first, then use a real-human asset or provider-owned verified route. |
| A rejected face reference | Reclassify | Check whether the face is generic, private, public, authorized, or unsupported by that route. |
| A public figure, celebrity, or non-consensual likeness | Stop | Do not rewrite the request into a near-match or filter-evasion prompt. |
| A "how do I bypass it?" request | Stop | Change the job to an allowed creative or verified workflow instead of evasion. |
What "human face" means in Seedance 2.0
Seedance 2.0 is not face-blind. The ByteDance Seed model page describes Seedance 2.0 as a multimodal audio-video generation model that can use text, image, audio, and video references. The official launch post also frames the model around subject consistency, camera language, motion, editing, and reference control. That supports normal creative work with human-looking subjects.
The boundary changes when the face is identifiable. A generic character prompt such as "a documentary-style shot of a young doctor in a hospital corridor" is different from uploading a real employee's portrait, a client's selfie, a celebrity face, or a reference image that is meant to preserve a particular person's likeness. The first case is a creative direction. The second case is a rights, consent, verification, and route-owner problem.
That distinction matters because "supports image references" is not the same as "accepts any real face." A route can accept generic reference images and still reject a portrait. A provider can advertise verified faces while the public developer route uses a different policy. A model can generate realistic human-looking clips while still blocking public-figure likeness or impersonation requests. Treat face/likeness as its own branch before you decide which prompt, API, or provider to use.
Current legitimate routes for real-person faces
For a real, identifiable person, the strongest current pattern is not a prompt trick. It is a verified route with an owner who can explain authorization, verification, asset status, and acceptable use.
| Route | What it can support | What it does not prove |
|---|---|---|
| BytePlus real-human asset library | First-party real-human asset handling for Seedance 2.0, including actor authorization, verification, uploaded materials, and Asset ID use. | It does not mean every account, region, or route can use any face without setup. |
| ComfyUI Seedance 2.0 Real Human | A partner-node workflow that documents one-time ByteDance liveness verification, verified assets, Group ID or Asset ID usage, and real-person video workflows. | It proves the ComfyUI route, not a universal public-API bypass. |
| Provider-owned verified-face route, such as HeyGen's claim | A provider may wrap Seedance with its own consent and identity infrastructure. | Provider marketing is not first-party proof for every Seedance route. |
| Ordinary Seedance creative generation | Human-looking fictional people and non-identifiable subjects. | It is not a real-person likeness authorization system. |
BytePlus documents a real-human asset library where an account creates an authorization invitation, the actor completes confirmation and real-person verification, materials are uploaded and accepted, and the resulting asset can be used in Model Playground or API workflows through an Asset ID. That is the most useful mental model for production: the face becomes a verified asset with a route owner, not a loose portrait file that any prompt can reuse.
ComfyUI's Seedance 2.0 Real Human documentation makes the same point from the workflow side. It describes real-person generation with one-time ByteDance liveness verification and asset handling. If you use that route, write the route name and its prerequisites into your workflow notes. Do not generalize the ComfyUI path into a claim that all public Seedance access accepts real faces.
HeyGen is useful as a provider example, but only as a provider example. Its Seedance pages claim verified human-face support through HeyGen's consent and identity infrastructure and distinguish that from public API behavior. That tells you why readers are seeing "Seedance real face" claims in the market. It does not remove the need to read HeyGen's current terms, data rules, verification flow, billing, support path, and account eligibility before using that route with real people.
How BytePlus real-human assets work
If you are planning a real-person workflow, treat the BytePlus pattern as an operational checklist. The important sequence is authorization first, verification second, asset state third, generation fourth.
- Create the authorization invitation from the route owner.
- Have the actor or rights holder review the purpose and complete the required authorization steps.
- Complete real-person verification, such as liveness checks, before the face is treated as usable.
- Upload and review the real-human material according to the platform requirements.
- Use the accepted Asset ID only in the route and purpose it was authorized for.
- Keep a record of who authorized the likeness, when, for which use, and under which account or route.
This sequence is slower than uploading a selfie and hoping the prompt passes. That is the point. It gives the production team a record of consent, it gives the platform a verification boundary, and it gives the developer a concrete asset status to test. If a clip fails later, you can debug the route, asset state, and policy response instead of guessing whether the face was too famous, too similar, insufficiently verified, or unsupported by the chosen provider.
Do not collapse Asset ID use into a generic "reference image" instruction. A verified real-human asset is a governed input. If your workflow stores prompts, generated clips, source portraits, or asset IDs, also decide who can access them, how long they are retained, and how support or deletion requests are handled. Those decisions belong in the workflow before customer, employee, or actor material enters the system.
What to do when a face reference is rejected
A rejected face reference is not an invitation to hide the face from filters. It is a signal to classify the job again. The safest recovery path is to ask what kind of face you are trying to use and which route owns that use.
Use this order:
| If the rejected input is... | Do this | Do not do this |
|---|---|---|
| A generic character sketch or non-identifiable mood reference | Simplify the prompt and remove likeness-like wording. | Add a real person's name or imply identity. |
| Your own face | Move to a verified real-human route and complete the required checks. | Keep reuploading edited selfies until one passes. |
| An actor or customer | Confirm written consent, route eligibility, and verification state. | Treat private permission in chat as enough for platform use. |
| A public figure or celebrity | Stop or change to a clearly fictional, non-identifiable subject. | Ask for a lookalike, near-match, or "same vibe" face. |
| A provider route that claims verified faces | Read that provider's current verification, data, refund, and support terms. | Assume the same claim applies to BytePlus, ComfyUI, or another provider. |
| A repeated rejection with no clear reason | Use non-sensitive test assets and contact the route owner if available. | Rewrite prompts to evade safety filters. |
The practical debugging record should include the route, account, input type, whether the person is identifiable, whether consent and verification are complete, the exact rejection message if one appears, and the safe fallback you chose. That record helps you distinguish a normal unsupported input from a broken route or a missing account permission.
Public figures and bypass requests should stop
BytePlus documents a content pre-filter that can block image, voice, or video outputs resembling public figures, with the stated aim of reducing impersonation, fraud, and deceptive deepfakes. The same FAQ is careful not to present itself as a complete public-figure authority. That means a non-triggered filter is not permission, and a triggered filter is not a prompt-engineering challenge.
BytePlus also publishes Video Generation Model Services terms that require acceptable use and prohibit bypassing or circumventing safety filters. For production, that becomes a simple stop rule: do not teach face-obfuscation, celebrity near-match prompts, "same face but unnamed" wording, or retry tactics designed to get around a route's safety boundary.
If the business request is legitimate, reframe it. Use a fictional actor, a licensed talent, a verified employee, or a non-identifiable character. If the request depends on making the model output a public person, a customer who did not authorize the use, or a confusing near-match, the right production answer is no.
Developer workflow and production handoff
Developers should treat real-human face generation as an auditable workflow, not a single API call. Even if the eventual implementation is simple, the acceptance criteria are not.
Before you ship, answer these questions:
| Check | Production question | Evidence to keep |
|---|---|---|
| Route owner | Which platform or provider is responsible for the face workflow? | URL, account, provider terms, support path. |
| Consent record | Who authorized the likeness and for what purpose? | Authorization record, actor or rights-holder confirmation, date. |
| Verification state | Is the real-human asset verified or merely uploaded? | Asset status, Group ID or Asset ID where applicable, route notes. |
| Input handling | What happens to portraits, prompts, and generated clips? | Retention rule, access control, deletion path. |
| Test case | Did you test with non-sensitive material before real assets? | Test prompt, expected output, failure behavior. |
| Rejection handling | What is the safe fallback when a face is rejected? | Classification path, support ticket, route switch, or stop decision. |
| Billing and retries | Who pays for retries and failed attempts? | Route billing notes and task usage where available. |
| Stop rule | Which requests are never accepted? | Public-figure, impersonation, no-consent, and filter-evasion rules. |
Keep implementation details in their own lane. If the next task is submit, poll, retrieve, or cancel video tasks, use the current BytePlus developer docs and your account console. If the next task is provider selection, compare route ownership, terms, data handling, support, and billing separately. If the next task is cost, do not rely on a face/likeness workflow to settle pricing; price rows, free trials, and resource packs change too quickly to borrow from memory.
For general access and route hygiene, use the published Seedance 2.0 access guide. For version readiness, keep the separate Seedance 2.1 vs Seedance 2.0 guide in its own lane. Keep the human-face decision focused on likeness, consent, verification, rejection, and stop rules.
A safe first test
If you are unsure which route applies, start with a non-sensitive test that does not include a real person's face. Use a fictional character prompt, a synthetic reference, or an approved internal test asset. Confirm that the chosen route can generate the kind of motion, framing, and output you need before introducing a verified real-human asset.
Then run the smallest real-person test your route allows. Use one verified asset, one clear use case, and one short output. Record the route, asset state, prompt, settings, result, rejection behavior, and support path. Do not scale to customer, actor, or employee material until you know how the route behaves when it succeeds, fails, and refuses.
This sounds conservative, but it saves time. The most expensive real-face failures are not always generation failures. They are unclear consent, wrong provider assumptions, missing support, repeated rejected uploads, and assets that no one can confidently delete or audit later.
FAQ
Can Seedance 2.0 use my own face?
It can be part of own-face workflows when the route supports verified real-person use. Do not treat a selfie upload as enough. Use a route with consent and verification, then keep the verification and asset-status record.
Can I use an employee, actor, or client face?
Only with clear authorization and a route that supports real-human assets or verified likeness use. For production, keep the consent record, purpose, route owner, asset status, and support path together.
Does ComfyUI make real-human Seedance 2.0 possible?
ComfyUI documents a Seedance 2.0 Real Human route with ByteDance liveness verification and asset handling. That is a specific partner-node workflow. It should not be rewritten as a universal public API claim.
Does HeyGen prove that all Seedance routes allow real faces?
No. HeyGen can be a provider-owned verified-face route, and its pages make their own claims about consent and identity infrastructure. Those claims do not automatically apply to BytePlus, ComfyUI, another provider, or a raw public API route.
Why was my face reference rejected?
Common causes include identifiable real-person input without the right verification route, public-figure similarity, missing consent, route-specific restrictions, or unsupported reference handling. Classify the face and route first, then decide whether to verify, switch route, simplify the creative prompt, or stop.
Can I use a celebrity or public figure face if I avoid the name?
No. Avoiding the name does not make a likeness request safe. Public-figure, celebrity, impersonation, and confusing near-match jobs should stop or be replaced with a clearly fictional, non-identifiable character.
Is there a prompt that bypasses the face restriction?
That is the wrong workflow. A rejection should lead to classification, consent, verification, provider review, or a stop decision. It should not lead to filter-evasion prompts.
Should I use Seedance 2.1 instead for faces?
Do not switch versions just to avoid the real-person route decision. Version readiness is a separate question. Check route-owner documentation and same-task tests before changing model versions, and use a separate Seedance version comparison when the question is really about 2.1 versus 2.0.
