Que pasa se o provedor de IA que uso no meu negocio sobe o prezo ou deixa de funcionar?

Un cliente de loxística escribiunos hai un par de meses bastante nervioso: lera que un provedor grande de IA lle subira o prezo a certos clientes empresariais sen avisar, e quería saber se lle podía pasar o mesmo co asistente que lle montamos para clasificar incidencias de reparto. Díxenlle a verdade, que si. Non falaramos dese risco ao asinar o proxecto. Nin el, nin nós.

Meter un modelo de IA nun negocio é meter unha dependencia nova, e das gordas. Non é como depender dun hosting, que podes cambiar nunha tarde copiando ficheiros dun sitio a outro. Cando un asistente leva meses funcionando cun modelo concreto, o texto das instrucións que lle das (o “prompt”) está afinado para as manías dese modelo en particular: como interpreta as datas, canto se explaia se non lle pos límite, que exemplos precisa para non saírse do guión. Cambiar de provedor non é cambiar unha clave de API. É volver probar media lóxica do asistente desde cero. En resumo: se o teu negocio depende dun provedor de IA concreto e ese provedor sobe o prezo, cambia de modelo ou deixa de dar soporte, migrar non é só cambiar unha clave de API, é volver axustar o prompt e probar de novo boa parte da lóxica do asistente.

Pasounos de verdade cun cliente de seguros. O modelo que usabamos deixou de estar dispoñible na súa versión antiga (deprecated, que din agora) e tivemos que migrar o asistente á versión nova en tres semanas, cunha data límite fixada polo provedor, non por nós. A lóxica xeral seguía funcionando, pero o ton cambiou: o modelo novo era máis seco, respondía máis curto, e tivemos que retocar o prompt enteiro para que volvese soar parecido a como soaba antes. Tres días de traballo que ninguén orzamentara.

Desde entón intento explicar isto en cada proxecto novo que depende de IA de forma seria, non como funcionalidade decorativa de escaparate. Dúas cousas axudan bastante. Unha, non meter a lóxica de negocio dentro do prompt se se pode evitar: as regras duras (que prezo aplicar, que prazo hai que cumprir) van en código normal de toda a vida, e o modelo encárgase só da parte de linguaxe. Así, se mañá cambia o modelo, o que se rompe é o ton, non o cálculo. Dúas, escribir o código de xeito que cambiar de provedor sexa substituír unha función, non reescribir a aplicación enteira. Nada do outro mundo, pero poucos clientes o piden, porque ninguén lles contou que fai falta pedilo.

O que non teño tan claro é canto disto merece a pena montalo desde o primeiro día nun proxecto pequeno. Esa capa de abstracción custa horas que o cliente nota na factura, e para un asistente sinxelo dunha pequena empresa quizais sexa pagar un seguro que nunca vai facer falta usar. Para o cliente de seguros mereceu a pena, visto con perspectiva. Para o das incidencias de reparto, a verdade, aínda non o sei.