Por qué Grok marca una imagen como moderated: política, límites y alternativas

Distingue el rechazo por política del límite de uso, aprende a diagnosticar cada caso y decide cuándo enviar el trabajo de imagen a otro modelo.

Conclusión principalTrata moderated como un estado observable del producto, no como una regla que hay que adivinar reescribiendo el prompt una y otra vez.

Respuesta rápida

Moderated significa que una política de contenido bloqueó esa petición concreta. No es que se haya agotado tu cuota ni que el servicio esté caído. Distingue primero cuatro estados en la respuesta —rechazo por política, límite de peticiones, cuota agotada y fallo del modelo— y solo después decide si cambias la entrada, esperas a que se reinicie la cuota o envías el trabajo a un modelo de imagen que sí permita ese contenido.

Empieza por la pregunta que hay detrás de la búsqueda

Cuando una imagen de Grok aparece como moderated, el usuario ve un único resultado, pero el equipo de producto tiene delante varias causas posibles: el texto del prompt, una imagen de referencia, el riesgo de usar a una persona real, reglas por región, el estado de la cuenta o un cambio de política de la plataforma. La peor reacción es etiquetar cualquier fallo como «el modelo no lo soporta» o dejar que el usuario reintente sin un mensaje de error estable.

Cómo evaluarlo más allá de una demo

Registra el request ID, la categoría de política, el estado HTTP y el código de error del proveedor, sin guardar entradas sensibles en los logs normales.
Separa en mensajes distintos el rechazo por política, el límite de peticiones, la cuota agotada y el fallo del modelo.
No prometas que un proveedor «nunca filtra»: las políticas, los modelos y las reglas por región cambian.
Ofrece una ruta alternativa permitida, pero mantén las comprobaciones de edad, consentimiento y derechos.
Usa solo la política oficial vigente y el contrato como referencia, y anota la fecha de revisión: una captura de prensa o una anécdota de foro no son las condiciones actuales.
Mantén una política de producto que puede ser más estricta que la del proveedor: que el modelo lo permita no significa que tu producto deba permitirlo.
Mantén un conjunto fijo de regresión con casos de permitir, denegar y escalar a revisión humana, y vuelve a ejecutarlo tras cada cambio de modelo o de política.

Opciones de ModelRush para este trabajo

En ModelRush, Grok 4.6 es una ruta de texto y agentes: no es un endpoint de generación de imágenes y no devuelve ninguna imagen.
Para un flujo abierto de texto a imagen, usa Z-Image Spicy y guarda el ID del modelo y el resultado de la revisión en el mismo registro de petición.
Para modificar una imagen que ya existe, usa Qwen Image Edit Spicy en lugar de disfrazar la edición como otra generación desde texto.

Un flujo de producción reproducible

Convierte moderated en un estado explícito. La pasarela comprueba la elegibilidad de la cuenta y los derechos antes de enviar nada al proveedor. Cuando el proveedor rechaza la petición, guarda un motivo normalizado y explica el siguiente paso en lugar de esquivarlo automáticamente. Muestra una ruta de imagen alternativa de ModelRush solo cuando el contenido está permitido y el fallo tiene que ver con capacidad o disponibilidad. Reutiliza una clave de idempotencia de negocio en los reintentos para que el usuario no pague dos veces por el mismo trabajo.

El registro de enrutamiento guarda policy_version y provider_policy_checked_at junto a la petición. Después de un cambio de modelo o de política, pausa las rutas sensibles y vuelve a ejecutar el conjunto de seguridad fijo antes de reabrirlas. Cuando la regla del proveedor y la del producto no coinciden, manda la del producto y el motivo del rechazo queda auditable. Ya en producción, vigila tres números: la tasa de aciertos de la regresión de políticas, la distribución de contenido que el proveedor permite pero tu producto rechaza, y el tiempo que pasa entre un cambio de política y su aplicación real.

Preguntas frecuentes

¿Moderated significa que se me acabó la cuota diaria de Grok?

No necesariamente. La cuota, el límite de peticiones y la política de contenido son estados distintos y hay que diagnosticarlos por separado a partir de la respuesta y del estado de la cuenta.

¿Cambiar de modelo lo resuelve automáticamente?

Solo si la petición está permitida y el problema es realmente de capacidad o disponibilidad. El enrutamiento nunca debe usarse para esquivar controles de abuso grave.

¿Debe la aplicación mostrar el error original del proveedor?

Guarda el error original a nivel interno para diagnosticar, pero muestra al usuario una explicación estable y accionable que no revele de más sobre la política interna.

¿Qué diferencia hay entre moderación y límite de peticiones?

La moderación afecta al contenido de esa petición: solo pasa si cambias la entrada o usas un modelo que lo permita. El límite de peticiones afecta a la frecuencia o a la cuota: solo se recupera esperando a que se reinicie la ventana o bajando la concurrencia. Deben devolver códigos de error y mensajes distintos.

Si el modelo lo permite, ¿mi producto también debería permitirlo?

No necesariamente. El canal de distribución, la edad de los usuarios, la legislación local y el riesgo de marca son responsabilidad tuya. Tu política puede ser más estricta que la del modelo, y el motivo del rechazo debe quedar registrado.

Revisa la política de uso aceptable y el catálogo de modelos de imagen, y diseña los estados de política junto con las capacidades del modelo en lugar de dejar que el usuario adivine.