Què cal preguntar abans de comprar qualsevol eina d’IA

Comprar una eina d’IA és fàcil. Conviure-hi durant dos anys és la part difícil. Gairebé totes les demos funcionen: estan preparades amb dades netes, amb el cas d’ús més favorable i amb algú al davant que se sap el producte de memòria. El cost real apareix després, quan cal connectar les dades que existeixen de debò, encaixar l’eina en el flux de treball, explicar a l’equip què fa i decidir què es farà el dia que s’equivoqui.

Això no és un problema exclusiu de les empreses grans amb departament de compres. Una pime que contracta un bot de conversa, un assistent de facturació o un agent de veu s’enfronta exactament al mateix risc, només que sense un departament legal que revisi el contracte abans de signar-lo. El que segueix són les preguntes que fem nosaltres abans de recomanar una eina. No són un formulari de compres: són els cinc punts on, quan alguna cosa va malament, gairebé sempre ja anava malament des de la signatura.

Què passa amb les meves dades si vull marxar?

La resposta que cal aconseguir per escrit: les dades marxen amb tu, en un format que un altre sistema pugui llegir, amb l’historial complet i sense dependre de la bona voluntat del proveïdor. Tota la resta d’aquesta secció és com comprovar que aquesta frase és veritat.

La primera pregunta no és per les funcionalitats: és per la sortida, perquè aquesta resposta condiciona tot el que vingui després.

Traduïda a una empresa petita sona així: si deixo de pagar l’any que ve, em puc endur les dades, les instruccions que hem anat afinant i l’historial de converses, o es queden dins de la plataforma?

Convé baixar un nivell més, perquè «sí, es pot exportar» admet respostes molt diferents: exportar en quin format, amb quins camps, en quant de temps i qui ho fa. Una assessoria que fa dos anys que resol consultes de clients amb un assistent hi té un actiu real; si l’exportació és un PDF per conversa, aquell actiu no existeix.

En la mateixa conversa hi caben dues preguntes més, i totes dues són de sí o no. Les nostres dades es fan servir per entrenar el model del proveïdor? Qui escriu i manté el codi que connecta l’eina amb els nostres sistemes? Si la resposta a la segona és «el vostre informàtic», el proveïdor no ven una plataforma: ven una peça que algú de casa haurà de muntar i mantenir.

La integració és real o és un pedaç?

És real si l’eina d’IA llegeix i escriu directament en el programa on ja hi ha la feina; és un pedaç si mou fitxers o dades per una capa intermèdia que algú ha de vigilar.

«Més de mil integracions» no diu res: només n’importa una, i hi ha dues coses molt diferents que s’expliquen amb la mateixa paraula. Una connexió nativa llegeix i escriu dades en aquell programa. Un connector genèric muntat sobre una capa intermèdia mou informació d’un lloc a un altre quan es compleix una condició, i algú l’ha d’arreglar cada vegada que canvia un camp.

Per a una gestoria o un despatx la pregunta és molt concreta: aquesta eina pot llegir i escriure directament en el programa de gestió que ja fem servir, o necessitarà que algú exporti i importi fitxers a mà cada setmana? Si la resposta inclou la paraula «exportar», l’eina no treu aquella feina: la canvia de lloc i afegeix un punt més on fallar.

La manera de comprovar-ho és demanar noms. Quin camp concret s’escriu, en quina pantalla apareix, què passa si dues persones toquen el mateix registre alhora. Un proveïdor que ja ha fet aquella integració respon en un minut; un que no l’ha feta respon amb el nombre d’integracions que té.

Què passa quan falla?

La pregunta no és si falla — tota eina d’IA decideix per probabilitats i, per tant, falla —, sinó si l’error es veu, es reconeix i acaba en mans d’una persona amb el context al davant.

Tota demo es prepara amb les preguntes que el sistema respon bé. La prova que de debò informa és la contrària: fer davant del proveïdor una pregunta que l’eina clarament no hauria de saber respondre, i mirar què fa. Diu que no ho sap, o improvisa una resposta amb aplom? Deriva a una persona? I quan deriva, aquella persona rep la conversa completa, o el client ho ha de tornar a explicar tot des del principi?

