Al 12 de junio de 2026, una solicitud de rostro en Seedance 2.0 se decide por ruta, consentimiento y verificación antes de escribir el prompt. Un personaje ficticio puede ser una creación normal. Tu propia cara, la de un actor, una empleada, un cliente o una persona contratada necesita una ruta que acepte uso real-humano y deje evidencia. Una celebridad, una figura pública, una cara parecida sin permiso o una petición para saltarse la detección facial debe detenerse antes de subir imágenes.
| Solicitud de rostro | Primer veredicto | Siguiente paso seguro |
|---|---|---|
| Persona ficticia, modelo genérico o personaje no identificable | Crear | Mantén la descripción como personaje y evita insinuar una identidad real. |
| Tu propia cara identificable | Verificar | Usa una ruta con verificación de persona real y conserva el registro. |
| Actor, empleada, cliente o talento contratado | Verificar con consentimiento | Obtén autorización para el uso concreto y trabaja con un asset real-humano o una ruta verificada. |
| Referencia de rostro rechazada | Reclasificar | Decide si es genérica, privada, autorizada, pública o no admitida por esa ruta. |
| Celebridad, figura pública o parecido sin consentimiento | Detener | No conviertas la petición en una cara parecida, sin nombre o más difícil de detectar. |
| Petición para saltarse la detección | Detener | Cambia el trabajo a un personaje permitido o a un flujo verificado. |
Qué significa trabajar con un rostro en Seedance 2.0
Seedance 2.0 no es un modelo incapaz de crear personas. La página de ByteDance Seed presenta Seedance 2.0 como un modelo multimodal de generación audiovisual que puede usar texto, imagen, audio y video como referencias. El lanzamiento oficial también habla de consistencia del sujeto, lenguaje de cámara, movimiento, ritmo y control por referencia. Esa capacidad permite escenas con personas visualmente creíbles: una médica ficticia en un hospital, un entrevistado inventado, un corredor genérico o un personaje de campaña que no apunta a nadie real.
La frontera aparece cuando el rostro puede vincularse con una persona concreta. Una foto de una empleada, un selfie de un cliente, una actriz contratada, una cara parecida a una celebridad o un retrato tomado de redes no son simples referencias de estilo. Entran en juego consentimiento, derechos de imagen, finalidad, verificación, estado del asset, conservación de datos, soporte y retirada. Confundir "acepta referencias de imagen" con "acepta cualquier cara real" crea errores de producto y de cumplimiento.
Por eso la primera pregunta no es si el prompt está bien redactado. La primera pregunta es de quién es la cara, para qué se usará, quién autorizó ese uso, qué ruta puede verificarlo y qué debe pasar si el sistema rechaza la entrada. Una plataforma puede aceptar imágenes de referencia y aun así bloquear un retrato. Un proveedor puede ofrecer rostros verificados dentro de su propia infraestructura sin que esa promesa se traslade a BytePlus, ComfyUI u otra API. La capacidad visual del modelo y el permiso para usar una identidad son problemas separados.
Rutas que pueden tener sentido para caras reales
Cuando el rostro identifica a una persona real, lo importante no es encontrar un truco de prompt. Necesitas una ruta con propietario claro: quién gestiona autorización, verificación, estado del asset, finalidad permitida y soporte si algo falla.
| Ruta | Qué puede admitir | Qué no demuestra |
|---|---|---|
| BytePlus real-human asset library | Manejo de assets de persona real para Seedance 2.0, con invitación de autorización, verificación, material aprobado y uso mediante Asset ID. | No significa que todas las cuentas, regiones o entradas acepten cualquier cara sin configuración. |
| ComfyUI Seedance 2.0 Real Human | Flujo de partner node con verificación de vida de ByteDance, Group ID o Asset ID y generación con persona real. | Demuestra esa ruta de ComfyUI, no un atajo universal para la API pública. |
| Ruta verificada de un proveedor, como HeyGen | Un proveedor puede envolver Seedance con su propio consentimiento, identidad y tratamiento de datos. | La promesa del proveedor no prueba el comportamiento de BytePlus, ComfyUI ni otra ruta. |
| Generación creativa ordinaria de Seedance | Personas ficticias, sujetos genéricos y personajes no identificables. | No es un sistema de autorización para usar el parecido de una persona real. |
La documentación de BytePlus real-human asset muestra una secuencia útil para producción: la cuenta crea una invitación de autorización, la persona o titular revisa el uso, completa verificación de persona real, se sube material, se obtiene estado aceptado y el Asset ID se usa en Model Playground o en flujos de generación de video. La cara deja de ser un archivo suelto y pasa a ser una entrada gobernada por estado, propósito y ruta.
La documentación de ComfyUI Seedance 2.0 Real Human llega a la misma conclusión desde el flujo de trabajo. Habla de verificación única con ByteDance, manejo de assets y uso de Group ID o Asset ID. Si eliges ComfyUI, registra el nombre de la ruta, sus requisitos, el ID usado, la cuenta responsable y el soporte disponible. No conviertas esa ruta en una afirmación de que cualquier entrada pública de Seedance acepta fotos reales.
HeyGen sirve como ejemplo de ruta de proveedor. Sus páginas de Seedance afirman que añaden identidad verificada mediante su propia infraestructura de consentimiento y verificación. Eso puede ser útil para un equipo que necesita una solución de identidad integrada, pero sigue siendo un contrato del proveedor. Antes de usarlo con clientes, actores o empleados, revisa sus términos actuales, tratamiento de datos, elegibilidad de cuenta, soporte, facturación y reglas de retirada.
Cómo usar el patrón BytePlus real-human asset
Para producción, el orden correcto es autorización, verificación, estado del asset y generación. Cambiar ese orden transforma una prueba técnica en un riesgo operativo.
- Crea la invitación de autorización desde la cuenta responsable.
- Haz que la persona, representante o titular revise el propósito concreto.
- Completa la verificación de persona real, por ejemplo una comprobación de vida, antes de considerar utilizable el rostro.
- Sube el material según los requisitos de la ruta y espera el estado aprobado.
- Usa el Asset ID aceptado solo en la ruta y finalidad autorizadas.
- Guarda quién autorizó, cuándo, para qué campaña, bajo qué cuenta y con qué soporte.
Ese flujo es más lento que probar un selfie varias veces. La lentitud es parte de la protección. El equipo conserva evidencia de consentimiento, la plataforma mantiene una frontera de verificación y el desarrollador puede depurar por estado de asset en lugar de adivinar si la cara era demasiado parecida a una figura pública, si faltaba permiso, si la cuenta no tenía habilitada la función o si el proveedor no admite ese tipo de referencia.
No trates un Asset ID como si fuera un enlace de imagen. Un asset real-humano aprobado puede aparecer en logs, prompts, videos generados, sistemas de almacenamiento y tickets de soporte. Define quién puede verlo, cuánto tiempo se conserva, cómo se elimina, qué pasa si el titular retira permiso y qué equipo responde a incidencias. Esas reglas deben existir antes de escalar de pruebas internas a materiales de clientes, empleados o talento contratado.
Qué hacer cuando una referencia de rostro es rechazada
Un rechazo no significa que haya que esconder mejor la cara. Significa que la entrada y la ruta no encajan, o que falta una condición de consentimiento, verificación o elegibilidad. Vuelve a clasificar el caso antes de reintentar.
Sigue este orden:
| Entrada rechazada | Acción segura | No hacer |
|---|---|---|
| Boceto de personaje o referencia de ambiente no identificable | Simplifica el prompt y elimina palabras que sugieran identidad real. | Añadir el nombre de una persona real o pedir "la misma cara". |
| Tu propia cara | Mueve el trabajo a una ruta real-humano verificada. | Recortar, difuminar o editar selfies hasta que alguno pase. |
| Actor, cliente, empleada o talento | Confirma autorización escrita, elegibilidad de ruta y estado de verificación. | Usar una aprobación de chat como sustituto de permisos de plataforma. |
| Celebridad o figura pública | Detén la solicitud o cambia a un personaje claramente ficticio. | Pedir una cara parecida, el mismo estilo facial o una aproximación sin nombre. |
| Proveedor que promete caras verificadas | Lee condiciones actuales de verificación, datos, soporte y reembolsos. | Aplicar esa promesa a BytePlus, ComfyUI u otra ruta. |
| Rechazo repetido sin motivo claro | Reproduce con material no sensible y contacta al propietario de ruta si existe. | Buscar prompts para evadir filtros de seguridad. |
El registro mínimo debe guardar ruta, cuenta, tipo de entrada, si la persona es identificable, estado de consentimiento, estado de verificación, mensaje exacto de rechazo, fallback seguro y decisión final. Con eso puedes separar una función no disponible, un asset no aprobado, una cuenta sin permiso, una restricción de política o un fallo de proveedor. Sin ese registro, cada intento nuevo parece un problema de prompt aunque el bloqueo sea de ruta.
Figuras públicas y detección facial: cuándo parar
La FAQ de content pre-filter de BytePlus explica que el sistema puede bloquear salidas parecidas a rostros, voces o videos de figuras públicas para reducir suplantación, fraude y deepfakes engañosos. También deja claro que no es una autoridad completa sobre quién es figura pública. Si el filtro no salta, eso no concede permiso. Si salta, tampoco convierte el caso en un reto de ingeniería de prompts.
Los términos de Video Generation Model Services de BytePlus prohíben eludir o sortear filtros de seguridad. En producción, la regla es directa: no documentes líneas de cuadrícula, obstrucciones faciales, cambios de rasgos, nombres omitidos, caras "parecidas pero no iguales" ni reintentos diseñados para atravesar una barrera de seguridad.
Si la necesidad comercial es legítima, cambia el recurso. Usa una persona ficticia, talento contratado con autorización, una empleada verificada o un personaje no identificable. Si el resultado depende de parecerse a una celebridad, una clienta sin permiso, una figura pública o una cara que pueda causar confusión, la respuesta operativa es no continuar con generación.
Handoff de producción para desarrolladores
El uso de rostros reales debe diseñarse como un flujo auditable. Aunque la implementación final sea enviar tarea, consultar estado y recuperar video, los criterios de aceptación tienen que cubrir permisos, datos, soporte y rechazo.
Antes de lanzar, responde:
| Control | Pregunta de producción | Evidencia que debe quedar |
|---|---|---|
| Propietario de ruta | Qué plataforma o proveedor responde por el flujo de rostro. | URL, cuenta, términos, ruta de soporte. |
| Consentimiento | Quién autorizó el parecido y con qué finalidad. | Registro de autorización, titular, fecha, campaña. |
| Verificación | El asset está verificado o solo fue subido. | Estado del asset, Group ID o Asset ID, notas de ruta. |
| Tratamiento de entrada | Qué pasa con fotos, prompts y videos. | Retención, control de acceso, eliminación. |
| Prueba no sensible | Se probó la ruta antes de usar caras reales. | Prompt de prueba, salida esperada, rechazo esperado. |
| Rechazo | Qué fallback se usa cuando una cara no pasa. | Clasificación, soporte, cambio de ruta o parada. |
| Costes y reintentos | Quién paga intentos fallidos y repeticiones. | Notas de facturación y uso de tarea. |
| Límite de no continuar | Qué solicitudes nunca se aceptan. | Figura pública, suplantación, falta de permiso, evasión. |
En equipos de habla hispana, el briefing suele llegar como "quiero poner mi cara", "usa esta foto de un cliente", "hazlo como este famoso" o "cómo salto la detección facial". Convierte esas frases en cuatro tarjetas antes de tocar la API. La tarjeta de persona dice si es ficticia, propia, empleada, cliente, talento, celebridad o figura pública. La tarjeta de evidencia dice consentimiento, verificación, Asset ID y cuenta. La tarjeta de ruta dice BytePlus, ComfyUI, proveedor o generación ordinaria. La tarjeta de fallo dice mensaje de rechazo, fallback, coste de reintento y motivo de parada.
Cuando entregues el resultado, no envíes solo el video final. Adjunta ruta usada, estado del asset, finalidad autorizada, fecha de generación, respuesta ante rechazos y contacto para eliminación o soporte. Eso evita que la misma cara se reutilice en otra campaña, otro cliente o un proveedor distinto sin volver a comprobar si el permiso original cubre ese uso.
Para acceso general y separación de rutas, consulta cómo acceder a Seedance 2.0. Si la duda real es la versión del modelo, usa la comparación Seedance 2.1 frente a Seedance 2.0. La decisión de rostro debe quedarse en identidad, consentimiento, verificación, rechazo y parada.
Primera prueba segura
Si no sabes qué ruta aplica, empieza sin una cara real. Usa un personaje ficticio, una referencia sintética o un asset interno aprobado. Comprueba movimiento, encuadre, duración, estilo, tiempos de tarea y comportamiento de rechazo sin exponer material personal. Esa prueba no resuelve consentimiento, pero separa los problemas de video de los problemas de identidad.
Después ejecuta la mínima prueba real que permita la ruta: un asset verificado, una finalidad concreta y una salida corta. Registra ruta, estado de asset, prompt, parámetros, resultado, mensaje de rechazo y soporte. No escales a clientes, empleados, actores o campañas pagadas hasta saber cómo responde la ruta cuando acierta, falla y rechaza.
La pérdida cara no siempre es un render fallido. Es tener permiso ambiguo, creer promesas de un proveedor fuera de su ruta, no poder borrar material, repetir subidas rechazadas, no saber quién paga reintentos o no poder explicar por qué una cara se usó en una pieza. Definir la frontera antes cuesta menos que reconstruirla después.
Preguntas frecuentes
¿Puedo usar mi propia cara en Seedance 2.0?
Sí, si la ruta elegida admite uso real-humano verificado. No basta con subir un selfie. Usa un flujo con consentimiento, verificación y estado de asset, y guarda ese registro junto con el resultado.
¿Puedo usar la cara de una empleada, actor o cliente?
Solo con autorización clara y una ruta que soporte assets real-humanos o parecido verificado. En producción, conserva finalidad, titular, estado de verificación, ruta, cuenta y soporte.
¿ComfyUI permite usar cualquier cara real con Seedance 2.0?
No. ComfyUI documenta una ruta específica de Seedance 2.0 Real Human con verificación de vida de ByteDance y manejo de assets. No convierte toda API pública ni todo proveedor en una ruta de caras reales.
¿HeyGen prueba que todas las rutas de Seedance aceptan rostros reales?
No. HeyGen puede ser una ruta de proveedor con identidad verificada, consentimiento y tratamiento propios. Esa afirmación no se transfiere automáticamente a BytePlus, ComfyUI ni otras entradas.
¿Por qué se rechaza mi referencia de rostro?
Puede tratarse de una persona identificable sin ruta de verificación, parecido a figura pública, falta de consentimiento, restricción de cuenta, asset no aprobado o manejo de referencia no soportado. Primero clasifica cara y ruta; después verifica, cambia de ruta, simplifica la creatividad o detén el trabajo.
¿Puedo usar una celebridad si no escribo su nombre?
No. Quitar el nombre no elimina el problema de parecido, suplantación o confusión. Las solicitudes de celebridades, figuras públicas, caras parecidas o usos sin permiso deben detenerse o cambiarse por un personaje ficticio no identificable.
¿Existe un prompt para saltarse la restricción de rostro?
Ese no es un flujo aceptable. Un rechazo debe llevar a clasificación, consentimiento, verificación, revisión del proveedor o parada. No debe convertirse en tácticas para evadir filtros.
¿Conviene cambiar a Seedance 2.1 para caras?
No cambies de versión solo para evitar la decisión sobre persona real. La versión del modelo, la ruta de cuenta, el permiso sobre el parecido y el estado del asset son temas distintos. Verifica la ruta y prueba la misma tarea antes de cambiar de modelo.
