Pides una imagen para una campaña y la primera versión funciona. Cambias el encuadre, corriges una frase y solicitas otra variante para una historia de Instagram. De pronto, el objeto ha cambiado de forma, la tipografía tiene una letra de más y el fondo parece pertenecer a otra campaña. Esa distancia entre una imagen bonita y una pieza que puedes entregar es donde conviene mirar el nuevo lanzamiento de Google.
Google ha publicado Gemini Nano Banana 2.1, una actualización de su modelo de generación y edición de imágenes. La ficha de Google Cloud fija su lanzamiento en disponibilidad general para el 6 de octubre de 2026, y las notas de la Gemini API confirman la misma fecha. Su identificador técnico es gemini-nano-banana-2.1.[1][3]
La propuesta combina mejoras de calidad visual, seguimiento de instrucciones, consistencia entre ediciones y representación de texto. Además, la tarifa publicada para los tokens de imagen de salida en la Gemini Developer API baja respecto a Nano Banana 2. Hay también una fecha que merece entrar en el calendario de quienes lo usan mediante API: Google anuncia que gemini-3.1-flash-image, el modelo anterior, dejará de funcionar el 29 de octubre de 2026.[2][4][3]
Vamos a separar lo que Google documenta de lo que todavía habría que comprobar trabajando con el modelo. Este artículo analiza las especificaciones y tarifas oficiales disponibles al publicarlo. No incluye una prueba propia de rendimiento, una comparación visual controlada ni una medición de latencia.
Qué es Nano Banana 2.1 y dónde encaja
Los nombres de esta familia obligan a leer la letra pequeña. Nano Banana 2 corresponde a Gemini 3.1 Flash Image. La nueva versión utiliza el identificador gemini-nano-banana-2.1. Nano Banana Pro sigue siendo Gemini 3 Pro Image, y Nano Banana 2 Lite corresponde a Gemini 3.1 Flash Lite Image. La guía de Google presenta 2.1 como el modelo principal de alta eficiencia para generar imágenes y editarlas mediante conversación, mientras reserva Pro para tareas visuales más complejas.[5]
Por tanto, el decimal no significa que todo lo anterior desaparezca a la vez. Hay una recomendación de usar 2.1 en nuevos proyectos y una retirada concreta anunciada para el identificador de Nano Banana 2 en la Gemini API. Tampoco podemos trasladar automáticamente una fecha de esa API a todas las aplicaciones de Google o a cualquier proveedor que revenda el servicio. Cada integración necesita comprobar su ruta y su calendario.[5][3]
La ficha para desarrolladores describe entradas de texto, imagen, vídeo y PDF, con salidas de imagen y texto. Declara un límite de entrada de 131.072 tokens y de salida de 32.768. Google Cloud también documenta la entrada de vídeo y la generación de imágenes a partir de ese material, pero no la salida de vídeo ni el soporte de audio.[2][1]
Esto amplía el material que puedes utilizar como referencia. Una miniatura basada en un vídeo, por ejemplo, puede partir del contexto de sus escenas en lugar de depender únicamente de una descripción escrita. La guía oficial contempla precisamente miniaturas, carteles e infografías inspiradas en vídeo. Sigue siendo generación de una imagen nueva: no hay que confundirla con extraer un fotograma fiel o con demostrar que una escena ocurrió tal como aparece en el resultado.[5]
Las mejoras que importan cuando hay que entregar un trabajo
Google anuncia mejor calidad visual y realismo en las resoluciones 1K, 2K y 4K, mayor precisión en texto y composición de infografías, y mejoras en la consistencia de personajes durante varias ediciones. También afirma haber corregido artefactos de repetición o mosaico en formatos muy anchos y muy altos a 2K y 4K.[2]
La importancia práctica está en cuánto trabajo queda después de generar. Si tienes que reconstruir el producto, volver a escribir todos los rótulos o rehacer la composición para cada formato, el ahorro inicial se va en correcciones. Una mejora de adherencia al encargo tendría valor precisamente ahí. Digo «tendría» porque una descripción del fabricante todavía necesita contrastarse con los encargos concretos de cada equipo.
En texto, la promesa interesa a quienes hacen menús, carteles, material educativo o anuncios. Pero la revisión tiene que seguir siendo literal: nombres, tildes, unidades, precios y fechas. Que una frase se vea bien integrada en una imagen no demuestra que esté bien escrita, y una tipografía convincente puede disimular un error mejor que una tipografía torpe.
La propia guía recomienda generar primero el texto y después pedir una imagen que lo incorpore. Es una recomendación útil para separar la aprobación del contenido de su presentación visual. Para una pieza con condiciones comerciales o instrucciones delicadas, resulta más prudente mantener el texto definitivo en una capa editable del programa de diseño y utilizar la IA para el material gráfico.[5]
En consistencia, Google documenta la combinación de hasta 14 imágenes de referencia y describe capacidades de conservación de hasta cuatro personajes y fidelidad de hasta diez objetos. Esos límites no equivalen a una garantía de que cualquier conjunto de referencias vaya a funcionar, ni acreditan que una pieza pueda publicarse sin supervisión.[2]
Para evaluar un producto, pediría una secuencia de cambios pequeños: otro fondo, distinta luz, un encuadre más cerrado y una versión vertical. Después compararía silueta, proporciones, materiales y elementos que debían conservarse. Si un bolso gana otro bolsillo o un envase cambia de tamaño, el resultado deja de describir el producto que vendes, aunque visualmente sea atractivo.
Más formatos, sin dar por hecho que más píxeles resuelven todo
La ficha de Google Cloud incluye formatos habituales como 1:1, 4:5, 9:16 y 16:9, junto a proporciones extremas como 1:4, 4:1, 1:8 y 8:1. El modelo ofrece resoluciones 1K, 2K y 4K. La ficha de la Gemini API indica que 1K es la resolución predeterminada y destaca la corrección de artefactos en composiciones panorámicas.[1][2]
Un formato ancho puede servir para una cabecera o una pieza que necesite continuidad visual. Uno alto puede ser útil para una composición vertical extensa. Eso te permite plantear el encargo con sus dimensiones desde el principio, aunque todavía debas revisar el archivo obtenido y adaptarlo a las especificaciones del destino.
Conviene separar resolución, proporción y calidad. Una salida con más píxeles facilita ciertos usos, pero no corrige por sí misma una perspectiva incoherente, un dato equivocado ni un objeto deformado. Para impresión, además, hay que comprobar dimensiones finales, densidad de píxeles, color y requisitos del proveedor. La etiqueta «4K» no constituye una certificación de imprenta.
Hay un detalle de migración fácil de pasar por alto: la guía mantiene la salida 0.5K para Gemini 3.1 Flash Image y señala que esa resolución no está disponible en Nano Banana 2.1. Si un servicio antiguo generaba imágenes pequeñas, habrá que revisar sus costes, tamaños y procesamiento posterior al cambiar de modelo.[5]
Para contenido digital, empezaría las pruebas en 1K y aumentaría la resolución cuando el uso lo justifique. Es una decisión de producción: ahorrar una salida grande que después vas a reducir puede ser razonable, pero ahorrar tamaño cuando el material necesita detalle también puede obligarte a repetir el trabajo.
El precio baja en la Gemini API, pero hay que leer qué se cobra
La página de tarifas de la Gemini Developer API publica para Nano Banana 2.1 un precio de 30 dólares por millón de tokens de imagen de salida en modalidad estándar y de 15 dólares en Batch. Para Nano Banana 2, esa misma página muestra 60 dólares por millón. En esa partida concreta, la tarifa estándar de 2.1 es un 50% menor.[4]
La equivalencia publicada para salidas cuadradas es de 0,0336 dólares por imagen 1K, 0,0504 dólares por imagen 2K y 0,0756 dólares por imagen 4K. Son importes correspondientes a la imagen de salida según esa página, consultada el 6 de octubre de 2026. No son una cotización universal para cualquier plataforma o configuración.[4]
Para aterrizarlo, mil imágenes 1K supondrían 33,60 dólares en imagen de salida. Mil salidas 2K sumarían 50,40 dólares y mil salidas 4K, 75,60 dólares. Son cálculos sobre las equivalencias de la Developer API, asumiendo exactamente mil imágenes generadas y sin añadir entradas, texto de salida, búsquedas ni otros costes del servicio.[4]
Google avisa de que una solicitud puede provocar varias consultas a Google Search y que se cobra cada consulta. La ficha de Cloud también recuerda que hay cargos adicionales por tokens de otras modalidades. Así que el coste de una automatización depende del material enviado, de lo que responde el modelo y de las herramientas que activa, además de la imagen final.[4][1]
Y falta la variable más habitual: los intentos. Si para obtener mil piezas aceptadas necesitas generar tres mil salidas 1K, esa misma partida pasa a 100,80 dólares. Es un ejemplo aritmético, no una tasa de rechazo medida en este modelo. Sirve para recordar que el coste relevante es el de la pieza aprobada, incluyendo revisión y correcciones, y no únicamente el de pulsar «generar».
Hay además una discrepancia documental que conviene hacer visible. La ficha de Google Cloud asigna 3.780 tokens de salida a una imagen 4K; la página de precios de la Gemini Developer API utiliza 2.520 para su equivalencia 4K. No voy a combinar los tokens de una con la tarifa de la otra y presentar el resultado como una factura confirmada. Los ejemplos anteriores siguen exclusivamente la Developer API. Si trabajas por Cloud, confirma la tarifa y el consumo aplicables a esa ruta antes de presupuestar.[1][4]
Búsqueda, referencias y límites: una imagen convincente sigue necesitando revisión
Nano Banana 2.1 admite apoyo de Google Search y búsqueda de imágenes para fundamentar la generación. La ficha también documenta niveles de razonamiento configurables: mínimo, medio como valor predeterminado y alto. Esas son capacidades anunciadas del modelo; su efecto concreto sobre calidad, tiempo y coste tendrá que medirse en cada flujo.[2]
La búsqueda puede aportar contexto visual o información actual, pero no garantiza la exactitud de una infografía. Si una imagen representa cifras de ventas, un mapa o instrucciones médicas, los datos necesitan una revisión independiente. Una fuente recuperada puede ser pertinente y el gráfico final, aun así, tener mal un rótulo o una proporción.
También hay condiciones de presentación. La guía indica que, al utilizar búsqueda de imágenes dentro de la fundamentación con Google Search, deben mostrarse las sugerencias de búsqueda que devuelve el servicio. Para una aplicación, esto forma parte del diseño del producto: no basta con guardar el PNG y desechar todo lo que acompaña a la respuesta.[5]
Respecto a derechos, Google recuerda que debes tener los permisos necesarios sobre las imágenes que subes. Encontrar una fotografía mediante búsqueda no demuestra que puedas utilizarla comercialmente, y emplearla como referencia no elimina esa comprobación. Para campañas, mantendría un registro del origen de cada recurso, sus permisos y el uso autorizado.[5]
Hay otra diferencia que no conviene esconder: la documentación para desarrolladores habla de consistencia de personajes, mientras que la ficha específica de Google Cloud marca «Person generation» como no soportado, aunque sí incluye «Virtual try-on». Eso impide prometer de forma general que cualquier generación de personas estará disponible en todas las rutas. Si ese es tu caso de uso, verifica el servicio concreto y sus políticas antes de diseñar la campaña.[2][1]
La guía señala que las imágenes generadas incorporan una marca de agua SynthID. Google Cloud también declara soporte de Content Credentials, basado en C2PA. Son mecanismos de procedencia que merece la pena conservar y verificar en el flujo de publicación. No demuestran que lo representado sea cierto ni sustituyen una revisión de derechos, consentimiento o exactitud.[5][1]
Si ya usas Nano Banana 2, prepara la migración antes del 29 de octubre
Las notas oficiales de la Gemini API anuncian la retirada de gemini-3.1-flash-image el 29 de octubre de 2026 y recomiendan migrar a gemini-nano-banana-2.1. Para un flujo de producción, esto merece atención inmediata: una actualización del modelo tiene consecuencias distintas cuando alguien depende de recibir una pieza a una hora concreta.[3]
Empezaría por localizar el identificador anterior en los scripts, las variables de configuración y los módulos de Make, n8n o cualquier aplicación que invoque la API. Después comprobaría si el proveedor o conector permite seleccionar la nueva versión. Si una integración oculta el identificador detrás de un nombre comercial, pediría confirmación de qué modelo utiliza realmente.
Cambiar el nombre es solo una parte. La ficha de Cloud advierte expresamente que Nano Banana 2.1 no admite los parámetros seed, topK, logprobs, temperature y topP, y que enviarlos devuelve un error de API. Una configuración heredada puede fallar aunque el identificador sea correcto.[1]
Tampoco asumiría que todas las APIs y bibliotecas tienen las mismas prestaciones. Cloud marca Interactions API en versión preliminar como no soportada para esta ficha, y la guía general para desarrolladores muestra flujos basados en interacciones. Hay que consultar el contrato de la ruta elegida y la versión de su SDK, en lugar de copiar un ejemplo de otro entorno sin comprobarlo.[1][5]
Además, ambas fichas señalan que no hay llamadas a funciones ni salidas estructuradas. Si la automatización necesita un JSON de validación, una decisión de negocio o llamadas a otras herramientas, esas responsabilidades deben resolverse fuera del generador. Una respuesta capaz de mezclar texto e imágenes no constituye por sí sola un agente que coordine toda la producción.[2][1]
Antes de cambiar producción, mantendría un conjunto pequeño de encargos ya conocidos: un producto con varias referencias, una composición con texto aprobado, una edición que deba conservar el objeto y una imagen en formato extremo. Compararía resultados, errores, tiempos y consumo real. El objetivo es descubrir qué cambia en tu trabajo, incluyendo fallos y casos que antes funcionaban.
Durante ese ensayo registraría el modelo exacto, la configuración, las referencias empleadas y los resultados aprobados. También limitaría los reintentos y contemplaría respuestas bloqueadas o sin imagen. La guía advierte que el modelo no siempre sigue el número exacto de imágenes solicitado, por lo que la automatización debe comprobar lo recibido en vez de dar por hecho que siempre habrá un archivo listo para publicar.[5]
Dónde lo probaría y qué dejaría bajo control humano
Para un equipo de comunicación, lo probaría primero en variantes de composición, fondos, ilustraciones editoriales y adaptación de formatos. En comercio electrónico, empezaría con materiales de apoyo que no sustituyan la fotografía documental del producto. En formación, serviría para explorar ilustraciones y diagramas, conservando una comprobación independiente de todo el contenido factual.
Si vas a hacer esa evaluación, pide cambios concretos y define lo que debe permanecer. «Cambia únicamente el fondo y conserva la forma y el color del producto» ofrece un criterio de revisión más claro que «hazlo mejor». La guía oficial recomienda describir con precisión, aportar propósito y refinar mediante cambios pequeños. Eso ayuda a que el encargo y su aceptación se puedan discutir con claridad.[5]
Reservaría la aprobación humana para la fidelidad del producto, los textos, las identidades y los usos sensibles. En una campaña, por ejemplo, que el modelo genere una variante no le concede permiso para cambiar una oferta, inventar un atributo o publicar el archivo. Esas decisiones necesitan reglas propias y una persona responsable.
Nano Banana 2.1 merece atención porque Google promete mejorar varios problemas que aparecen entre la primera generación y la entrega, y porque la Developer API publica una reducción concreta en la tarifa de imagen de salida. Todavía hace falta comprobar cuánto de esa mejora llega a cada trabajo. Si ya dependes de Nano Banana 2 por API, la prioridad está clara: revisar la integración, probar el sustituto y preparar el cambio antes de su retirada. Después, mide cuántas piezas utilizables obtienes y cuánto cuesta terminarlas. Ahí tendrás una respuesta más útil que en la primera imagen que salga bonita.[2][4][3]
Fuentes y referencias
Documentación consultada el 6 de octubre de 2026. Se utilizaron las páginas en inglés para contrastar los cambios recientes de la Gemini API. Las prestaciones anunciadas se atribuyen a Google; las recomendaciones de evaluación y producción son criterio editorial.
- Google Cloud: ficha técnica de Gemini Nano Banana 2.1.
- Google AI for Developers: novedades y capacidades de Gemini Nano Banana 2.1.
- Gemini API: notas del lanzamiento y anuncio de retirada de Nano Banana 2.
- Gemini Developer API: precios de generación de imágenes.
- Gemini API: guía de generación y edición de imágenes.
Las tres ilustraciones de este artículo se generaron con GPT Image 2.5 mediante nuestro proceso editorial. Son imágenes conceptuales y no resultados de Nano Banana 2.1. No deben utilizarse para juzgar la calidad visual del modelo de Google.