Retirar un modelo es la nueva obsolescencia de una API, salvo que cambia el comportamiento y no la sintaxis

Cuando una API REST queda obsoleta, el fallo hace ruido. Las llamadas devuelven errores, las pruebas fallan, alguien recibe una alerta. Cuando se retira un modelo, el fallo puede ser silencioso. El endpoint se sustituye, las llamadas siguen funcionando y las respuestas cambian. El clasificador de facturas sigue devolviendo una categoría. Solo que no siempre la misma.

Por eso una actualización rutinaria de la documentación de Databricks esta semana merece la atención de cualquiera que tenga IA en producción.

Qué ha pasado

La documentación de las Foundation Model APIs de Databricks da por retirados Gemini 2.5 Flash y Gemini 2.5 Pro el 2 de octubre de 2026. La política de mantenimiento muestra que Gemini 2.5 Flash sale tanto en pago por token como en capacidad aprovisionada (provisioned throughput), y que Gemini 2.5 Pro sale de la capacidad aprovisionada en la misma fecha. Los sustitutos recomendados son Gemini 3.1 Pro o Gemini 3.5 Flash.

El siguiente de la lista: Claude Sonnet 4 en pago por token se retira el 9 de octubre de 2026, con Claude Sonnet 4.6 como sustituto recomendado. DeepSeek V4 Pro (0813) e Inkling, de Thinking Machine Labs, todavía en Public Preview, salen el 30 de octubre.

La política explica la mecánica sin ambigüedad. Un modelo pasa de legacy (ya no se ofrece a nuevos espacios de trabajo) a obsoleto (con fecha de retirada anunciada a 30 o 90 días) y después a retirado (inaccesible). Quien usa capacidad aprovisionada a veces tiene más margen: Meta Llama 3.1 405B salió del pago por token en febrero de 2026 pero siguió disponible en capacidad aprovisionada hasta mayo.

Hay un detalle que pesa más que las fechas. Cuando el proveedor del modelo avisa con menos de un mes, Databricks dice que puede redirigir temporalmente las llamadas a una versión similar para dar tiempo a migrar. Entre el 26 de marzo y el 7 de junio de 2026, las llamadas a Gemini 3 Pro se redirigieron a Gemini 3.1 Pro. Es una cortesía razonable. También significa que el modelo que responde a su tráfico de producción puede cambiar sin que cambie una sola línea de su código.

Por qué es más difícil que retirar una API

Retirar una API cambia el contrato. Retirar un modelo mantiene el contrato y cambia el comportamiento que hay detrás. El modelo nuevo suele ser mejor en promedio, pero los sistemas en producción no funcionan en promedio. Funcionan con prompts concretos, formatos de salida concretos, umbrales que alguien ajustó y código que interpreta lo que vuelve.

Lo que puede cambiar al sustituir un modelo:

• La forma de la salida: el JSON que llegaba limpio viene con comentarios, un campo cambia de nombre, una lista cambia de orden.
• El criterio: los casos límite de un clasificador caen de otro lado; una extracción se vuelve más o menos conservadora.
• Coste y latencia: un sustituto de gama superior puede duplicar el coste por tarea o añadir segundos a un paso con presupuesto de latencia.
• Rechazos y comportamiento de seguridad: el modelo nuevo puede rechazar entradas que el anterior aceptaba, o al revés.

Nada de esto produce un error. Todo esto puede romper un proceso de negocio.

Trate los modelos como dependencias con fecha de caducidad

1. Aviso de retirada
2. Sustituto candidato
3. Evals de regresión en sus tareas
4. Control de coste y latencia
5. Versión aprobada
6. Vía de rollback disponible

EvidenciaControl de versiones

Mantenga un inventario con fechas. Cada uso en producción de un modelo alojado debería figurar con proveedor, plataforma, modalidad de pago y fecha de retirada publicada. Casi todos los equipos saben qué modelos usan; pocos saben cuáles caducan este trimestre.

Abstraiga el nombre del modelo. Referencie los modelos por configuración o por una ruta del gateway, no con cadenas repartidas por los servicios. En nuestro análisis del C1 LLM Gateway explicamos que el gateway se está convirtiendo en un punto de aplicación de políticas; el ciclo de vida de los modelos es una política más.

Tenga un conjunto de regresión propio. La única forma fiable de aprobar un sustituto es ejecutarlo sobre sus propias tareas y con su propia forma de puntuar. Es lo que defendimos en nuestro artículo sobre Palantir AIP Evolve: la evaluación es la superficie de control que hace segura la mejora.

Fije versiones cuando pueda y sepa cuándo no puede. Fijar una versión da previsibilidad hasta la fecha de retirada. Con redirecciones, una versión fijada es una petición, no una garantía.

Decida el fallback por adelantado. Si un modelo desaparece o empeora, ¿cuál lo sustituye, con qué coste y quién aprueba el cambio?

Pase el cambio por la gestión de cambios habitual. En España, una entidad financiera sujeta a DORA tiene que gestionar el riesgo de sus proveedores de servicios TIC y documentar sus cambios; que el proveedor sustituya el modelo es un cambio en un servicio TIC contratado. Y si el modelo forma parte de un sistema de alto riesgo según el Reglamento europeo de IA, conviene que el equipo jurídico valore si la sustitución constituye una modificación sustancial que obligue a repetir la evaluación de conformidad. En Latinoamérica el marco depende de cada supervisor, pero la lógica es la misma: el modelo es un proveedor más y sus cambios necesitan evidencia.

Qué hacer esta semana

1. Busque en el código y la configuración Claude Sonnet 4 en pago por token en Databricks. El 9 de octubre está a seis días.
2. Liste todos los modelos alojados de los que depende con su fecha de retirada y póngalas en el mismo calendario que los vencimientos de certificados.
3. Construya un conjunto pequeño de regresión por caso de uso, aunque sean 50 casos representativos con su salida esperada, y ejecútelo antes de cada cambio de modelo.
4. Pregunte a sus plataformas cómo gestionan las retiradas con poco aviso: redirección, error o fallback, y si avisan cuando redirigen el tráfico.
5. Presupueste las migraciones. Cada modelo del que depende implica al menos una migración al año.

En resumen

Los modelos alojados son ya dependencias con fecha de caducidad publicada, y el sustituto nunca es un simple recambio. Los equipos que lo gestionarán con calma son los que ya tratan un cambio de modelo como una versión: inventario, evaluación, aprobación y camino de vuelta.