El costo recurrente de la IA en producción no es la inferencia. Es la recualificación: las reevaluaciones, el reajuste de prompts y las pruebas de regresión que debes cada vez que un modelo cambia bajo tus pies. El correo llegó un martes.

Un modelo que habíamos estado ejecutando en producción durante la mayor parte de un año, fijado a una versión específica a propósito, estaba siendo deprecado. Teníamos una ventana para migrar. Después de eso, el endpoint comenzaría a devolver errores.

Habíamos hecho todo lo que el manual de ingeniería cuidadosa te dice que hagas. No flotábamos en un alias más reciente que pudiera cambiar bajo nosotros de la noche a la mañana. Fijamos la versión exacta del modelo, la escribimos en la configuración y la tratamos como cualquier otra dependencia que no queríamos que se moviera sin una revisión.

La fijación debía ser la opción segura. El aviso de deprecación dejó claro algo que la fijación había estado ocultando silenciosamente: fijar una versión del modelo no te compra inmunidad al cambio. Te compra un retraso.

El suelo sigue moviéndose. Solo puedes elegir el martes. Esa distinción es el costo más subpresupuestado en la IA en producción.

Los equipos modelan su gasto en IA como inferencia: tokens de entrada, tokens de salida, por precio. Optimizan la elección del modelo, optimizan la longitud del prompt, discuten si el modelo más barato es suficientemente bueno. Casi nadie tiene una línea en el presupuesto para el día en que el modelo cambia y todo el sistema tiene que ser probado como correcto de nuevo.

Voy a llamar a esa línea el impuesto de recualificación, y al final de este artículo quiero que tengas tanto un nombre para él como una forma de planificar en torno a él. De qué te protege realmente la fijación, y de qué no Fijar una versión del modelo es genuinamente una buena práctica. Detiene la deriva silenciosa de comportamiento, donde un proveedor actualiza los pesos detrás de un alias y tus salidas cambian sin que una sola línea de tu código cambie.

Si alguna vez has visto una puntuación de evaluación moverse sin razón que puedas encontrar en tus propios commits, ya sabes por qué los equipos fijan. Pero una fijación es un candado en tu lado de una puerta que el proveedor también controla. Los proveedores deprecan.

En 2026 la cadencia, si acaso, se ha acelerado: nuevos modelos frontera se lanzan cada pocos meses, los más antiguos se retiran, y varios proveedores han retirado modelos con poca antelación. La mayoría de los equipos no están ejecutando un solo modelo de todos modos. La realidad actual, corroborada en encuestas de ingeniería a lo largo del año, es que los stacks de producción mantienen varios modelos en vuelo a la vez: un modelo frontera para razonamiento difícil, un modelo más barato para llamadas rutinarias, a veces un modelo autoalojado para datos que no pueden salir del edificio.

Cada uno de esos está en su propio reloj de deprecación. Así que la fijación no elimina el cambio. Convierte un cambio impredecible en uno programado.

Eso es una mejora real, porque un cambio programado es algo para lo que puedes asignar personal y presupuesto. Solo es un desastre cuando trataste la fijación como permanencia y no pusiste nada en el plan para el día en que expira. Lo que todos olvidan cotizar: el modelo no es lo único que cambia Aquí está la parte que hace que la recualificación sea costosa en lugar de trivial.

Cuando pasas de una versión del modelo a la siguiente, el modelo no es una pieza intercambiable. Casi todo lo que construiste sobre el modelo antiguo estaba, lo hayas querido o no, ajustado al comportamiento específico de ese modelo. Tus prompts estaban ajustados a él.

La frase que producía de manera fiable salida estructurada en el modelo antiguo puede producir algo sutilmente diferente en el nuevo. Tus ejemplos de pocos disparos estaban calibrados a sus peculiaridades. Tus barreras de seguridad estaban configuradas contra sus modos de fallo.

Tus analizadores de salida estaban endurecidos contra las formas específicas que tendía a devolver. Tu temperatura y y...