Imagina una firma contable pequeña que llama a finales de octubre porque el asistente de cotizaciones de su sitio dejó de responder. Esa semana no se desplegó nada. Nadie tocó el código. En los logs se ve la misma petición saliendo y un 404 regresando, una y otra vez, desde un modelo que el viernes anterior funcionaba bien.
Así se ve el retiro de un modelo de IA desde adentro de una empresa pequeña. No hay página de estado, no hay banner rojo, no hay una caída de la que todo el mundo esté hablando. Simplemente una función deja de trabajar, y quien la construyó se fue hace meses.
Hay uno de estos en el calendario justo ahora, y está cerca.
Qué cambió y cuál es la fecha que importa
El 14 de septiembre de 2026, Google publicó fechas actualizadas de deprecación y retiro para un grupo de modelos Gemini en las notas de versión de Google Cloud. La entrada que afecta a más software en producción: Gemini 2.5 Pro, Gemini 2.5 Flash y Gemini 2.5 Flash-Lite tienen fecha de retiro el 16 de octubre de 2026, según la documentación de ciclo de vida de modelos de Google, consultada el 18 de septiembre de 2026.
Dos detalles de esa documentación pesan más que la fecha principal, y son justo los que se le pasan a la gente.
El primero: la fecha de retiro es el último día en que el modelo está disponible. Después de esa fecha, la documentación de Google indica que el modelo queda desactivado de forma permanente, sin acceso ni soporte, y que las peticiones que usan el ID de un modelo retirado normalmente devuelven un error 404. No es una advertencia ni un respaldo más lento. Es un 404, que la mayoría del código escrito con prisa trata como una falla genérica cualquiera.
El segundo detalle es el que agarra a todos desprevenidos. La página de versiones y ciclo de vida de modelos de Google indica que un mes antes de la fecha de retiro se bloquea el acceso nuevo al modelo para inferencia en línea, inferencia por lotes y ajuste. Para un retiro el 16 de octubre, esa ventana se cerró a mediados de septiembre. Si un proyecto nunca ha llamado a Gemini 2.5, es posible que ya no pueda empezar, así que aquello de "primero probamos en el modelo viejo y migramos después" dejó de ser un plan viable.
A quién le afecta de verdad
No todos los que usan Gemini tienen algo que hacer. La diferencia está en si el nombre de un modelo aparece escrito en algún lugar de tus sistemas.
Si tu equipo usa Gemini dentro de Google Workspace, en el panel lateral de Gmail o Documentos, no estás eligiendo una versión de modelo y no tienes migración que correr. Google administra lo que hay detrás de esa experiencia.
Estás expuesto si un ID de modelo como gemini-2.5-flash aparece en algo de lo que depende tu operación. En una empresa de diez a sesenta personas, suele vivir en alguno de estos lugares:
- Un Apps Script pegado a una hoja de cálculo que clasifica prospectos o redacta respuestas.
- Un chat o formulario de cotización del sitio web, casi siempre una Cloud Function o un backend pequeño.
- Un paso en una plataforma de automatización, donde el nombre del modelo vive en un menú o en un campo JSON dentro de un flujo que nadie abre desde hace un año.
- Una app web o móvil construida sobre Firebase.
- Un script de reportes o de resúmenes que corre programado, y cuyo resultado alguien pega cada mes en una presentación para el cliente.
- Un prototipo que se volvió producción en silencio, porque funcionaba.
El último es el que más daño hace, porque es el que no tiene dueño, ni pruebas, ni manejo de errores.
Qué revisamos primero en un proyecto de cliente
Cuando un cliente nos pide resolver una de estas fechas límite, no empezamos cambiando nombres de modelos. Empezamos por encontrarlos todos.
1. Inventariar cada punto de llamada. Buscar en todo el entorno, no solo en el repositorio principal, por familia de modelo y no por una cadena exacta. Los sufijos de versión varían, y de eso se trata la búsqueda amplia:
grep -rn "gemini-2\.5" . --include="*.js" --include="*.ts" --include="*.py" --include="*.gs" --include="*.json" --include="*.yaml" --include="*.env*"Después hay que repetirlo a mano donde grep no llega: proyectos de Apps Script adjuntos a hojas y formularios, flujos en plataformas de automatización, variables de entorno definidas en una consola y no en un archivo, y cualquier configuración que haya dejado un proveedor anterior.
2. Separar versiones fijadas de alias. Google publica versiones estables junto con alias que se actualizan solos. El código que fija una versión exacta es predecible y se va a romper en una fecha conocida. El código que sigue un alias se mueve por su cuenta, lo cual es cómodo hasta que un cambio de generación altera el comportamiento bajo un prompt afinado para el modelo anterior. Los dos casos necesitan revisión. Necesitan revisiones distintas.
3. Probar si el acceso ya está bloqueado. Por la regla del mes que mencionamos arriba, revisamos temprano si el proyecto todavía alcanza el modelo viejo. Eso cambia el plan. Si ya no lo alcanza, no hay transición gradual que diseñar, solo una migración.
4. Rastrear qué consume la salida. Una llamada que falla es un problema. Una llamada cuya respuesta se guarda en una base de datos, se le envía por correo a un cliente o define en qué cola cae un ticket es un problema mucho mayor. Seguimos la salida hasta su última parada antes de decidir cuánto cuidado hace falta.
5. Leer el manejo de errores. Aquí aparece el riesgo real. Muchas integraciones pequeñas envuelven la llamada en un try que se traga la excepción y devuelve una cadena vacía. El día del retiro ese código no truena. Sigue corriendo, y manda contenido en blanco o cortado a clientes reales, cosa que nadie nota durante una semana.
La migración, en el orden en que la hacemos
Lee la lista de modelos vigente para tu propio proyecto. No un artículo de blog, incluido este. Las fechas y la disponibilidad cambian por región y por superficie, y las páginas de modelos de Google son el único lugar donde eso es definitivo para tu cuenta.
Elige un modelo en disponibilidad general, no uno en preview. Los modelos en preview tienen su propio ciclo de vida, a menudo más corto, y no son el lugar donde aterrizar trabajo de producción que no quieras volver a mover en seis meses. Si el único reemplazo que sirve para tu caso está en preview, conviene saberlo antes de planear el trabajo, no después.
Mueve el ID del modelo a configuración. Si la cadena está escrita a mano en el código, el primer cambio es sacarla a una variable de entorno o a una sola constante. Ese es el arreglo que vuelve esta fecha límite la última dolorosa, porque el siguiente retiro pasa a ser un cambio de configuración y una prueba.
Vuelve a probar los prompts, no solo cambies el nombre. Una generación nueva no es un reemplazo directo. Cambian el largo de la respuesta, el tono, el formato y qué tan al pie sigue las instrucciones, y a veces cambian los nombres de los parámetros entre generaciones, así que revisa la guía de migración de Google para el par que vas a mover. Si tu prompt pide JSON, comprueba que siga devolviendo JSON que se pueda parsear. Corre las veinte entradas reales más comunes y compara las respuestas lado a lado.
Arregla el manejo de errores ya que estás adentro. Cualquier llamada que pueda fallar debe fallar de forma ruidosa: registra el ID del modelo, registra el código de estado y avisa a una persona. Diez minutos de trabajo aquí convierten cada deprecación futura en una notificación en vez de un misterio.
Despliega y luego observa. Despliega antes de la fecha, no ese mismo día, y deja el valor anterior en configuración hasta que veas una semana completa de tráfico normal con el modelo nuevo.
Notas de costo y riesgo
Tres cosas sobre las que conviene ajustar expectativas.
El precio es por modelo, así que verifícalo. Las tarifas cambian entre familias y niveles de modelo, y uno más nuevo o más grande no es automáticamente el más barato ni el más caro. Revisa la tarifa vigente del modelo específico al que te vas a mover contra tu volumen mensual real antes de comprometerte, en lugar de asumir que el cambio sale igual.
Estas fechas se mueven, en los dos sentidos. No siempre se adelantan. En el mismo grupo de actualizaciones de septiembre de 2026, a Gemini 2.5 Flash Image se le puso fecha de retiro el 15 de marzo de 2027, extendida desde el 2 de octubre de 2026, y Gemini 3.1 Flash-Lite Image quedó con fecha de retiro prevista para el 28 de junio de 2027 o después. Una extensión es un regalo, no un plan. Lo correcto ante una fecha que se corre es dejar la migración agendada y disfrutar el margen extra.
El riesgo real es el inventario, no la ingeniería. Cambiar el nombre de un modelo es una tarea chica. Estar seguro de que encontraste todos los lugares donde aparece es el trabajo completo, y la primera búsqueda en un repositorio pocas veces es la que encuentra todo.
Cómo ayuda Guanacos Tech
Esto lo hacemos como un trabajo corto y acotado: inventariar cada lugar donde se llama a un modelo Gemini en tu código, scripts, automatizaciones y consolas, decirte cuáles se rompen el 16 de octubre y cuáles están bien, migrar los que importan, y dejar el ID del modelo en configuración con manejo de errores que avise la próxima vez. Somos una consultora independiente con ingenieros certificados por Google, y trabajamos en inglés y español en Norteamérica y Latinoamérica.
Si no tienes claro si algo en tu empresa llama a Gemini 2.5, esa duda ya es la respuesta, y vale una hora antes de octubre. Puedes ver qué hacemos en Google Cloud, o agendar una llamada y lo revisamos contigo.