Veinte días o seis meses: cuánto tiempo tienes cuando retiran un modelo

Qué ha pasado en las últimas dos semanas

Tres anuncios, cada uno en la propia página de retiradas del fabricante, y ninguno tuvo eco en la prensa española ni húngara:

• 11 de septiembre. OpenAI marcó gpt-5.4-cyber para retirada. La fecha de apagado es el 1 de octubre de 2026. Son veinte días desde el anuncio. El sucesor es gpt-5.6-cyber.
• 24 de septiembre. Se apagan la Videos API y las variantes del modelo Sora 2. Esto se anunció ya el 24 de marzo, así que aquí el plazo fue de seis meses — pero no se nombra ningún modelo sucesor. Las experiencias de navegador y móvil ya se habían discontinuado el 26 de abril.
• 26 de agosto. Cuatro modelos de transcripción (whisper-1, gpt-4o-transcribe, gpt-4o-mini-transcribe, gpt-4o-transcribe-diarize) pasaron a retirada, con apagado el 26 de febrero de 2027. Aquí tienes seis meses, y hay sucesor nombrado.

El patrón no es «de vez en cuando se discontinúa algo». El patrón es que el plazo oscila entre veinte días y seis meses en el mismo proveedor, y no hay manera de predecir cuál te toca.

24 SEP  Se apagan Videos API + Sora 2
        sin modelo sucesor nombrado
        anunciado 24 mar -> 6 meses

1 OCT   Se apaga gpt-5.4-cyber
        sucesor: gpt-5.6-cyber
        anunciado 11 sep -> 20 DÍAS

2 NOV   grok-imagine-image-quality
        redirigido, quality=low
        anunciado 2 sep  -> 61 días

11 DIC  Se apagan snapshots gpt-5 y o3
        sucesor: variantes gpt-5.6
        anunciado 11 jun -> 6 meses

Qué se comprometen por escrito seis proveedores

Esta es la espina dorsal del artículo. Cada fila sale de la documentación del propio fabricante, a 12 de septiembre de 2026:

La lección no es qué proveedor es «mejor». Es que el plazo no es una costumbre del sector, sino un compromiso distinto por proveedor y por nivel (GA o preview) — y si no lo has leído, no sabes de cuánto tiempo dispondrás.

Tres trampas peores que el plazo

1. El modelo no se apaga, cambia debajo de ti. Este es el caso difícil, porque no recibes ningún error. Los despliegues Standard de Microsoft Foundry se actualizan automáticamente en la retirada, región por región. Detrás del alias latest de Google aparece una versión nueva con dos semanas de aviso. Con la variante de calidad de imagen de Grok, las peticiones no se rechazan, sino que se redirigen a la 2.0 con quality=low, a un precio por imagen más bajo. En los tres casos el código sigue funcionando — solo devuelve otra cosa.

2. La capacidad reservada no se actualiza sola. En el mismo sitio donde un despliegue Standard pasa automáticamente, un despliegue Provisioned no se actualiza: hay que migrarlo a mano, y pasado el plazo cada petición devuelve 410 Gone. Es decir, quien pagó por capacidad garantizada recibe más trabajo, no menos. Y en un modelo en preview no hay tercera vía: o se fuerza la actualización o se termina — quedarse no es una opción.

3. No solo se puede ir el modelo, también los datos. En el caso del servicio de vídeo que se apaga el 24 de septiembre, la propia ayuda del fabricante dice que al cerrarse la ventana de exportación borrará de forma permanente los datos asociados a tu uso del servicio, y recomienda exportar cuanto antes. Si dentro de una herramienta se han acumulado meses de trabajo, ese es el plazo sin vuelta atrás.

Qué hacer ahora

Cuatro pasos, unas pocas horas en total:

