El mensaje “The request failed because the input image may contain a real person” corresponde en ModelArk al HTTP 400 InputImageSensitiveContentDetected.PrivacyInformation. Es un rechazo de la imagen de entrada, no un fallo del prompt, de la red o de la cola. Reenviar la misma foto, añadir grano, recortar el rostro o buscar un proveedor “sin censura” no repara la causa. Hay que cambiar de ruta: salida confiable de la misma cuenta, personaje digital predefinido, retrato real autorizado mediante asset://, o detención.
Respuesta en 30 segundos
- Guarda el error exacto, Request ID, modelo, ruta, rol de la entrada y hora.
- Decide si necesitas una identidad real concreta. Si no, usa un personaje ficticio o predefinido.
- Si el archivo es una salida original reciente de la misma cuenta ModelArk, comprueba si cumple la regla de salida confiable (trusted output).
- Si necesitas a una persona concreta y tienes autorización, usa el flujo Real Human de tu cuenta y espera a que el Asset ID esté utilizable.
- Si faltan derechos, se busca suplantar a alguien o la ruta no admite assets verificados, detén el trabajo.
No hay un prompt mágico que convierta un retrato sin verificar en un asset autorizado.
El error dice “puede contener”, no “hemos probado quién es”
La tabla oficial de errores de ModelArk publica el código, el HTTP 400 y el texto exacto. El verbo may marca una clasificación de riesgo: el sistema cree que la imagen puede representar a una persona real. No certifica la identidad, no decide si el consentimiento es válido y no demuestra que el retrato no sea sintético.
Por eso una cara creada por otra IA, si parece fotográfica, también puede ser rechazada. El arreglo seguro para un personaje realmente ficticio es escoger una dirección visual inequívocamente no identificable o una ruta documentada para ese tipo de asset. Convertir la foto de una persona concreta en boceto, collage o imagen con ruido para que el detector deje de verla sigue apuntando a esa persona y puede ser evasión. La política GenAI de BytePlus prohíbe sortear los mecanismos de seguridad.
Matriz de decisión: sujeto, procedencia y ruta
| Material | Ruta que debes comprobar | Resultado esperado |
|---|---|---|
| Personaje ficticio no identificable | image_url ordinario o personaje predefinido | Un envío; si hay falso positivo, cambia el asset o escala con el Request ID |
| Salida original y reciente de la misma cuenta ModelArk | Ruta de salida confiable | Solo si sigue original, es elegible y está dentro de la ventana de 30 días |
| Persona privada autorizada | Real Human asset workflow | Verificación, estado utilizable y asset://<asset_id> |
| Figura pública, permiso incierto o uso de suplantación | Ninguna ruta de producción | Detener; no cambiar de proveedor para intentar pasar |
La capacidad del modelo para representar seres humanos, la estructura técnica del API, el estado del asset y los derechos son cuatro preguntas distintas.
image_url acepta imágenes, pero no concede elegibilidad
El API de creación de tareas de vídeo permite enviar URL públicas o Base64 dentro de content[].type="image_url", con roles como first_frame, last_frame o reference_image. Ese contrato explica cómo transportar la imagen; no promete que cualquier rostro real supere el filtro.
En el flujo de retrato autorizado, la estructura externa puede seguir usando image_url, pero el valor cambia:
json{ "type": "image_url", "image_url": { "url": "asset://asset-EXAMPLE" }, "role": "reference_image" }
asset:// referencia un activo ya creado y validado en la biblioteca correspondiente. No es una URL que puedas inventar ni el resultado automático de subir una foto por HTTP.
Las tres rutas oficiales que sí hay que distinguir
Salida confiable de la misma cuenta
El tutorial actual de Seedance 2.0 documenta algunas salidas de ModelArk con rostro que pueden reutilizarse como entradas confiables. Deben proceder de la misma cuenta, conservar el archivo original y seguir dentro de la ventana documentada de 30 días. Comprimir, editar, reenviar o cambiar de cuenta puede romper la señal de confianza. Además, que la entrada sea confiable no garantiza que el vídeo final pase la moderación.
Personaje digital predefinido
Si tu historia no requiere la identidad de una persona concreta, la biblioteca de personajes digitales evita transformar una foto privada en problema de identidad. Comprueba las condiciones del asset elegido: poder seleccionarlo no equivale por sí solo a tener licencia universal para cualquier uso externo o comercial.
Persona real autorizada
La documentación de assets de personas reales describe autorización del sujeto, comprobación de identidad y presencia (liveness), subida de material y consistencia facial. Tras la verificación, el Group ID o Asset Group ID identifica al sujeto autorizado; cada imagen o vídeo aceptado recibe su propio Asset ID. La solicitud usa el segundo mediante asset://<asset_id>: disponer de un Group ID no vuelve utilizables automáticamente todos los archivos del sujeto.
La guía actual de la biblioteca privada de personas reales sigue marcada como invited users only. Por tanto, no se puede prometer esta función a todas las cuentas de España o del EEE. La disponibilidad depende de la cuenta, la región y el acceso concedido; que un asset aparezca en una lista tampoco prueba que su estado permita generar.
El consentimiento no sustituye la verificación técnica
Tener permiso es imprescindible para una persona identificable, pero no activa una función en tu cuenta ni crea un Asset ID. Antes de producir, deben pasar dos puertas independientes:
- derechos y finalidad: consentimiento aplicable, uso declarado, distribución y revocación;
- aceptación técnica y de seguridad: ruta compatible, asset utilizable y moderación de entrada y salida.
Una aceptación técnica tampoco concede derechos. Evita usos de suplantación, publicidad engañosa, contenido íntimo sin consentimiento, difamación o casos con menores que requieran una revisión más estricta. Para figuras públicas no existe una excepción general que permita copiar su apariencia.
Cómo escalar un posible falso positivo
No difundas el retrato en logs generales para demostrar que “es IA”. Prepara un paquete mínimo:
- model ID y ruta exactos;
- URL, Base64 o
asset://, y rol de la entrada; - error code, Request ID y timestamp;
- procedencia: generador externo, salida confiable o asset verificado;
- estado de autorización, sin adjuntar la biometría salvo en un canal oficial seguro;
- disponibilidad del Real Human workflow en esa cuenta.
Un gateway puede prefiltrar, transmitir el 400 del upstream, cambiar el texto o devolver primero un task ID y marcarlo después como failed. Sin request/response y task details no se puede atribuir la decisión a la capa correcta.
Cuándo reintentar y cuándo parar
Reintenta una vez solo cuando haya cambiado la condición:
- sustituiste el material por un personaje realmente ficticio y no identificable;
- confirmaste una salida confiable original, de la misma cuenta y no caducada;
- el Asset ID autorizado ya tiene estado utilizable;
- la ruta documenta soporte Real Human, no solo image-to-video genérico.
No automatices reintentos para rechazos de privacidad o contenido. No reescribas el prompt para crear un “parecido cercano”. Y no prometas que el mismo asset funcionará en todos los wrappers.
La mecánica general de envío, consulta de estado y descarga está en la guía de Seedance 2.0 API. Después de resolver identidad y assets, consulta la comparativa de proveedores Seedance para verificar capacidades de la ruta. Los fallos de red, cuota o generación que no son de rostro pertenecen al diagnóstico general de Seedance 2.0.