Una IA es dissenya per com falla, no pel que encerta

Una IA no es guanya el seu lloc pel que encerta. Se'l guanya pel que passa quan falla.

Quan un proveïdor ens ensenya el que la seva IA pot fer, ho fa en el format més favorable que existeix: la demo. Vint minuts en què un assistent llegeix dos-cents correus i n'encamina cadascun al seu comercial, o resumeix una trucada de quaranta minuts en quatre línies que entren soles a la fitxa del CRM, sense despentinar-se. I funciona. Assentim, calculem en veu baixa les hores que això estalvia —"això ens treu feina de sobre", "mira tot el que fa"—, i la conversa sencera gira al voltant d'una sola cosa: de què és capaç.

Però la capacitat no és la pregunta. Posada a prova així, gairebé qualsevol IA d'avui fa gairebé qualsevol cosa, i la fa bé. La pregunta és què passa quan s'equivoca —perquè s'equivocarà, i ho farà sense avisar, igual de convençuda que quan encerta—. El que separa una IA que acaba vivint a l'operació d'una que es queda per sempre a la demo és l'altra cosa. Posar una IA en un procés comercial no és triar on encerta. És decidir on ens podem permetre que s'equivoqui.

Comença pel cost de l'error, no per la capacitat

El reflex, després de veure una IA funcionar, és preguntar "pot fer això?". I gairebé sempre la resposta és que sí, de manera impressionant. El problema és que aquesta pregunta no és una decisió: és la condició de partida que la mateixa demostració ja dona per complerta. La primera decisió de veritat no és què és capaç de fer la IA, sinó quant costa que ho faci malament en aquesta tasca concreta. El manifest d'aquest blog desenvolupa la decisió que va abans —què li demanem al sistema i amb quin criteri—; aquí donem aquesta part per tancada i comencem per la següent.

La variable que mana no és amb quina freqüència s'equivoca —això no se sap del tot per endavant, i a més canvia amb el temps—. És una altra: quan una sortida surt malament, fins on arriba el dany i com és de reversible? Hi caben dues coses, aquí dins. L'abast: una sortida dolenta, es queda a casa, o toca un client, una dada de la qual pengen altres decisions, diners? I la reversibilitat: es caça i es desfà abans que importi, o quan un se n'assabenta ja ha sortit? La primera decisió en posar una IA en un procés no és on encerta: és el radi de dany d'una sortida dolenta.

El mateix model, exactament amb la mateixa capacitat, ocupa llocs molt diferents segons la tasca. En un extrem, el barat i reversible: un primer esborrany que un humà editarà de totes maneres —resumir una trucada a la fitxa, deixar una nota interna—. Una sortida dolenta costa dos minuts de correcció, i l'humà ja és a la porta. Al mig, el recuperable amb fricció: classificar i encaminar leads. Un error reparteix malament o retarda, s'arregla; però el risc de veritat no és la fallada solta, és el biaix sistemàtic que ningú veu fins que fa mesos que opera. I a l'altre extrem, el car i difícil de desfer: una dada que la IA extreu d'un document i que alimenta una oferta, o qualsevol cosa que surt cap a un client sense un humà pel mig. Una xifra inventada en una proposta enviada no es recupera amb un "perdó, error del sistema".

D'aquí que el primer sigui situar la tasca en aquest espectre. Aquesta única ubicació decideix el règim amb què la IA pot operar: on l'error és barat i reversible, pot córrer amb poca xarxa o amb cap; on és car o irreversible, no s'hi acosta sense la verificació i el disseny de fallada de què parlen els dos apartats següents —o, senzillament, encara no hi entra—. La pregunta de la capacitat no mou aquesta decisió ni un mil·límetre. La del cost de l'error la decideix sencera.

Com sabries que s'ha equivocat?

La fallada que de veritat costa diners no és la que es veu. Quan una IA es queda en blanc o retorna un disbarat evident, es delata sola: molesta, però es caça sense esforç. La cara és l'altra, la plausible-però-falsa: la sortida que sembla correcta i no ho és, dita exactament amb el mateix aplom que la correcta. Una IA no aixeca la mà quan no sap; produeix amb la mateixa seguretat encerti o no. Per això la pregunta útil en avaluar-la no és "funciona?", sinó una altra de força més incòmoda: sabríem quan no ha funcionat?

I aquí apareix la trampa. Una IA només aporta alguna cosa si comprovar que la seva sortida està bé costa menys que haver-la fet des de zero. Si per refiar-te'n has de refer la feina, no has automatitzat res: has mogut la feina de fer a revisar, i amb un pas de més pel camí. El valor de posar una IA en un procés no és en el que produeix, sinó que verificar que està bé surti barat. El contrari és productivitat fantasma: sembla que estalvies l'hora de redactar, però aquesta hora reapareix —o hauria de reaparèixer— en la de comprovar.

