Por qué se bloqueó mi render: el error de política de contenido

Pulsaste Generar y, en lugar de un clip, recibiste una frase: The engine declined this prompt. Rephrase it and retry — you have not been charged. (el motor rechazó este prompt; reformúlalo y vuelve a intentarlo, no se te ha cobrado nada). Es un mensaje corto y no te dice en cuál de cuatro situaciones bastante distintas estás. Este artículo es ese párrafo que falta, sin dramas.

Qué es exactamente el error

Un bloqueo tiene un solo código, content_blocked, y te llega con la misma forma desde las dos superficies que llaman a un motor de renderizado: imágenes y video.

En imágenes, la llamada responde HTTP 422 con el sobre de error estándar:

{
  "error": {
    "message": "The engine declined this prompt. Rephrase it and retry — you have not been charged.",
    "type": "invalid_request_error",
    "code": "content_blocked"
  }
}

El video es asíncrono, así que el bloqueo llega cuando consultas el estado del trabajo, no cuando lo envías:

{
  "id": "…",
  "object": "video.generation",
  "status": "failed",
  "model": "seedance-1-pro",
  "duration": "5s",
  "error": { "type": "invalid_request_error", "code": "content_blocked" },
  "usage": { "credits_spent": 0, "credits_remaining": 4820 }
}

Fíjate en el type. Un bloqueo es un invalid_request_error, una afirmación sobre la solicitud, mientras que un motor que lo intentó y falló devuelve upstream_error. Ese único campo es la forma más rápida de distinguir un rechazo de una mala tirada, y un webhook video.generation.failed lleva el mismo código si estás escuchando uno.

Nunca se cobra, pero puedes ver dos filas

credits_spent es cero y tu saldo termina donde empezó. Conviene conocer el mecanismo que hay debajo, porque sorprende a quien lee su registro de uso.

El video cobra al enviar y reembolsa cuando el trabajo termina mal, así que un clip bloqueado produce una fila de cargo y una fila de reembolso negativa equivalente en el mismo minuto. Se compensan a cero. Las imágenes cobran el lote por adelantado y reembolsan cada toma que vuelve vacía. En ambos casos solo pagas por trabajo entregado, pero el registro cuenta la secuencia tal cual en lugar de ocultarla. Tienes una guía completa en cómo leer tu registro de uso.

Los tres límites que nunca se mueven

Algunos prompts se rechazan en todo eroq, de forma permanente, y ninguna reescritura lo cambia. Están por escrito en la política de uso aceptable y son pocos.

Cualquier contenido que involucre a menores, ya sean reales, ficticios, estilizados o implícitos. Personas reales identificables sin su consentimiento, lo que incluye los deepfakes y la suplantación de figuras públicas. Cualquier cosa ilegal, además del acoso. Aquí la aplicación es a nivel de cuenta, no solo de solicitud, así que no es un filtro que se pueda esquivar.

Si tu prompt está en este terreno, el bloqueo es el resultado correcto y para ti el artículo termina aquí. Todo lo que sigue trata de los otros casos, que son mucho más comunes.

Dónde está de verdad el muro en cada superficie

Este es el caso de la mayoría, y es un problema de enrutamiento más que de política.

Todos los motores de video menos uno los modera su propio proveedor, antes de que intervenga eroq: Seedance 2.5, Seedance 1.0 Pro y Lite, Kling, Hailuo y Veo aplican las reglas de su proveedor, y el rechazo es suyo. Motion One es el motor de video sin censura propio de eroq, está disponible en todas las cuentas, incluido el nivel gratuito, y es la respuesta siempre que el problema sea que un proveedor rechazó tu escena y no que la escena esté prohibida.

El chat y la voz no tienen esa división: funcionan con los modelos propios de eroq, sin censura dentro de la misma política escrita. En imágenes, Eroq Uncensored y Anima son los modelos sin censura, mientras que Flash Image y Flux Image son motores de terceros moderados por su proveedor, igual que los de video. Las imágenes siguen pasando por un motor que puede rechazar un prompt concreto, así que content_blocked es algo con lo que te toparás de vez en cuando, y cuando pase será uno de los tres límites estrictos de arriba o un falso positivo por una palabra. El chat y la voz no tienen un filtro de contenido de este tipo en el motor; los límites estrictos se comprueban en tu texto antes de que se ejecute nada y se aplican a nivel de cuenta.

