¿Qué pasa si el proveedor de IA que uso en mi negocio sube el precio o deja de funcionar?

Un cliente de logística nos escribió hace un par de meses bastante nervioso: había leído que un proveedor grande de IA le había subido el precio a ciertos clientes empresariales sin previo aviso, y quería saber si a él le podía pasar lo mismo con el asistente que le montamos para clasificar incidencias de reparto. Le dije la verdad, que sí. No habíamos hablado de ese riesgo al firmar el proyecto. Ni él ni nosotros.

Meter un modelo de IA en un negocio es meter una dependencia nueva, y de las gordas. No es como depender de un hosting, que puedes cambiar en una tarde copiando archivos de un sitio a otro. Cuando un asistente lleva meses funcionando con un modelo concreto, el texto de las instrucciones que le das (el “prompt”) está afinado para las manías de ese modelo en particular: cómo interpreta las fechas, cuánto se explaya si no le pones límite, qué ejemplos necesita para no salirse del guion. Cambiar de proveedor no es cambiar una clave de API. Es volver a probar media lógica del asistente desde cero. En resumen: si tu negocio depende de un proveedor de IA concreto y ese proveedor sube el precio, cambia de modelo o deja de dar soporte, migrar no es solo cambiar una clave de API, es volver a ajustar el prompt y probar de nuevo buena parte de la lógica del asistente.

Nos pasó de verdad con un cliente de seguros. El modelo que usábamos dejó de estar disponible en su versión antigua (deprecated, que dicen ahora) y tuvimos que migrar el asistente a la versión nueva en tres semanas, con fecha límite fijada por el proveedor, no por nosotros. La lógica general seguía funcionando, pero el tono cambió: el modelo nuevo era más seco, respondía más corto, y tuvimos que retocar el prompt entero para que volviera a sonar parecido a como sonaba antes. Tres días de trabajo que nadie había presupuestado.

Desde entonces intento explicar esto en cada proyecto nuevo que depende de IA de forma seria, no como funcionalidad decorativa de escaparate. Dos cosas ayudan bastante. Una, no meter la lógica de negocio dentro del prompt si se puede evitar: las reglas duras (qué precio aplicar, qué plazo hay que cumplir) van en código normal de toda la vida, y el modelo se encarga solo de la parte de lenguaje. Así, si mañana cambia el modelo, lo que se rompe es el tono, no el cálculo. Dos, escribir el código de forma que cambiar de proveedor sea sustituir una función, no reescribir la aplicación entera. Nada del otro mundo, pero pocos clientes lo piden, porque nadie les ha contado que hace falta pedirlo.

Lo que no tengo tan claro es cuánto de esto merece la pena montarlo desde el primer día en un proyecto pequeño. Esa capa de abstracción cuesta horas que el cliente nota en la factura, y para un asistente sencillo de una pyme igual es pagar un seguro que nunca va a hacer falta usar. Para el cliente de seguros mereció la pena, visto con perspectiva. Para el de las incidencias de reparto, la verdad, todavía no lo sé.