1. Apunta qué identificadores de modelo aparecen en tus sistemas. No solo en el código: en las automatizaciones, en los flujos no-code , en las llamadas metidas en hojas de cálculo y en la configuración de las herramientas que usa tu equipo. De lo que no sabes en qué modelo corre, no te vas a enterar cuando lo retiren.
2. Usa identificadores versionados en lugar de un alias tipo latest — al menos donde importe la estabilidad de la salida. El compromiso es real: el identificador versionado lo tienes que ir subiendo tú, pero no cambia debajo de ti tras un correo. El alias es cómodo, y puede voltear en dos semanas.
3. Designa un sucesor para cada modelo antes de necesitarlo. No basta con saber cuál es el reemplazo recomendado por el fabricante: también hay que saber cómo rinde en tu tarea. Para eso sirve una comparación de dos semanas, cuya receta detalla Una cata de modelos de dos semanas , un artículo aparte.
4. Abre la página de retiradas de tu proveedor y ponla en el calendario. La única fecha que de verdad cuenta es la tuya: cuándo hay que cerrar la migración por tu parte. El plazo del fabricante no es tu plazo.

Dos decisiones estructurales reducen la exposición. Un model router pone los modelos de varios proveedores detrás de una sola clave, con lo que cambiar pasa a ser una cuestión de configuración y no un proyecto de desarrollo. Y con los modelos open-weight lo que has descargado no te lo pueden retirar — los pesos están contigo. Ninguna de las dos es gratis: el router es un intermediario más, y la ejecución local pide hardware y operación. (Más información: Care mensual — migramos antes de que retiren el modelo.)

Cómo enterarte a tiempo

Aquí está el problema de fondo: no hay feed RSS bajo las páginas de retiradas de ningún gran proveedor. Ni OpenAI, ni Anthropic, ni Google, ni Microsoft, ni AWS. El feed del blog del fabricante lleva los anuncios; las retiradas no aparecen ahí — y las newsletters diarias de IA se saltan este tipo de noticia de forma rutinaria, porque no resulta bastante emocionante.

Quedan dos métodos. O cinco minutos semanales en el calendario, en los que recorres las dos o tres páginas de retiradas que te afectan. O vigilancia automática de páginas: un servicio de detección de cambios basta para esto incluso en su nivel gratuito, y además te muestra el contenido del cambio, no solo que ha cambiado algo. Encontramos una excepción consolidada: el calendario de retiradas de Microsoft Foundry lista los modelos de diez proveedores con fechas en una sola página — un buen resumen aunque no uses Azure.

Malentendidos típicos

• «Ya avisarán por correo.» El aviso llega normalmente a quien tiene uso activo de ese modelo, a la dirección registrada como contacto de desarrollo o de facturación — no necesariamente a quien opera el proceso.
• «Los grandes proveedores dan seis meses todos.» El mismo proveedor dio veinte días y seis meses en un mismo mes. El compromiso de quince días tampoco es teórico: está publicado.
• «Un modelo en preview vale para producción.» Dos de ellos se comprometen a dos y a treinta días de aviso respectivamente, y un despliegue en preview no tiene la opción de «me quedo en el viejo». Un proceso en producción sobre un modelo en preview no es optimizar costes, es exposición.
• «A mí no me afecta, no uso API.» Los modelos detrás de las interfaces de consumo también se cambian; solo que no recibes un 410 avisando — solo una salida distinta.
• «Si lo retiran, el sucesor será mejor.» El sucesor es distinto. Tus prompts, tu ajuste de temperatura y el procesamiento montado sobre el formato de salida estaban afinados para el anterior. Por eso la comparación va antes del cambio, no después.

Lo que conviene llevarse

La retirada de modelos no es un fallo, sino el funcionamiento normal del servicio: donde se publica un ciclo de vida de 18 meses, cada modelo se sustituye en año y medio — y eso es el máximo declarado, no la media. Hay tres cosas que sí controlas: saber qué modelo mueve cada cosa, usar identificadores versionados donde importe la estabilidad y mirar una vez por semana la página de retiradas que te afecta. El resto es asunto del proveedor — y su plazo conviene leerlo antes de que tu proceso dependa de él.