En Nano Banana 2, image safety no nombra un solo interruptor. Dentro del Gemini API hay una capa ajustable de seguridad en el prompt. También hay una capa de respuesta más dura que puede exponer razones visibles como OTHER, PROHIBITED_CONTENT e IMAGE_SAFETY. Y por encima de eso existe otra capa de policy removal dentro de Gemini Apps. Gran parte del debugging sale mal no porque el modelo sea completamente impredecible, sino porque esas tres decisiones se tratan como si fueran un solo filtro.
Si solo te quedas con una regla, que sea esta: BLOCK_NONE es un control estrecho, no un master switch. Puede cambiar cuatro categorías del lado del prompt en el Gemini API. No reescribe las built-in core protections de Google y tampoco explica por qué una tarea puede verse distinta en Gemini Apps y en el API.
La ruta más rápida es identificar primero qué contrato se activó:
- Si el resultado cambia cuando cambias
safetySettings, probablemente sigues en la capa ajustable. - Si el API muestra
SAFETY,OTHER,PROHIBITED_CONTENToIMAGE_SAFETY, léelo como una señal de routing, no como un rechazo genérico. - Si la misma tarea se comporta distinto en Gemini Apps y en Gemini API, trata el app shell como una surface separada, no como un espejo perfecto del API.
Nota de evidencia: este artículo usa documentación oficial del Gemini API, la help page de Gemini Apps, la model card de Gemini 3.1 Flash Image y complaint threads actuales verificados el 3 de abril de 2026. El capture directo de Google fue bloqueado en este entorno, así que las observaciones de búsqueda se apoyan en evidencia fallback en lugar de fingir una captura limpia.
Qué significa realmente image safety en Nano Banana 2
Nano Banana 2 corresponde en el Gemini API al modelo gemini-3.1-flash-image-preview. Google lo posiciona como el modelo de imagen rápido y de mayor throughput. Eso importa porque muchas páginas siguen reciclando lenguaje de seguridad de Nano Banana antiguo o de Nano Banana Pro y presentan el nuevo modelo como "lo mismo, solo que más estricto". Ese shortcut no es fiable.
La mental model más útil es que image safety en Nano Banana 2 puede apuntar al menos a tres contratos diferentes.
El primer contrato es la prompt-side safety system ajustable del Gemini API. Google documenta solo cuatro categorías ajustables: harassment, hate speech, sexually explicit content y dangerous content. Cuando los desarrolladores hablan de safetySettings, normalmente están hablando de esa capa.
El segundo contrato es la capa de block y response más dura del propio API. La schema pública documenta razones como SAFETY, OTHER, PROHIBITED_CONTENT e IMAGE_SAFETY. No son cuatro palabras distintas para el mismo rechazo. Son route signals que te dicen si debes revisar settings, reescribir el prompt, cambiar la tarea o aceptar que ese request no pertenece a esa surface.
El tercer contrato es el product shell de Gemini Apps. La documentación actual de Google muestra generación de imágenes, edición de imágenes subidas, combinación de imágenes y escenarios personalizados con personas, pero al mismo tiempo advierte que las imágenes pueden eliminarse por policy reasons. Por eso Gemini Apps no se debe describir como "el API con una interfaz más bonita". Es otra surface con otro contrato de cara al usuario.
En cuanto separas esos tres contratos, la confusión alrededor de Nano Banana 2 baja mucho. Dejas de preguntar por qué el filter parece random y empiezas a hacer la única pregunta útil: qué layer tomó la decisión esta vez.
Qué pueden cambiar los safety settings y qué no
Uno de los errores más comunes alrededor de Nano Banana 2 es tratar BLOCK_NONE como si fuera el botón de apagado del modelo. La documentación actual del Gemini API no respalda esa lectura.
Lo que sí respalda es una lectura más estrecha y más útil. En el Gemini API, los adjustable safety settings cubren solo cuatro categorías del lado del prompt:
HARASSMENTHATE_SPEECHSEXUALLY_EXPLICITDANGEROUS_CONTENT
Eso significa que BLOCK_NONE sí puede ser la jugada correcta cuando tu request realmente cae en esos configurable thresholds. Pero no es una respuesta universal.
Google también dice claramente que los core harms siguen bloqueándose fuera de esos adjustable settings. Así que si bajas o desactivas los configurable thresholds y el resultado no se mueve en absoluto, la señal fuerte no es "Google seguro esconde otro filtro secreto". La conclusión más defendible es más simple: probablemente nunca estuviste en la capa ajustable.
Esa es una razón por la que muchas discusiones sobre Nano Banana 2 dan vueltas. Una persona dice "ya puse todo en BLOCK_NONE". Otra responde "entonces Google tiene un hidden extra filter". La conclusión más sólida es otra: el request seguramente ya salió de la configurable layer y entró en un contrato que BLOCK_NONE nunca iba a controlar.
La consecuencia práctica es sencilla. Usa safetySettings solo cuando el failure observado realmente encaje con la capa ajustable del prompt. Si la response surface te está dando otra señal, cree esa señal y cambia el route.
Cómo leer SAFETY, OTHER, PROHIBITED_CONTENT e IMAGE_SAFETY
Nano Banana 2 se vuelve bastante más fácil de operar cuando lees la visible reason como una instrucción para el siguiente movimiento y no como una etiqueta vaga de rechazo.
En la documentación actual del Gemini API, Google documenta públicamente block reasons como SAFETY, OTHER, PROHIBITED_CONTENT e IMAGE_SAFETY. En integrations de generación de imágenes puedes ver esos valores o response-layer reasons muy parecidos en el body. La forma más segura de operar es tratar la visible reason como una routing instruction.
| Visible reason | Lo que suele indicar | Qué hacer después |
|---|---|---|
SAFETY | El request cayó en la configurable safety system. | Mira safetyRatings, compáralos con tus safetySettings actuales y confirma si realmente es un problema de las cuatro categorías ajustables. |
OTHER | El request puede haber tocado una policy boundary más amplia o contenido no soportado. Los troubleshooting docs de Google dicen explícitamente que BlockedReason.OTHER puede indicar Terms of Service o unsupported content. | No lo trates como un threshold problem estrecho. Replantea la tarea, simplifica el request o acepta que esa surface no es la adecuada. |
PROHIBITED_CONTENT | Ya no estás en una zona de mild false positive, sino en una policy zone más dura. | No sigas empujando la misma idea con pequeños retoques. Cambia la tarea o para. |
IMAGE_SAFETY | La image-generation safety layer bloqueó el output. | Reescribe el prompt, cambia el framing, cambia el style o pasa a una guía de troubleshooting más estrecha. No asumas que un toggle de settings lo va a resolver. |
La parte importante es la última columna. Estas labels son valiosas porque te dirigen a acciones distintas.
Si ves SAFETY, la documentación te da una ruta de settings. Si ves OTHER, Google ya te está diciendo que el problema puede vivir fuera de las adjustable categories. Si ves PROHIBITED_CONTENT, normalmente la jugada correcta es dejar de insistir con microcambios. Y si ves IMAGE_SAFETY, en general estás delante de un image-layer block, no de una prueba de que configuraste mal el API.
Aquí sigue habiendo un límite: Google no publica una trigger taxonomy detallada para cada caso de IMAGE_SAFETY o OTHER. Por eso no debes tratar esas labels como si revelaran un hidden rulebook. Son route markers, no una explicación completa.
Por qué también fallan prompts benignos
Una razón por la que Nano Banana 2 puede sentirse opaco es que incluso casos de uso legítimos pueden sufrir friction. En los current complaint threads del Google developer forum siguen apareciendo false positives con prompts de moda, lifestyle y otros contextos no NSFW. La model card de Gemini 3.1 Flash Image también dice que Google sigue reduciendo tanto false positives como false negatives, lo que equivale a admitir que el equilibrio todavía se está ajustando.
La lectura correcta de esa evidence no es "el modelo está roto" ni "todas las complaints son user error". La lectura más fuerte es otra: el contrato público sigue siendo incomplete.
Por ejemplo, una benign reference-image edit puede fallar aunque el usuario no esté pidiendo contenido sexual, de odio o violento. Una descripción de ropa puede leerse con más agresividad de la esperada. Una realistic portrait edit puede parecer rutinaria en una surface y fallar en otra. Nada de eso prueba una hidden official blacklist. Lo que prueba es que la friction operativa es más compleja que la taxonomy pública.
Esa diferencia importa. En cuanto la gente empieza a tratar los rumores de foros como si fueran policy oficial, la calidad del debugging cae. Se sobreajustan al folklore, no a la evidence, y terminan haciendo pequeñas cirugías de prompt donde en realidad lo que hacía falta era cambiar de route.
Un mejor workflow es registrar el failure exacto, reducir la ambigüedad y hacer un solo cambio importante cada vez. Mueve el framing desde identity- o body-centric language hacia task- o scene-centric language. Si la tarea incluye personas, decide antes si realmente necesitas photorealistic generation, editorial-style illustration o un reference transform más seguro. Y si aun así sigue fallando, la respuesta honesta a veces no es "todavía no encontré la frase mágica", sino "esta surface no lo soporta ahora mismo".
Gemini Apps vs Gemini API
Gran parte del mal advice sobre safety empieza cuando Gemini Apps y Gemini API se aplastan en una sola historia.
La documentación oficial de Gemini Apps no respalda esa simplificación. Google describe actualmente Nano Banana 2 en Gemini Apps como una surface con generación de imágenes, edición de imágenes subidas, combinación de imágenes y escenarios personalizados con personas. Eso ya basta para rechazar la blanket claim de que Nano Banana 2 "no permite imágenes de personas".
Al mismo tiempo, esa misma help surface advierte que las imágenes pueden eliminarse cuando el system detecta un posible policy issue. Ese caveat es la parte clave. Que una capability exista a nivel de producto no significa que todo request vaya a pasar. Y un app-level removal no es lo mismo que una documented API response reason.
Por eso los cross-surface anecdotes son tan engañosos. Una persona puede decir "esto me funcionó en Gemini" y otra "el API bloqueó la misma idea", y ambas pueden tener razón al mismo tiempo. El shell, el moderation path, el user-facing messaging y el enforcement timing no son iguales.
La consecuencia práctica para operadores es clara. Si tu tarea real es consumer-style editing o personalized image manipulation, Gemini Apps puede ser la mejor reference surface para entender qué está soportado hoy. Si tu tarea real es production API integration, necesitas razonar desde los documented API contracts y no desde screenshots del app o anecdotes de foros. Son señales relacionadas, pero no intercambiables.
Cuándo conviene cambiar de route en vez de seguir con retry
Uno de los hábitos más útiles alrededor de Nano Banana 2 image safety es saber cuándo otro retry solo va a perder tiempo.
Si recibes 200 OK pero sin una usable image, o ves un IMAGE_SAFETY claro en la response path, pasa a la guía más estrecha Nano Banana 2 devuelve 200 OK pero no entrega imagen. Ese es un operational failure mode muy concreto con su propia lógica de debug.
Si el failure mix incluye quota exhaustion, malformed requests o broader reliability problems, y no solo un safety-specific block, la ruta correcta es la guía más amplia Nano Banana 2 no funciona. En este locale todavía no hay una versión equivalente en español, así que aquí se mantiene el mejor route disponible. El análisis de safety no va a arreglar un 429, un bad parameter o un temporary service problem.
Si la pregunta real es si Nano Banana 2 puede manejar personas, retratos o personalized edits con estabilidad, entonces la mejor ruta es la página más específica sobre restricciones de Gemini image generation con personas. Esa pieza está enfocada en la rama human-image, en lugar de obligar a esta página a cargar con todo.
Y si tu trabajo se parece menos a "entender los safety contracts de Google" y más a "entregar image generation detrás de una sola capa estable de app o API", puede ser más relevante una tooling surface más amplia como Nano Banana AI image generator. Eso no elimina las policy decisions internas del modelo de Google, pero sí puede reducir el desorden operativo alrededor del provider switching y del fallback routing.
La idea grande es esta: muchas veces el siguiente paso correcto es routing, no otro retry. Cuando tratas Nano Banana 2 image safety como un problema de identificar primero el contrato y elegir después la acción, gran parte de los reintentos inútiles desaparece.
FAQ
BLOCK_NONE desactiva todos los safety filters de Nano Banana 2?
No. La lectura que respaldan hoy los docs del Gemini API es mucho más estrecha. BLOCK_NONE solo cambia los thresholds de cuatro prompt-side categories. No elimina las built-in core protections de Google y tampoco comprime el app-level policy behavior dentro del mismo rule set.
image safety significa que Nano Banana 2 no puede manejar imágenes de personas en absoluto?
No. La current help page de Gemini Apps muestra claramente escenarios de personalized-image y image-editing con personas. La afirmación más precisa es que los requests con personas viven en una zona más sensible y que el comportamiento puede variar entre Gemini Apps y Gemini API.
Se factura siempre un block de IMAGE_SAFETY?
La lectura más segura es tratar los processed image-generation blocks como potentially billable, a menos que la official surface diga lo contrario. Google publica el current token-based pricing de Nano Banana 2, pero en este research pass no apareció una frase oficial limpia que cubra todos los casos de IMAGE_SAFETY. Por eso el artículo evita una universal billing claim más fuerte que lo que permiten los docs.
Cuál es la forma más simple de depurar Nano Banana 2 image safety?
Identifica primero el contrato. Pregunta si se trata de los adjustable safety settings del Gemini API, de una API response reason más dura o del product-level policy behavior de Gemini Apps. Si ni siquiera puedes nombrar la layer, el resto del troubleshooting casi siempre termina siendo adivinanza.
Nano Banana 2 no tiene un único image-safety filter. Tiene varios enforcement contracts que el mercado suele meter dentro de una sola frase confusa. En cuanto los separas, los retry vacíos bajan mucho.