En atenció al client i en agents de veu, aquesta diferència és gairebé tot el producte. Un error ben gestionat és invisible: el client percep que el passen amb algú que ja sap de què va l’assumpte. Un error mal gestionat és el motiu pel qual un client s’enfada amb la marca, no amb la tecnologia, i aquella conversa no la recupera després cap millora del model.

Què es pot exigir de debò a un proveïdor?

Concreció, no percentatges.

Aquí convé desmuntar un consell que es repeteix molt: que el proveïdor t’ha de donar xifres de clients semblants a tu. Sona exigent i és el contrari. Un percentatge d’estalvi és el més fàcil de produir i el més difícil de comprovar que hi ha: ningú no publica els projectes que van sortir malament, la majoria d’aquests números no tenen al darrere ni una mesura prèvia ni un mètode, i un «un 40% menys de temps» sense el procés al qual es refereix no es pot contrastar ni reproduir.

Nosaltres tampoc no publiquem percentatges de clients, de manera que tampoc no recomanem demanar-los a ningú com a prova.

La concreció exigible, on un proveïdor solvent es distingeix en cinc minuts: quin procés s’automatitza i quin no, amb quines dades treballa el sistema, què decideix sol i què deixa en mans d’una persona, què passa quan s’equivoca i qui ho detecta, quanta feina hi ha per part nostra abans que allò funcioni, i com se’n surt. Si a «quant de temps estalvia això a la pràctica» la resposta és una xifra rodona en lloc de «depèn de quants casos entrin per aquell canal i de com estiguin avui», el problema no és la modèstia: és que ningú no ha mirat el procés.

És la mateixa diferència que hi ha entre un catàleg i una auditoria integral d’IA: mirar el procés, les dades que hi ha i què passa quan el sistema s’equivoca. Cap d’aquestes tres coses no es respon amb un percentatge.

Compleix el que la llei ja exigeix?

A la Unió Europea això ja no és opcional, i no cal explicar-ho com una amenaça. Qualsevol eina que parli amb clients, faci servir veu o generi contingut automatitzat hauria de poder explicar en quina categoria de risc se situa segons el Reglament (UE) 2024/1689 i quines obligacions de transparència compleix. Un proveïdor europeu que treballa seriosament ho té respost per escrit i ho envia sense que calgui insistir.

Preguntar-ho abans de signar estalvia refer un procés després. El punt que afecta més empreses és l’article 50, l’obligació de transparència del qual s’aplica des del 2 d’agost de 2026: avisar que s’està parlant amb un sistema automàtic i identificar el contingut generat per IA. Si el bot que es compra avui no permet configurar aquell avís on s’ha de llegir, el problema s’hereta amb l’eina. El calendari complet, amb el que es va ajornar i el que no, és a què canvia de debò a l’agost de 2026.

La pregunta que resumeix totes les altres

Abans de signar convé poder respondre tres coses sense recórrer a la intuïció: quin procés concret s’automatitza, què passa si el proveïdor apuja el preu o desapareix, i qui respon si l’eina s’equivoca davant d’un client. Si aquestes tres respostes no estan clares, encara no és el moment de comprar l’eina, per molt bé que s’hagi vist a la demo.

Dit de la manera més pràctica possible, són cinc frases que es poden llegir en veu alta a la reunió:

• «Si deixem de pagar al gener, què m’enduc i en quin format?»
• «Escriu directament en el nostre programa de gestió? En quin camp?»
• «Fes-li ara, aquí, una pregunta que no hauria de saber respondre.»
• «Què decideix el sistema pel seu compte i què deixa en mans d’una persona?»
• «Quina obligació de transparència compleix i on es configura l’avís?»

Cap de les cinc no requereix saber de tecnologia, i totes cinc es responen en una reunió. Un proveïdor que treballa bé les agraeix, perquè li estalvien un client descontent al sisè mes. Un que les esquiva ja ha respost.