Dicho claro: una escena dentro de la política de eroq pero fuera de las reglas del proveedor de Kling no es un fallo de política, es un plano apuntado al motor equivocado, y por mucho que lo reformules no se va a mover. Cambia de motor. Tienes una visión más amplia de esa frontera en IA sin censura.

Distinguir un rechazo de un fallo

Cuatro estados se parecen en la interfaz y se comportan de forma completamente distinta. Por qué fallan los renders de video con IA cubre toda la clasificación; esta es la versión corta para el triaje:

• content_blocked: una decisión de contenido. Reintentar la reproduce exactamente igual. Reescribe o cambia de motor.
• generation_failed: el motor aceptó el trabajo y no devolvió nada. Esto es el azar. Reintenta.
• generation_timeout: el render nunca volvió. Un trabajo atascado más de diez minutos se marca como fallido y se reembolsa la primera vez que consultas su estado.
• Los rechazos previos, que no son bloqueos en absoluto: 403 plan_required (el motor está por encima de tu plan), 503 model_unavailable (ese motor todavía no está abierto al público), 402 insufficient_credits (saldo vacío), 403 role_forbidden (tu rol en el espacio de trabajo no puede gastar créditos) y 429 rate_limit_exceeded (con una cabecera Retry-After que te dice cuántos segundos esperar). Todos se deciden antes de poner el trabajo en cola, así que no se cobra nada y no hay nada que reembolsar.

La lógica de reintentos que vale la pena escribir cabe en una línea: nunca reintentes content_blocked, reintenta el fallo y el timeout, y pasa todo lo demás a una persona.

Cuando es un falso positivo

El caso molesto: escribiste algo inocente y una palabra hizo saltar un filtro. Los filtros leen sustantivos, no intenciones, así que la solución es describir la imagen en lugar del hecho: nombra el plano, la luz y la ropa en vez del acto, y quita el nombre de cualquier persona real. El método completo de reescritura está en el artículo enlazado arriba y vale la pena guardarlo en favoritos.

Un diagnóstico más que no cuesta nada. Ejecuta el mismo prompt en Motion One. Si allí se renderiza y en un motor premium se bloqueó, has aprendido que el prompt está bien y que el proveedor es estricto. Si Motion One también lo bloquea, estás mucho más cerca de uno de los tres límites estrictos de lo que pensabas.

Abre el estudio de video y vuelve a probar el plano en el motor adecuado.

Preguntas frecuentes

¿Me cobran cuando se bloquea un render?

No. El trabajo bloqueado nunca te cuesta créditos: el video cobra al enviarse y reembolsa de inmediato cuando el trabajo vuelve bloqueado, las imágenes reembolsan cada toma vacía y la respuesta indica credits_spent en cero. Si tu saldo se movió, busca la fila negativa equivalente en el registro de solicitudes antes de pensar otra cosa.

¿Por qué el mismo prompt se renderiza en un motor y no en otro?

Porque todos los motores de video salvo Motion One los modera su proveedor de origen, con las reglas de ese proveedor. Motion One es el motor sin censura propio de eroq, dentro de la política escrita, así que una escena que un proveedor rechaza puede renderizarse ahí. El chat y la voz funcionan con los modelos propios de eroq, y en imágenes Eroq Uncensored y Anima son las opciones sin censura, así que la división importa sobre todo en video.

¿Un prompt bloqueado hace que marquen mi cuenta?

Los límites estrictos (menores, personas reales identificables, cualquier cosa ilegal) se aplican a nivel de cuenta y no por solicitud, así que esos sí importan. Un falso positivo corriente por una palabra clave no es eso, y reescribir y reintentar es parte normal del uso de la herramienta. Si no tienes claro de qué lado de la línea está un proyecto, lee primero la política de uso aceptable.

¿Cómo gestiono los bloqueos desde el código?

Ramifica según el código de error, no según el texto del mensaje. content_blocked llega como invalid_request_error y nunca debe reintentarse, mientras que generation_failed y generation_timeout llegan como upstream_error y merecen dos intentos. Todo lo demás (restricciones de plan, saldos vacíos, límites de solicitudes) es un problema de configuración que necesita a una persona, no un bucle.