Qué se rompe cuando cambia una API de IA y cómo enterarte antes

Hay tres cosas que pueden cambiar y sólo una avisa

La distinción es la que decide qué hay que vigilar, y casi nadie la hace explícita.

• El contrato técnico. Cambia un campo, se retira una versión. Rompe ruidosamente y se arregla rápido.
• Los límites de uso. Cambia la frecuencia permitida o el costo. Rompe a veces, y suele coincidir con el peor momento.
• El comportamiento del modelo. El mismo pedido devuelve una respuesta distinta. No rompe nada visible y es el que más daño hace.

El tercero es propio de la IA. Ninguna integración tradicional tiene esta categoría de fallo, y por eso ninguna práctica heredada la vigila.

Conviene entender por qué el tercero existe, porque explica que no se pueda tratar como un fallo corriente.

Un proveedor de modelos mejora su producto continuamente, y una mejora general puede ser un cambio de comportamiento para tu caso concreto. No es un error del proveedor: es que tu sistema dependía de un detalle que él nunca prometió mantener.

Esa asimetría es estructural. Lo único que la compensa es que tú midas lo que a ti te importa, porque nadie más lo va a medir.

Por qué el cambio de comportamiento es el caro

Un ejemplo concreto de los que se repiten. Un sistema clasificaba correos entrantes en cuatro categorías y funcionaba con una precisión razonable.

El proveedor actualizó el modelo. La API no cambió, el formato no cambió, no hubo un solo error en los registros. Lo que cambió fue que el modelo empezó a interpretar de otra manera un tipo de caso ambiguo.

El resultado fue que un 8 % de los correos empezó a caer en la categoría equivocada. Nadie lo detectó durante casi un mes, porque el sistema no falla: acierta distinto.

Qué partes de tu sistema dependen de la forma exacta

No todo lo que conecta con una API de IA es igual de frágil. Estas cuatro son las que más se rompen:

• Todo lo que parsea la respuesta. Si tu código busca un texto concreto dentro de lo que devuelve el modelo, cualquier cambio de redacción lo rompe.
• Los umbrales calibrados. Si ajustaste un valor de confianza probando, ese número vale para el modelo con el que lo probaste.
• Los prompts largos y afinados. Un prompt ajustado durante semanas contra una versión puede rendir distinto en la siguiente.
• Las estimaciones de costo. Cambian con el precio por unidad y con cuánto texto devuelve el modelo, que también varía.

La primera se resuelve pidiendo salida estructurada en vez de texto libre, que es la medida técnica con mejor relación entre esfuerzo y protección.

Hay una quinta dependencia que casi nadie anticipa: el tiempo de respuesta.

Un modelo nuevo puede ser mejor y más lento, o tardar distinto según la carga del proveedor. Si tu sistema tiene un límite de espera ajustado al comportamiento anterior, empieza a cortar peticiones que antes llegaban.

El síntoma es confuso porque parece un problema de red, y la causa está en que el margen que había dejado de sobrar.

Cómo enterarse antes

Cuatro mecanismos, del más barato al más completo. Los dos primeros no cuestan nada y casi nadie los tiene.

El paso dos es el que más discusión genera y el que más protege. Fijar versión significa quedarse atrás a propósito, y a cambio significa que nada cambia bajo tus pies sin que tú lo decidas.

El cambio de límites, que llega sin aviso útil

Los límites de frecuencia y de volumen cambian con menos preaviso que el contrato técnico, y su efecto es inmediato.

El patrón típico: el sistema funciona bien durante meses, la empresa escala el uso a otra área y de golpe empiezan a aparecer errores en las horas pico. No es un fallo del código: es que se alcanzó un techo que nadie sabía que existía.

Lo que evita el susto son dos cosas simples: conocer el límite vigente y tener una respuesta prevista para cuando se alcance. Reintentar con espera, encolar o degradar a una versión más simple.

Un sistema que no tiene respuesta prevista para el límite simplemente falla delante del usuario, y esa es una decisión de diseño aunque nadie la haya tomado.

Qué dejar preparado desde el día uno

Cinco cosas que cuestan poco al principio y muchísimo después.

• Una capa propia entre tu sistema y la API. Todo pasa por ahí. Cambiar de proveedor toca un archivo, no veinte.
• Salida estructurada en vez de texto libre siempre que se pueda.
• El prompt versionado, en el repositorio y no dentro de una herramienta.
• Los casos de prueba guardados con su salida esperada.
• Un tope de gasto y una alerta, para que un cambio de precio no se descubra en la factura.

La primera es la que más ahorra y la que más se salta por prisa. Es también lo que hace viable cambiar de modelo de IA sin perder lo construido.

Sobre la tercera, versionar el prompt: no es una formalidad de proceso.

Cuando el comportamiento cambia, la primera pregunta es si cambió el modelo o si alguien tocó el prompt. Sin historial no hay forma de responderla, y el equipo pierde días buscando en el sitio equivocado.

Con el prompt en el repositorio, esa pregunta se responde en un minuto mirando el historial de cambios.

Cuando el proveedor retira una versión

Es el único cambio con fecha conocida, y aun así pilla a la mitad de las empresas.

El aviso llega con meses de antelación por correo, y muere en la bandeja de quien montó la integración, que a veces ya no trabaja ahí.

El mecanismo que funciona es aburrido: una revisión trimestral de las versiones en uso y sus fechas de retirada, en la misma reunión donde se mira el costo. Quince minutos al trimestre.

Hay un matiz que conviene conocer sobre estas fechas: cuando un proveedor retira una versión, el sistema no deja de funcionar de golpe en la mayoría de los casos.

Lo habitual es que redirija al modelo siguiente, que es peor que un error. Tu sistema sigue respondiendo, con un modelo que nunca probaste, y no hay ninguna señal de que algo cambió.

O sea que la fecha de retirada no es la fecha en que se rompe: es la fecha a partir de la cual estás corriendo sobre algo que no elegiste.

Quién tiene que estar mirando

Todo lo anterior es inútil sin una persona con el encargo explícito, y aquí es donde falla en la práctica.

El proveedor de la integración suele considerar terminado su trabajo al entregar. La empresa suele asumir que el proveedor sigue mirando. En medio no hay nadie, y el sistema envejece sin que nadie lo note.

Está desarrollado en quién mantiene las integraciones de IA, y es la pregunta que conviene dejar cerrada por contrato antes de la primera entrega.

La revisión trimestral, en quince minutos

Cinco preguntas, una vez cada tres meses, con una persona responsable de responderlas.

• ¿Qué versión de qué modelo estamos usando y hasta cuándo está soportada?
• ¿Cambió algo en el comportamiento desde la última revisión?
• ¿El costo por unidad sigue siendo el mismo?
• ¿Nos acercamos a algún límite de frecuencia o de volumen?
• ¿Los casos de prueba siguen dando el resultado esperado?

Cinco preguntas, quince minutos, y casi todos los incidentes de este territorio dejan de ocurrir. Es la parte más barata de operar IA y la que menos empresas hacen.

Un consejo sobre dónde poner esa revisión: en la misma reunión donde ya se mira el costo.

Una reunión nueva de quince minutos al trimestre se cancela a la segunda vez. Un punto añadido a una reunión que ya existe sobrevive, y es el mismo esfuerzo.