Si Nano Banana Pro muestra RESTRICTED by System Instructions, no empieces reescribiendo el prompt. En la mayoria de los casos, ese mensaje no significa que Google haya degradado Pro en todas partes al mismo tiempo. Suele significar una de tres cosas: estas en la surface equivocada, no tienes el entitlement correcto para esa ruta, o el pedido sigue dentro de una categoria que el sistema va a bloquear de todos modos.
Lo primero es identificar donde estas intentando usar Pro. En Gemini Apps, comprueba si la imagen llego de verdad a Redo with Pro y si aun te queda quota. En AI Mode, comprueba Thinking with 3 Pro, las condiciones actuales de disponibilidad y si el trabajo encaja de verdad con una ruta de infografias o diagramas. En AI Studio o en Gemini API, usa primero un prompt minimo claramente seguro sobre gemini-3-pro-image-preview y luego decide si el problema es de route o de category.
Despues de una sola correccion, no cambies de surface enseguida. Repite la prueba en la misma surface. Si un safe prompt funciona pero tu pedido original sigue fallando, deja de tratarlo como un problema de wording. En ese punto es mucho mas probable que estes viendo un limite de categoria y no un downgrade oculto.
Al 14 de abril de 2026, las help pages publicas de Google para Gemini Apps y AI Mode, junto con la documentacion de Gemini API, siguen describiendo Pro de forma distinta en cada surface. Y las safety docs siguen diciendo que algunos core harms permanecen siempre bloqueados. La pregunta util no es Google cambio Pro en secreto, sino que puerta fallo primero.
Tablero de ruta en 30 segundos
| Donde viste el bloqueo | Que revisar primero | Como verificar en la misma surface | Cuando cambiar la hipotesis |
|---|---|---|---|
| Gemini Apps | Si realmente aparecio Redo with Pro y si aun queda quota | El mismo trabajo ahora deja ver o completar el redo con Pro | Ya no es un problema de prompt sino de ruta o limite |
| AI Mode | Si estas en Thinking with 3 Pro, con condiciones validas y una tarea tipo diagrama | La misma tarea corre en la rama correcta de AI Mode | La tarea no encaja con el route actual |
| AI Studio o Gemini API | Si usas gemini-3-pro-image-preview y si un safe prompt minimo pasa | Ese safe prompt funciona en el mismo modelo | El problema es el pedido original, no Pro en general |
| El safe prompt funciona pero el pedido original no | La ruta sigue viva | Solo el pedido original sigue bloqueado | Debes leerlo como policy boundary |
Este mensaje confunde porque Nano Banana Pro ya no significa un solo carril identico en todas partes. En Gemini Apps, Pro aparece como una capa de redo despues de Nano Banana 2. En AI Mode, Pro es una ruta mas estrecha y mas selectiva. En la API, Pro es directamente un model ID. Si mezclas las tres superficies dentro del mismo experimento, la diferencia entre contratos parece una caida global de calidad.
Por eso, aqui casi siempre es un error empezar con cirugia de prompts. Cambiar el prompt no te dice si estabas en la surface equivocada, si no tenias el entitlement correcto o si ya habias chocado con una categoria que el sistema no va a dejar pasar. La ruta mas rapida es separar ramas, tocar una sola cosa y verificar sin cambiar de surface.
Si viste esto dentro de Gemini Apps
La correccion mas importante en esta rama es sencilla: Gemini Apps no empieza en Nano Banana Pro. La ayuda actual de Google dice que las imagenes nuevas se crean primero con Nano Banana 2 y que despues los usuarios de pago pueden usar Redo with Pro. Eso significa que mucha gente cree que ya esta evaluando Pro cuando en realidad esta evaluando el flujo default de Nano Banana 2 o un estado de la app donde ese redo ya no esta disponible.
Si RESTRICTED by System Instructions aparece dentro de Gemini Apps, hazte tres preguntas. Primera: la imagen llego realmente al punto donde aparecia Redo with Pro? Segunda: aun tienes quota para seguir usando ese redo? Tercera: estas comparando contra el contrato actual de la app o contra un recuerdo antiguo de lo que era Pro?
Aqui es facil mezclar route issue con quality complaint porque la app empaqueta default model, redo path y quota boundary dentro del mismo flujo de consumo. Cuando se agota el limite diario ligado a Nano Banana 2, el camino de Pro redo tambien puede desaparecer. En ese caso, la respuesta correcta no es prueba otra version del prompt. La respuesta es reconocer que la App-side contract ya no te esta dando esa ruta, y decidir si esperas el reset, cambias de surface o sigues conscientemente con Nano Banana 2.
Si lo que realmente te confunde es por que Pro se siente tan distinto entre Gemini Apps, AI Mode y la API, abre Nano Banana Pro empeoro?.
Si intentabas usar Pro en AI Mode
AI Mode es la rama donde mas tiempo se pierde porque el branding suena familiar mientras el contrato es mucho mas estrecho. La ayuda actual de Google describe Pro en AI Mode a traves de Thinking with 3 Pro y lo situa alrededor de infografias y diagramas, no como una ruta superior para cualquier imagen. Ademas, sigue teniendo condiciones actuales de plan, region y lenguaje.
Por eso, una negativa en AI Mode no equivale a Nano Banana Pro esta bloqueado en todas partes. Puede significar que estas en el modo equivocado, fuera de las condiciones actuales, o intentando empujar una tarea de imagen general por una ruta que Google hoy describe para visuales mas estructurados. Si tu trabajo se parece mas a hazme una imagen rapida que a arma una infografia clara, suele ser mas eficiente cambiar de surface que seguir refinando el mismo prompt.
La mejor verificacion en la misma surface es bastante sobria: manten la tarea estrecha y facil de juzgar. Confirma Thinking with 3 Pro, confirma las condiciones actuales y confirma el fit del trabajo; luego repite el mismo job. Si route y entitlement ya estan bien pero la tarea sigue fuera del papel actual de AI Mode Pro, insistir con prompt tuning no te dara mucha informacion nueva. Lo que toca revisar es la eleccion de surface.
Y por eso tampoco conviene mezclar Gemini Apps y AI Mode dentro de la misma prueba. Un usuario que crea en Apps, luego prueba algo parecido en AI Mode y luego vuelve esta comparando dos contratos distintos y llamando a la diferencia downgrade oculto. La disciplina mas segura es otra: una surface, una correccion, una verificacion.
Si usas AI Studio o la Gemini API
Del lado developer la lectura es mas mecanica. Si quieres Pro, el primer check es gemini-3-pro-image-preview. Despues, el primer test no deberia ser tu prompt de produccion, sino un prompt minimo claramente seguro. Una infografia simple, una comparativa en tres columnas o un diagrama neutral funcionan mejor que una tarea cargada de personas o categorias sensibles. Lo que quieres saber aqui no es si la salida es perfecta, sino si la ruta sigue viva.
Si ese safe prompt pasa en gemini-3-pro-image-preview, ya aprendiste algo importante: el modelo es reachable y la route no esta muerta. Si el pedido original sigue fallando, el foco del troubleshooting se mueve desde la disponibilidad de Pro hacia la categoria del pedido. En la API esa diferencia suele verse con mas claridad que en la surface de consumo.
Tambien conviene no mezclar en este titulo otros errores que pertenecen a otra familia. Si lo que estas viendo de verdad son 429, respuestas vacias, parametros ignorados o tamanos incorrectos, entonces ya no estas en el problema de RESTRICTED by System Instructions. En ese caso, la mejor salida es arreglar los errores comunes de Gemini image API, porque la siguiente rama ya es billing, endpoint o parameter handling.
Si el problema esta en la categoria del pedido
Esta es la rama que menos apetece aceptar, pero para esta frase suele ser de las mas utiles. Las Gemini safety docs actuales siguen diciendo que algunos core harms permanecen siempre bloqueados. No es un problema de quota, no es un hidden toggle y no es un caso en el que una pequena reescritura vaya a abrir la puerta con fiabilidad. Cuando ya descartaste route y entitlement, lo que queda puede ser la frontera de categoria.
La prueba practica es simple. No cambies de surface. No cambies de modelo. Sustituye el pedido original por uno claramente seguro y ordinario. Si ese safe control prompt pasa y el pedido original sigue bloqueado, ya separaste route issue de category issue. La ruta funciona. Lo que se bloquea es el trabajo concreto que estas intentando pasar por ella.
A partir de ahi, la pregunta util cambia. Puedes reformular el trabajo como una version segura? Puedes cambiar a una persona real por un personaje ficticio, o un edit sensible por una infografia neutral? Si la respuesta es no, entonces tambien conviene aceptar el no del sistema: la policy actual no esta permitiendo esa categoria, y seguir apretando el prompt no va a convertirla en una tarea aceptable.
Si tu caso se parece mas a restricciones con personas reales, public figures o rostros, la pagina adecuada es por que Gemini restringe la generacion de imagenes de personas. Pero esta pagina debe seguir siendo mas estrecha: su trabajo es ayudarte a reconocer la frontera rapido, no recontar toda la historia de policy.
Como verificar la correccion y elegir la ruta correcta
Cuando hagas una correccion, no cambies cinco variables a la vez. El orden mas seguro es este:
- cambia una sola cosa
- repite la prueba en la misma surface
- si aun necesitas separar route de category, añade un safe control prompt
- cambia de ruta solo cuando la surface actual ya no coincide con el contrato correcto
Ese orden importa porque vuelve legible el resultado. Si cambias surface, prompt y modo de acceso al mismo tiempo, no sabras que funciono. Si te quedas en la misma surface y corriges una rama cada vez, queda claro si arreglaste route, entitlement o si solo confirmaste una policy boundary real.
Si acabas de probar que Gemini Apps ya no te da el path de Pro redo, cambia de surface o espera al reset. Si acabas de probar que AI Mode no encaja con la tarea, deja de empujar ahi una tarea de imagen general. Si en la API un safe prompt funciona pero el original no, deja de leerlo como global Pro outage. Y si ni siquiera el safe prompt funciona, todavia no estas en policy diagnosis: vuelve a route y entitlement.
Despues de identificar el gate, ya tiene sentido abrir las paginas hermanas mas amplias:
- Nano Banana Pro empeoro?: cuando necesitas el contexto cross-surface
- Por que Gemini restringe la generacion de imagenes de personas: cuando el bloqueo cae en people / public-figure boundary
- Arreglar errores comunes de Gemini image API: cuando el fallo developer pertenece a otra familia
Preguntas frecuentes
Pro sigue existiendo en Gemini Apps?
Si, pero no como un carril de inicio siempre abierto. La ayuda actual de Google dice que la imagen se crea primero con Nano Banana 2 y que despues los usuarios de pago pueden aplicar Redo with Pro mientras sus limites actuales lo permitan.
AI Mode Pro sirve para cualquier tarea de imagen?
No. La descripcion actual de Google coloca Thinking with 3 Pro alrededor de infografias y diagramas. No significa modo superior para cualquier imagen.
La API puede aflojar esto con safety settings?
No para las categorias que Google describe como siempre bloqueadas. Hay contextos donde safety settings importan, pero la documentacion actual sigue diciendo que algunos core harms no se desbloquean por ese camino.
Que significa que el safe prompt funcione pero mi pedido original no?
Significa que la ruta sigue viva y que el problema ya esta en la categoria del pedido original. El siguiente paso es reformular el trabajo o aceptar la frontera.
Cuando conviene volver a Nano Banana 2?
Cuando lo que quieres es generacion de imagen general, cuando Gemini Apps ya te esta llevando por Nano Banana 2 como default path, o cuando AI Mode Pro claramente no encaja con la tarea. En la documentacion publica actual, Nano Banana 2 sigue ocupando el papel de ruta general por defecto.