Diseño para la deprecación de modelos con modelos virtuales y transiciones por etapas

El 23 de julio de 2026, OpenAI tiene programado cerrar 15 entradas de modelos listadas —una mezcla de instantáneas y alias obsoletos que abarcan las API de Codex, chat, deep-research, búsqueda, audio, tiempo real y uso de computadora, según su página de depreciaciones. La tarea inmediata es la migración. El problema de ingeniería duradero es la propiedad de las dependencias: el código de la aplicación no debería depender directamente de identificadores cuyos ciclos de vida están controlados por un proveedor de modelos.

Esta publicación describe un patrón operativo más seguro: inventariar el uso actual, colocar un alias de modelo virtual estable entre las aplicaciones y los modelos del proveedor, evaluar los reemplazos frente a pruebas específicas de la carga de trabajo, cambiar el tráfico sincrónico a través de un canario ponderado y preservar una ruta de reversión rápida.

1. Lea el calendario como un SRE

La página de depreciaciones de OpenAI define la semántica directamente: un modelo se vuelve depreciado en el momento del anuncio —todavía funciona, pero ahora tiene una fecha de cierre— y una vez cerrado, las solicitudes dirigidas a él ya no se resuelven. La política de notificación publicada es de al menos seis meses para modelos de disponibilidad general y al menos tres meses para variantes especializadas como Codex y los modelos chat-latest. Los modelos de vista previa pueden recibir notificaciones con tan solo dos semanas de antelación, y OpenAI desaconseja explícitamente el uso de vistas previas para cargas de trabajo de producción críticas para el negocio, a menos que el equipo pueda migrar rápidamente (página de depreciaciones de OpenAI).

El anuncio del 22 de abril estableció dos lotes de cierre concentrados: 15 entradas listadas el 23 de julio, y el 23 de octubre un conjunto adicional de instantáneas y alias heredados de GPT-3.5, GPT-4, GPT-4 Turbo, GPT-4.1 Nano, GPT-4o y la serie o, junto con gpt-image-1 y varias familias de modelos base ajustados. Tenga en cuenta lo que no es el 23 de octubre: no es toda la familia GPT-4, y no es toda la serie o —las versiones fechadas o3-2025-04-16 y o3-pro-2025-06-10 las instantáneas se enumeran por separado para el 11 de diciembre, y solo la gpt-4o-2024-05-13 instantánea aparece de la línea GPT-4o.

La secuencia de modelos de imagen merece atención como precedente. Cuando DALL·E 2 y 3 cerraron el 12 de mayo, OpenAI había enumerado gpt-image-2, gpt-image-1, o gpt-image-1-mini como reemplazos recomendados. Los equipos que seleccionaron gpt-image-1-mini ahora deben migrar de nuevo antes de su cierre el 1 de diciembre, y gpt-image-1 tiene programado su cierre para el 23 de octubre. La lección se generaliza: el objetivo de la migración también puede estar en el calendario, y una arquitectura cuya respuesta a la obsolescencia sea editar cadenas de modelos en todas partes y volver a implementar repetirá ese trabajo al ritmo del proveedor.

Tampoco es este el patrón de un solo proveedor. Anthropic enumera a Claude Opus 4.1 para su retiro el 5 de agosto de 2026, con una política documentada de al menos 60 días de aviso para los modelos lanzados públicamente (obsolescencia de modelos de Anthropic). Google enumera el 16 de octubre de 2026 como la fecha de cierre más temprana para Gemini 2.5 Pro, Flash y Flash-Lite, y un modelo de vista previa: gemini-3.1-flash-lite-preview — estuvo activo del 3 de marzo al 25 de mayo de 2026, menos de tres meses desde su lanzamiento hasta su cierre (Deprecaciones de Gemini). La propia documentación de la API de DeepSeek indica que los alias heredados deepseek-chat y deepseek-reasoner serán deprecados el 24 de julio de 2026, asignándolos por compatibilidad a los modos de razonamiento y sin razonamiento de deepseek-v4-flash; no identifica esa fecha como un cierre (Modelos y precios de DeepSeek). Estos cuatro proveedores publican cambios activos en el ciclo de vida de sus modelos; sus periodos de aviso y asignaciones de migración difieren.

2. El problema del inventario: no puedes migrar lo que no puedes encontrar

Toda guía de migración comienza con "audita tu uso", y todo equipo de plataforma sabe por qué ese paso se pasa por alto: los ID de los modelos se esconden en configuraciones de servicios, constantes en notebooks, pipelines de CI, valores predeterminados de frameworks, archivos de configuración de agentes de codificación y herramientas de terceros que nadie recuerda haber adoptado. Grep encuentra las cadenas en tus repositorios; pero no encuentra el volumen, el propietario ni el tráfico que se origina fuera del control de versiones. El censo fiable es observacional: si cada llamada a un modelo pasa por una única puerta de enlace, entonces el uso por modelo —desglosado por equipo, aplicación, usuario y cuenta virtual, con su coste asociado— es una consulta de panel, y la pregunta "¿quién sigue llamando a este modelo que se retira?" tiene una respuesta en tiempo real con nombres y cifras en dólares. La propia guía de Anthropic apunta en la misma dirección, recomendando a los clientes exportar auditorías de uso por clave y por modelo antes de migrar. Ese censo es también la función de priorización: un modelo con tres llamadas residuales al día desde un trabajo por lotes olvidado es un ticket; uno que soporta una función orientada al cliente con un coste de seis cifras al mes es un proyecto.

‍

‍