El que decideix si aquesta comprovació és barata de veritat o només ho sembla és l'asimetria: si verificar una resposta és més fàcil que produir-la. Quan l'asimetria juga a favor, hi ha una àncora contra la qual contrastar sense refer la feina: un total que ha de quadrar, un camp que només admet certs valors, una dada que es creua amb una altra font. Extreure un import d'una factura té el seu cost; comprovar que la suma quadra amb el total, cap. Quan no hi ha asimetria, arriba la il·lusió: per saber si el resum d'una trucada és fidel caldria tornar a escoltar-la sencera, i per saber si una classificació és correcta cal el mateix criteri que la IA venia a substituir. Aquí "revisar" es degrada a "fer-hi un cop d'ull", i un cop d'ull aprova just el plausible-però-fals, que és l'únic que calia caçar. Una verificació que no és més barata que la feina no és una verificació: és un segell de goma. I hi ha un cas a part, el del biaix: en tasques de volum —classificar, encaminar—, la fallada perillosa no és la individual sinó el patró sistemàtic, que cap comprovació peça a peça detecta. Aquí verificar no és mirar cada sortida, és auditar l'agregat cada cert temps.

La decisió, doncs, és on es posa l'humà i quant costa de veritat aquesta comprovació, sense enganyar-se sobre el segon punt. Creuat amb l'anterior: si una tasca ajunta cost de l'error alt i verificació cara o il·lusòria, no és candidata a IA encara —és, de fet, just on més confiança immerescuda donarà—. On l'error és barat, n'hi ha prou amb una verificació per mostreig, o amb cap. La pregunta no és "poso algú a revisar?". És si la revisió que de veritat ens podrem permetre atrapa la fallada que importa.

Dissenya-la perquè falli en veu alta

Cap verificació ho atrapa tot, i el que es cola és precisament el plausible-però-fals, que és el que millor passa els controls. Així que queda una última decisió, i no és com detectar millor la fallada: és què fa el sistema quan ell mateix no les té totes. Una IA mal muntada només té una manera de funcionar —produir, passi el que passi—, i un sistema que falla en silenci és el que surt més car, perquè quan un se n'assabenta ja ha actuat. Dissenyar-la perquè falli en veu alta és donar-li una manera de dir "això no ho tinc clar" abans de deixar anar la sortida.

El reflex és construir primer el camí feliç i deixar el què-passa-si-falla per a quan falli. Convé fer-ho al revés. Un pas amb IA en producció es dissenya primer per la seva sortida d'emergència —què fa amb allò que no hauria de resoldre—, no pel seu millor cas. Aquesta és, en el fons, la diferència entre una demo i un sistema: la primera només ensenya l'encert; el segon té decidida la fallada per endavant.

Hi ha tres maneres de fer que avisi en lloc d'inventar, i les tres són la mateixa idea aplicada en moments diferents. Abstenir-se: que "no ho sé" sigui una resposta vàlida i de primera classe, no un buit que el model omple endevinant. On l'error és car, una abstenció —"això que ho miri una persona"— val més que una resposta segura i equivocada; la majoria de les fallades que fan mal venen d'un sistema al qual mai se li va permetre dir que no se'n refiava. Escalar el dubtós, no tot: el valor és a triar, deixar que la IA corri sola on va sobrada i aixequi la mà on no. És el revers de la verificació de l'apartat anterior —ja que no es pot revisar tot, que sigui el mateix sistema qui digui què mirar—. Encaminar sols els leads clars i enviar a una persona els ambigus surt més barat i més fiable que revisar-ne els cent o no revisar-ne cap. Acotar el radi: contenir per disseny el que una sortida dolenta pot tocar. Que redacti però no enviï; que proposi però que un humà signi el cas límit; que escrigui en un camp de revisió i no directament en el que ja alimenta l'oferta. És el cost de l'error del primer apartat convertit en tallafoc: si no es pot abaixar la probabilitat de la fallada, se n'abaixa l'abast.

La pregunta que tanca tot això és senzilla de formular i reveladora de contestar: què fa el sistema amb els casos que no hauria de resoldre? Si la resposta és "no ho havia pensat, suposo que el que surti", no hi ha pla de fallada: hi ha una única manera de funcionar. I un procés comercial amb IA que no té sortida d'emergència no és en producció encara que estigui funcionant: està operant sense xarxa, i el dia que la necessiti no hi serà.

Les tres preguntes que decideixen si una IA passa de la demo a l'operació —quant costa que s'equivoqui, si ho sabríem, i què fa quan no se'n refia— comparteixen una cosa: cap va sobre el que la IA sap fer. Totes van sobre el que passa quan no ho fa bé.

Per això, davant de qualsevol IA que proposin posar en un procés, la pregunta no és “funciona?”. Són dues: què passa el dia que s'equivoqui, i com ens n'assabentarem. Sense les dues contestades, això no és en producció —és en una demo amb usuaris reals—. Que l'error sigui barat o car és el que decideix quant pesen aquestes respostes: on equivocar-se no costa res, es contesten en un minut; on costa, són la diferència entre un sistema i un accident.

I una més, per a més endavant, perquè això no es decideix una sola vegada: quan canviï el model, o se'n vagi el proveïdor que el va muntar, qui torna a fer-se aquestes preguntes? Un sistema que fallava en veu alta pot començar a fallar en silenci sense que ningú hagi tocat res. Una IA no entra a l'operació el dia que demostra que sap fer alguna cosa. Hi entra el dia que tenim decidit què passa quan s'equivoqui.