La reunió de programació semblava fàcil. Un centre cultural volia fer servir una eina per suggerir activitats a qui s'inscrivia al seu butlletí. La responsable tècnica hi veia una manera d'ordenar propostes; la mediadora temia que les recomanacions repetissin sempre els mateixos públics; una visitant preguntava per què el sistema assumia què volia fer segons la seva edat. Durant uns minuts, cada intervenció va semblar un obstacle. Després algú va dibuixar quatre columnes: què es discuteix, qui suporta l'error, quina evidència falta i què no s'automatitza encara. El desacord va deixar de ser una interrupció i es va convertir en un mapa de feina.
Els projectes d'IA sovint busquen consens massa aviat. Una demostració fluida crea la impressió que les preguntes crítiques retarden una solució evident. Però l'acord ràpid pot amagar que les persones descriuen problemes diferents. Qui dissenya l'eina pot pensar en precisió; qui atén el públic, en explicacions; qui rep el resultat, en si manté una sortida quan la recomanació no encaixa. Cap d'aquestes mirades no és suficient per si sola. Anomenar el desacord no vol dir que totes les opinions pesin igual en una decisió sensible. Vol dir que l'organització sap què tria i quin risc deixa sense resoldre.
Posar el context en clar#
Un mapa de desacords comença evitant paraules massa grans. En comptes d'escriure «preocupació per biaixos», convé descriure una escena: «el suggeriment de cursos no ofereix horaris per a qui treballa a la tarda». En lloc de «manca transparència», es pot dir: «una persona no sap per què ha rebut aquesta invitació ni on la pot desactivar». Les escenes obliguen a parlar de conseqüències, no de principis buits. També ajuden a comprovar si el problema pertany al model, a les dades, a la pantalla, a una norma del servei o a una expectativa que ningú no havia fet explícita.
Un mapa de desacords comença evitant paraules massa grans. En comptes d'escriure «preocupació per biaixos», convé descriure una escena: «el suggeriment de cursos no ofereix horaris per a qui treballa a la tarda».
La segona columna pregunta qui paga l'error. Una recomanació equivocada pot ser una molèstia lleu si suggereix una pel·lícula que no interessa. No és igual si ordena sol·licituds de suport, modifica una cita o decideix quina informació rep una família. El cost tampoc no es reparteix igual. Qui té temps, domini digital i confiança pot corregir una pantalla o reclamar. Qui no en té pot acceptar un resultat injust perquè suposa que no hi ha alternativa. Mirar qui suporta la reparació ajuda a decidir quins usos necessiten revisió humana obligatòria i quins poden ser suggeriments reversibles.
Allò que canvia a la pràctica#
La tercera columna recull l'evidència que falta. Un equip pot sortir de la paràlisi amb proves petites: cinc casos anonimitzats, una sessió amb persones usuàries, una comparació entre recomanació automàtica i criteri professional, un registre de canvis. L'evidència no és una excusa per ajornar una decisió; serveix per saber quina pregunta s'ha de respondre abans d'ampliar l'ús. Si una prova mostra que el problema afecta sempre el mateix grup, no cal esperar una mètrica perfecta per posar un límit.
La darrera columna és la més important: què no s'automatitza encara. Dir «encara no» no és un fracàs d'innovació. Un centre pot fer servir IA per ordenar preguntes freqüents sense permetre que enviï comunicacions sobre una beca. Una associació pot preparar resums interns sense deixar que classifiqui urgències. És una decisió d'abast que protegeix les persones mentre l'equip aprèn si hi ha una manera responsable de continuar.
Decidir amb informació#
El mapa funciona millor quan incorpora veus que sovint arriben al final. La persona de recepció sap on s'encallen els formularis; qui tradueix detecta una paraula que canvia de sentit; una participant pot explicar per què una notificació li ha semblat invasiva. No es tracta de demanar testimonis íntims per justificar un risc ja decidit. Es tracta de crear una conversa on l'experiència concreta pugui modificar el disseny. La reunió ha de tornar alguna cosa: una resposta a la preocupació, un canvi visible o una explicació honesta de per què no s'ha adoptat una proposta.
També cal separar el desacord saludable del conflicte que no s'ha de resoldre en una taula comuna. Si hi ha violència, discriminació, assetjament, una relació de poder desigual o informació molt sensible, la persona afectada no ha de debatre amb qui va prendre la decisió per demostrar que hi ha un problema. En aquests casos s'activa el procediment de protecció i es limita la informació compartida. Un mapa de desacords ajuda a governar una eina; no substitueix una via formal de reparació ni una obligació de cura.
Revisar i ajustar#
Una cooperativa de consum va aplicar aquest mètode abans de provar un classificador de consultes. L'equip tècnic volia reduir el temps de resposta; l'equip d'atenció va advertir que algunes preguntes barrejaven una incidència de factura amb una situació econòmica delicada. El mapa va produir una regla clara: el sistema podia suggerir etiquetes, però mai tancar una consulta ni decidir prioritat quan apareixien paraules sobre tall de subministrament, deute o amenaça. Durant el pilot, el registre va mostrar que l'excepció s'activava més del previst. En lloc de canviar el llindar per aparentar eficiència, la cooperativa va reforçar el torn humà. El mapa no va eliminar el desacord; va evitar que s'amagués darrere d'un número de productivitat.
Abans del pròxim desplegament, n'hi pot haver prou amb una hora i una paret buida. Escriviu cinc decisions que l'eina podria influir, busqueu per a cadascuna una escena de dany plausible, una persona que suportaria la reparació, una evidència que falta i un límit actual. Després trieu una acció petita: provar, canviar, preguntar o no automatitzar. Guardeu el mapa amb el projecte i torneu-hi quan aparegui una incidència. El criteri no consisteix a produir un consens elegant. Consisteix a conservar els desacords que ajuden a veure allò que una interfície brillant tendeix a ocultar.
El resultat d'una bona conversa no és que tothom surti entusiasmat. És que qui haurà de fer servir l'eina entén què pot qüestionar, qui la pot aturar i què passarà si alguna cosa falla. Aquesta claredat reparteix responsabilitat. També retorna a la tecnologia la seva mida real: no és una autoritat que resol el debat, sinó una proposta que les persones poden acceptar, limitar o retirar amb raons.
El mapa ha de tenir data. Sense una revisió acordada, la cautela inicial es pot convertir en una llista oblidada i l'entusiasme inicial es pot consolidar sense proves. Una data de retorn permet comprovar si l'evidència ha canviat, si una excepció s'ha fet habitual o si un límit continua sent necessari. Arribat aquell dia, les opcions no són només seguir o cancel·lar: es pot mantenir un pilot, reduir-lo, canviar la tasca, obrir una consulta nova o aturar una funció. Una decisió madura no necessita defensar el pla original; necessita poder explicar per què el pla actual continua cuidant millor les persones afectades.
No totes les preguntes s'han de resoldre abans de començar, però totes han de deixar una traça. Si l'equip acorda provar una eina malgrat una incertesa, ha d'escriure quina és, qui la revisarà i quin fet obligaria a canviar de rumb. Aquesta disciplina evita que un risc conegut es converteixi després en una sorpresa convenient. També ajuda les persones noves a entendre per què existeix un límit i com poden proposar-ne la revisió sense haver de repetir tot el debat des de zero.
La data de revisió pot recuperar també la veu de qui no era a la primera reunió. Abans de tornar al mapa, l’equip pot convidar una persona afectada i algú que atengui incidències a llegir dos casos anonimitzats. No es tracta de demanar una aprovació de cortesia, sinó de comprovar si el desacord s’ha descrit amb justícia i si el cost de corregir continua caient al mateix costat. Un mapa útil canvia quan apareixen raons millors; no es limita a conservar la signatura de qui el va dibuixar.
