La carpeta de la compra tenia una comparativa de preus, un vídeo de demostració i una xifra sobre hores estalviades. A la biblioteca de barri hi havia un cansament real: cada dia arribaven preguntes semblants i la cua de correus no semblava acabar-se. Per això la proposta de comprar un assistent d’intel·ligència artificial sonava raonable. La cap d’equip, però, no va preguntar quin proveïdor era millor. Va posar cinc capçaleres en un full: necessitat, persones afectades, dany tolerable, proves que falten i alternativa sense tecnologia.
Aquell full no era burocràcia addicional. Era una protecció contra una confusió habitual: tractar una eina disponible com si ja fos una solució. “Tenim molta feina repetitiva” no descriu una feina, ni permet saber si el servei millorarà. Pot voler dir que el web és difícil, que la norma és opaca, que falta una dada al formulari o que una persona necessita parlar amb algú. Abans de decidir com automatitzar, cal saber què s’està repetint i per què.
Una necessitat observable, no una promesa comercial#
La primera nota de la fitxa deia: “Una persona espera massa per entendre si pot renovar un préstec quan rep un avís ambigu.” Aquesta frase és més útil que “automatitzar l’atenció” perquè descriu una espera, una acció i un error de servei. També evita atribuir qualitats humanes a un producte. El problema no era que faltés una resposta intel·ligent; era que moltes persones no podien completar una gestió sense interpretar un missatge confús.
La primera nota de la fitxa deia: “Una persona espera massa per entendre si pot renovar un préstec quan rep un avís ambigu.”
El grup va revisar vint consultes recents. Hi havia preguntes sobre horaris, reserves, claus d’accés, penalitzacions i activitats infantils. A primera vista totes podien rebre una resposta ràpida. En llegir-les bé, van veure diferències importants. Una consulta sobre l’horari d’estiu es podia resoldre amb una font pública actualitzada. Una pregunta sobre un compte bloquejat podia ser una contrasenya oblidada, una devolució pendent o un error administratiu. Respondre amb seguretat sense saber quin cas era podia fer perdre més temps que una pregunta inicial ben feta.
La fitxa demana que la necessitat tingui un indicador que es pugui comprovar. La biblioteca va escollir el temps fins a la primera orientació útil, però no es va quedar amb el rellotge. També va registrar si la persona va haver de tornar a escriure, si la resposta es podia entendre amb lector de pantalla i si l’empleada va haver de corregir un missatge anterior. L’objectiu no era enviar textos abans; era aconseguir que menys gent quedés encallada.
La conversa que una classificació no captava#
Durant la reunió, una bibliotecària va explicar el cas d’un usuari que havia escrit només “no em deixa”. Un sistema podia assignar aquesta frase a una categoria, però la frase no contenia el problema. Quan ella va trucar, va descobrir que l’usuari havia canviat de telèfon i no podia rebre el codi de verificació. La solució no era una explicació sobre préstecs, sinó una recuperació d’accés feta amb cura.
El cas va servir per omplir la casella de persones afectades. No només hi havia la persona que escriu. Hi ha qui no pot connectar-se amb facilitat, qui comparteix dispositiu, qui llegeix en una llengua diferent i qui se sent exposat quan una pantalla li diu que té una incidència. També hi ha el personal que rep la conversa truncada i ha de reconstruir-la. Si una eina redueix minuts interns però fa que la persona expliqui tres vegades la mateixa situació, pot estar traslladant la càrrega, no reduint-la.
La fitxa va obligar a formular cada grup sense etiquetes abstractes. En lloc de “usuari vulnerable”, van escriure situacions: “persona que no sap si ha d’enviar dades per correu”, “persona que no entén una notificació automàtica”, “persona que necessita una resposta fora d’horari però no una decisió immediata”. Aquest llenguatge ajuda a dissenyar límits i proves. També impedeix que una categoria general serveixi d’excusa per decidir sense escoltar.
Tres rutes per treure feina repetida#
La comparació va començar amb una opció que sovint no apareix als catàlegs: arreglar el servei. La biblioteca va simplificar els avisos de renovació, va separar els tràmits més habituals i va afegir un petit formulari amb tres preguntes que recollien la dada necessària. És una intervenció modesta, però pot eliminar consultes que la institució havia creat amb missatges difícils. Demana redacció, proves d’accessibilitat i manteniment, no un model que endevini el que falta.
La segona ruta era una automatització de regles. Els horaris, els enllaços de renovació i les dates de recollida es podien respondre amb plantilles revisades i dades del catàleg. Si la consulta no encaixava, el flux no havia de fingir comprensió: havia de derivar-la amb el context ja recollit. Aquesta opció té una virtut important en un servei públic: es pot explicar la regla i auditar-ne el canvi. El seu límit no és un defecte; és el senyal que ha arribat una situació que mereix criteri humà.
La tercera ruta era la IA, però reduïda a funcions que es podien supervisar. Podria proposar un resum per a l’empleada, assenyalar que falta un número de carné o preparar un esborrany que no s’envia sol. No podria confirmar sancions, valorar la credibilitat d’una persona ni decidir l’accés a un servei. Abans de contractar, calia demostrar que la sortida era editable, que les dades emprades eren visibles i que una persona podia assumir el cas sense començar des de zero.
Posar les tres rutes una al costat de l’altra va canviar la pregunta. Ja no era “quina IA ens estalviarà més?”, sinó “quina combinació redueix la fricció sense crear un problema més difícil de reparar?”. En algunes consultes, la resposta era un avís millor. En d’altres, una regla clara. Només en una part concreta tenia sentit provar una assistència generativa.
Dany tolerable vol dir reparació possible#
La casella més incòmoda era la del dany tolerable. No serveix per convertir les persones en percentatges d’error. Serveix per preguntar què passa després d’un error, qui n’assumeix el cost i si existeix una correcció fàcil. Confondre un horari d’una activitat és reparable si hi ha una font oficial visible. Dir per error que un compte està suspès pot fer que algú deixi d’insistir, es desplaci inútilment o comparteixi informació personal per por.
La biblioteca va definir tres fronteres. La informació pública podia automatitzar-se amb un enllaç a la font i data de revisió. Les qüestions de compte només podien oferir passos de comprovació i un canal cap a una persona, sense afirmar causes. Les accions que afectessin menors, dades personals o el dret de préstec quedaven fora de qualsevol resposta automàtica. Aquestes fronteres són una decisió de servei, no una limitació tècnica que s’hagi de superar.
També van descriure com es desfaria un error. Qui rebés una resposta equivocada havia de poder contactar amb algú sense repetir la seva història. El personal havia de veure el missatge original, la proposta i la regla o dades que l’havien generada. I les incidències s’havien d’agrupar per trobar patrons: si moltes persones no entenen un avís, potser cal corregir l’avís i no entrenar millor la resposta.
Fer visible allò que encara no se sap#
Una fitxa honesta inclou una columna de desconeixement. L’equip hi va escriure que no sabia quantes consultes es resolien amb una frase més clara, quins idiomes necessitaven suport prioritari ni quantes persones abandonaven el tràmit de renovació. Aquestes absències no eren un argument per comprar de pressa. Eren les preguntes que havien de guiar una prova curta.
Durant quinze dies van registrar casos despersonalitzats: origen de la consulta, dada absent, temps fins a la resolució, correcció necessària i resultat. Van afegir una pregunta voluntària: “Aquesta resposta t’ha permès fer el següent pas?” Les dades van mostrar que molts correus arribaven després d’un avís massa curt. El canvi amb més impacte no va ser un assistent, sinó mostrar un exemple concret i un botó de recuperació d’accés.
La prova d’IA no es va descartar, però va quedar condicionada. S’usaria només per redactar esborranys interns en casos de llenguatge llarg, amb revisió humana i sense decisió automàtica. Es compararia amb el flux de regles i amb el web redissenyat. El criteri d’èxit no seria només el nombre de missatges gestionats, sinó menys repeticions, menys correccions i una via de reparació real.
Comprar una decisió que es pugui explicar#
La biblioteca va acabar la reunió sense signar cap contracte. Va aprovar primer canvis editorials, quatre respostes de regla i un pilot petit amb data de finalització. A la carpeta hi havia la fitxa, les hipòtesis que calia revisar, el nom de qui assumia cada revisió i el motiu pel qual certes decisions quedaven prohibides. Això no fa la compra més lenta per definició. Fa que el següent pas tingui una raó que es pot entendre i qüestionar.
Abans d’acceptar una demostració, pots provar la mateixa pràctica amb una tasca del teu equip. Escriu què observa una persona, no què promet el producte. Nomena qui haurà d’explicar l’error. Decideix quin dany no vols imposar. Apunta què no saps. I descriu una alternativa que puguis provar aquesta setmana sense cap compra. Si després d’això la IA continua sent la millor opció, la compra tindrà límits, proves i responsabilitats. Si no ho és, hauràs resolt una part del problema abans de convertir-lo en una llicència.
