Pueden pasar dos cosas distintas
Un proveedor puede quitarte el modelo de dos maneras, y cada una pide una preparación completamente distinta.
Una es la retirada: desde una fecha dada el modelo no se puede llamar y la petición vuelve con error. Es incómodo pero honrado — te enteras al instante. La otra es el cambio silencioso: el nombre del modelo se queda, pero por detrás corre una versión actualizada, y la salida se desplaza sin que se note. Esa es la que pasa desapercibida durante meses.
El caso ruidoso: la retirada
Los grandes proveedores llevan un ciclo de vida para los modelos: activo → heredado → marcado para retirada → retirado. Un modelo marcado sigue funcionando, pero ya tiene fecha.
La práctica habitual es avisar con al menos 60 días para los modelos publicados, por correo y en la documentación. Un gran proveedor retiró así varios modelos a lo largo de 2026, cada uno con un sucesor designado. Y para los modelos activos se publica por adelantado una fecha de «no antes de» — o sea que puedes comprobar hasta cuándo es seguro lo que usas.
De ahí salen dos tareas, y las dos son de cinco minutos: suscríbete a los avisos y mira la página de retiradas cada trimestre. Con eso basta para que los 60 días no se conviertan en tres.
El caso silencioso, que es más peligroso
Si en tu código usas un nombre de modelo del tipo «último», sin versión, el proveedor puede actualizar por debajo cuando quiera. No falla nada. La llamada se completa, la respuesta llega, el sistema está en verde.
Solo que la salida ha cambiado. Más larga. Con otro formato. Le falta un campo. Más prudente en una pregunta límite. Si procesas respuestas en un flujo automatizado, esto pasa desapercibido días o semanas, porque cada uno supone que solo ese caso fue raro.
La defensa es sencilla: fija la versión exacta en producción, no el nombre flotante. El nombre flotante es cómodo mientras desarrollas; en producción es un riesgo.
Seis preparativos que puedes hacer ya
Ninguno es mucho trabajo, y los seis pagan cuando llega el problema:
- Versión fijada en producción. El nombre del modelo debe llevar versión exacta.
- El nombre del modelo en un solo sitio. Un valor de configuración, no repartido por veinte puntos del código. Cambiar es entonces una línea.
- Un conjunto de pruebas de veinte tareas, con las buenas respuestas escritas. Es el mismo conjunto que usas para elegir modeloal principio.
- Salidas de muestra guardadas. La buena respuesta de entonces, guardada — es con lo que compararás. Una entrada de la biblioteca de prompts tiene un campo justo para esto.
- Un segundo proveedor al alcance. No hace falta usarlo; basta con que existan el formato de llamada y el acceso. Para eso está un model router , entre otras cosas.
- Un responsable y una fecha. Que haya alguien a quien llegue el correo de retirada y que lo mire una vez al trimestre.
Lo que suele romperse
Al cambiar de modelo no cambia la «inteligencia» sino cinco cosas muy prosaicas:
- La forma de la salida. La misma petición da una respuesta con otra estructura — otros titulares, otra lista, otro orden.
- La longitud. El modelo nuevo es más o menos hablador, y si montaste sobre un límite de caracteres, eso se desplaza.
- El tono. Se vuelve más formal o más cercano, y ya no encaja en tus plantillas.
- El límite de rechazo. Lo que antes pasaba se vuelve dudoso, o al revés.
- El valor por defecto del razonamiento. Si el modelo nuevo piensa más de serie, crecen el tiempo de respuesta y la factura sin que hayas cambiado nada.
La receta de migración
Cuando llega el aviso, cuatro pasos, y no tiene por qué llevar más de media jornada:
- Pasa las veinte tareas por el modelo viejo y por el nuevo, con el mismo prompt.
- Compara con las salidas guardadas, no con tus recuerdos. Apunta las diferencias.
- Corrige el prompt, no te pongas a buscar otro modelo. La mayoría de las diferencias se reducen a la petición de formato y de longitud, que una frase puede restaurar.
- Ejecuta los dos en paralelo unos días antes de pasar a producción, si puedes. Comparar las dos salidas es la única prueba de verdad.
Si el modelo nuevo resuelve bien las mismas veinte o más, ya está. Si resuelve menos, entonces el problema no es el modelo sino un prompt ajustado al anterior — y eso tiene arreglo.
Cuando no puede cambiar nada
Hay sitios donde el cambio es en sí el problema: un proceso auditado, un compromiso contractual a largo plazo, investigación donde la reproducibilidad es un requisito.
Ahí un modelo cerrado es estructuralmente la elección equivocada, porque la retirada no la decides tú. Los modelos de pesos abiertos dan aquí una ventaja real: lo que descargaste correrá exactamente igual dentro de cinco años. A cambio, la operación es tuya — pero aquí la pregunta no es el precio, es si la cosa es posible siquiera.
Qué llevarte
La retirada es ruidosa y manejable; la actualización silenciosa es el riesgo de verdad. La defensa en producción es una versión fijada, un conjunto de veinte tareas y salidas de muestra guardadas — con eso, migrar es media jornada. Donde el cambio no está permitido en absoluto, un modelo de pesos abiertos descargado es la única respuesta estructuralmente correcta.