El modelo sobre el que se ejecuta tu flujo de trabajo hoy tiene una fecha de retirada, la hayas leido o no. Cuando un proveedor retira una version o la actualiza en silencio en su sitio, los prompts que ajustaste, las evaluaciones en las que confias y los costes que presupuestaste pueden cambiar todos sin que tu modifiques una linea de codigo. Tratar eso como una nota al pie en las notas de version de un proveedor es la forma en que un agente en produccion se rompe un martes sin que nadie sepa explicar por que.
Esta entrada expone lo que los principales proveedores han hecho realmente entre 2024 y 2026, por que la “deriva de comportamiento” (el mismo prompt produciendo una salida distinta tras una actualizacion del modelo) es dificil de detectar, y el manual que los equipos regulados usan para mantener el control del ciclo de vida del modelo en lugar de estar sometidos a el.
¿Es la retirada de modelos realmente un evento programado, o un caso excepcional?
Es programada, es rutinaria y esta publicada. No es un riesgo hipotetico contra el que te aseguras. Es un evento operativo recurrente con fechas concretas.
La politica de retirada de OpenAI se compromete a periodos minimos de aviso: al menos 6 meses para modelos de disponibilidad general, al menos 3 meses para variantes especializadas y tan solo 2 semanas para modelos preview (cualquiera con preview en el nombre). OpenAI afirma con claridad que los modelos preview no se recomiendan para “cargas de produccion criticas para el negocio salvo que puedas migrar con poco margen.” Ejemplos reales de la lista publicada: gpt-4-32k y sus instantaneas con fecha se anunciaron para retirada el 6 de junio de 2024 y se apagaron el 6 de junio de 2025; gpt-4.5-preview se anuncio el 14 de abril de 2025 con apagado el 14 de julio de 2025, una ventana de tres meses.
Anthropic publica una pagina de retiradas de modelos paralela con un ciclo de vida de cuatro etapas (Active, Legacy, Deprecated, Retired) y un compromiso de “al menos 60 dias de aviso antes de la retirada del modelo para los modelos publicados.” Claude Opus 3 (claude-3-opus-20240229) se retiro de forma anticipada el 30 de junio de 2025 y se retiro definitivamente el 5 de enero de 2026. Claude Sonnet 4 y Opus 4 (las instantaneas 20250514) se marcaron como deprecated el 14 de abril de 2026 con fecha de retirada el 15 de junio de 2026.
La cuestion no es que estos proveedores se comporten mal. Ambos publican sus calendarios, dan aviso y recomiendan reemplazos. La cuestion es que una fecha de retirada es una propiedad de cada modelo que usas, el reloj siempre esta corriendo, y “ya lo gestionaremos cuando llegue el correo” no es un plan cuando el correo te da 60 dias para revalidar un flujo de trabajo regulado.
¿Que es la deriva de comportamiento, y por que es mas dificil que la retirada?
La retirada es el riesgo ruidoso. Recibes un correo, una fecha y un reemplazo recomendado. La deriva de comportamiento es el silencioso: el modelo cambia manteniendo el mismo nombre, de modo que nada en tu codigo ni en el changelog de tu proveedor te indica que algo se movio.
El caso documentado mas claro es anterior a la generacion actual pero sigue siendo la referencia canonica. En 2023, los investigadores Lingjiao Chen, Matei Zaharia y James Zou publicaron How is ChatGPT’s behavior changing over time?. Ejecutaron las versiones de marzo de 2023 y junio de 2023 de GPT-4 sobre las mismas tareas. En la identificacion de numeros primos frente a compuestos, la precision cayo del 84% en marzo al 51% en junio. El articulo tambien encontro que la proporcion de generaciones de codigo directamente ejecutable cayo bruscamente en esa misma ventana. El modelo se llamo “GPT-4” todo el tiempo. La conclusion de los autores es la frase que todo responsable de operaciones deberia interiorizar: “el comportamiento del ‘mismo’ servicio LLM puede cambiar sustancialmente en un periodo de tiempo relativamente corto.”
¿Por que es esto mas dificil de gestionar que una retirada?
- Una retirada tiene una fecha y una notificacion. La deriva, cuando un modelo se actualiza en su sitio detras de un alias estable, puede no tener ninguna de las dos.
- Los alias la ocultan. La documentacion de OpenAI distingue las instantaneas fijadas (una version con fecha como
gpt-4o-2024-05-13) de los alias no fijados (un puntero dinamico comogpt-4oque puede moverse). Si tu codigo llama al alias, heredas lo que el proveedor decida apuntar a continuacion. - Es invisible a la inspeccion. No puedes leer un prompt y ver que ahora se comportara de forma distinta. El cambio solo aparece en las salidas, frente a entradas reales, a nivel de distribucion.
¿Como detectarias siquiera que un modelo cambio por debajo?
No leyendo las notas de version, ni revisando a mano unos pocos prompts. Detectas la deriva igual que detectas una regresion en cualquier otra dependencia de software: con una bateria de pruebas que se ejecuta en cada cambio. Para modelos, esa bateria es un conjunto de evals de regresion.
Un conjunto de evals de regresion es una coleccion fija de entradas representativas con un comportamiento esperado conocido como correcto, puntuado automaticamente, que ejecutas siempre que el modelo cambia (una nueva version, una migracion forzada o una revision rutinaria). El detalle critico para los equipos regulados: construyelo a partir de tus propias trazas reales, no de un benchmark publico generico. Un benchmark publico te dice que el modelo es bueno en las tareas de otra persona. Tus trazas te dicen si todavia maneja tus reclamaciones, tus clausulas contractuales o tus cartas de autorizacion previa como lo hacia el mes pasado.
| Enfoque | Que detecta | Que se le escapa |
|---|---|---|
| Leer el changelog del proveedor | Retiradas anunciadas y cambios de version mayores | Actualizaciones en su sitio, movimientos silenciosos de alias, cambios sutiles de comportamiento |
| Revisiones manuales puntuales | Fallos groseros y evidentes en un punado de casos | Deriva a nivel de distribucion; el 5% de casos que ahora fallan |
| Benchmarks publicos | Capacidad general del nuevo modelo | Si todavia rinde en tu flujo de trabajo especifico |
| Conjunto de evals de regresion a partir de tus trazas | Cambio de comportamiento especifico de la tarea, antes de que llegue a los usuarios | Solo tan bueno como la cobertura de tu muestra de trazas |
La disciplina aqui es la misma que describimos en coste por tarea completada: el numero que importa se mide frente a tu trabajo real, no frente a la demo de un proveedor. Una bateria de regresion es la contraparte de calidad de esa disciplina de coste. Combina ambas y un cambio de modelo se convierte en un evento medido con un aprobado o suspenso, no en una sorpresa que tus usuarios reportan por ti.
¿Cual es el manual empresarial para mantener el control?
El objetivo es convertir un evento externo que no puedes programar en uno interno que si puedes. Tres controles, en orden creciente de cuanto reducen tu exposicion.
Fija la version, nunca llames a un alias movil
Llama siempre a una instantanea con fecha, nunca a un alias flotante, en cualquier flujo de trabajo que haya sido validado. Fijar no detiene la retirada (la instantanea sigue teniendo una fecha de retirada), pero elimina por completo la clase de sorpresa de actualizacion silenciosa. Un modelo fijado cambia cuando tu lo cambias. Trata el identificador del modelo como tratas la etiqueta de una imagen de contenedor: una version especifica que tu build referencia, registrada en el control de versiones, nunca latest.
Manten un conjunto de evals de regresion construido a partir de trazas reales
Manten el conjunto de evals descrito arriba como un activo vivo. Actualizalo a medida que tu trafico cambia para que siga representando trabajo real. Cuando llega un aviso de retirada o se publica una nueva version, ejecutas la bateria contra el candidato y lees un diff, no una intuicion. Esto es lo que convierte el reloj de 60 dias del proveedor de una carrera contrarreloj en una lista de comprobacion.
Prefiere despliegues en los que tu controlas el ciclo de vida
El control mas fuerte es sacar el ciclo de vida del calendario del proveedor. Dos formas de hacerlo:
- Pesos abiertos en tu propio entorno. Un modelo cuyos pesos posees y ejecutas dentro de tu VPC, tu infraestructura on-premise o tu nube soberana no es retirado por un tercero. Actualizas cuando tus evals dicen que la nueva version es al menos tan buena, no cuando una fecha externa te obliga. Ademas mantienes los datos regulados dentro de tu frontera de confianza, que es la misma razon por la que los equipos regulados mantienen la IA en casa en primer lugar.
- Fijacion de version por contrato. Cuando un modelo alojado es inevitable, negocia una ventana de soporte definida y terminos de aviso anticipado en el contrato, en lugar de depender de una pagina de politica publica que puede cambiar.
¿Donde encaja la torre de control?
Una torre de control es la capa operativa que registra cada ejecucion del agente (las entradas, el modelo y la version, las llamadas a herramientas, el coste y la salida) y te permite reproducir cualquier ejecucion concreta despues. Esa capacidad es lo que hace que el manual anterior sea exigible en lugar de aspiracional.
Cuando una version de modelo cambia, la reproduccion es la diferencia entre “algo va mal” y “aqui esta el diff exacto.” Reejecutas tu conjunto de regresion contra la version candidata y comparas, ejecucion por ejecucion, contra la linea base registrada. Ves que casos se movieron, en cuanto y sobre que tipo de entrada. Como cada ejecucion ya lleva su identificador de modelo, tambien puedes demostrar que flujos de trabajo siguen llamando a una instantanea proxima a retirarse, la misma auditoria que Anthropic recomienda que los equipos ejecuten contra su propio uso antes de una fecha de retirada.
Para flujos de trabajo regulados, ese historial registrado y reproducible es ademas el rastro de auditoria. Cuando un regulador, un auditor o la asesoria juridica pregunta “que modelo produjo esta decision, y produciria la misma hoy,” la respuesta honesta requiere una version fijada y una traza que puedas reproducir. La plataforma de Proqtor esta construida para mantener esa evidencia dentro de tu entorno, y nuestra postura de seguridad documenta como se mantiene esa frontera. Para el patron mas amplio de mantener la IA dentro de la frontera, consulta la discusion de la frontera de confianza a lo largo de nuestras demas notas.
Preguntas frecuentes
¿Cuanto aviso dan realmente los proveedores de modelos antes de retirar un modelo?
Varia segun el proveedor y el nivel del modelo, y esta documentado. OpenAI se compromete a al menos 6 meses para modelos de disponibilidad general, al menos 3 meses para variantes especializadas y tan solo 2 semanas para modelos preview. Anthropic se compromete a al menos 60 dias para modelos publicados. Ambos notifican por correo a los clientes afectados y listan fechas en sus paginas publicas de retirada. La implicacion practica: lee esas paginas con regularidad y trata los modelos preview como inadecuados para flujos de trabajo que no puedas migrar rapidamente.
¿Cual es la diferencia entre un modelo retirado y la deriva de comportamiento?
La retirada es una baja anunciada: el modelo desaparece en una fecha conocida y tu migras a un reemplazo. La deriva de comportamiento es cuando un modelo cambia manteniendo el mismo nombre, de modo que el mismo prompt devuelve una salida distinta sin cambio de version y a veces sin aviso. La retirada es ruidosa y programada; la deriva es silenciosa y solo visible en las salidas. Gestionas la retirada siguiendo fechas y fijando versiones; detectas la deriva con un conjunto de evals de regresion ejecutado en cada cambio.
¿Fijar una version de modelo protege por completo mi flujo de trabajo?
No, y ese es el limite honesto. Fijar una instantanea con fecha elimina el riesgo de actualizacion silenciosa en su sitio, que es el mas insidioso, pero la instantanea sigue teniendo una fecha de retirada fijada por el proveedor. El control completo sobre el ciclo de vida requiere o bien pesos abiertos que ejecutas dentro de tu propio entorno, donde ningun tercero puede retirar tu modelo, o bien terminos contractuales que fijen una ventana de soporte. Fijar mas un conjunto de evals de regresion es el minimo solido; ser dueno del despliegue es la respuesta duradera.