Dilluns, la Nora va obrir l'aplicació municipal per demanar hora amb infermeria. Ho havia intentat la setmana anterior i la primera opció era al cap de divuit dies. Aquell matí va aparèixer una hora per dijous. No sabia que el canvi no venia d'un nou professional, d'una ampliació d'agenda ni d'una decisió anunciada pel centre. Durant la nit s'havia activat una regla automàtica: les sol·licituds amb determinades respostes del formulari passaven a una cua prioritària. La regla treballava en segon pla, no figurava a l'organigrama i ningú a recepció no podia explicar a la Nora per què a ella li sortia aquell forat i a una altra persona no.
El problema no és que tota classificació automàtica sigui il·legítima. Un sistema pot ajudar a ordenar peticions urgents, evitar que algú repeteixi dades o detectar que una visita necessita més temps. El problema comença quan una regla canvia de fet qui espera, qui rep una trucada o qui queda fora d'una agenda sense que la institució pugui dir què ha canviat, qui n'ha respost i com es revisarà si perjudica algú. Una decisió rellevant no deixa de ser decisió perquè s'executi molt de pressa ni perquè s'hagi escrit com una configuració tècnica.
L'automatització no elimina la responsabilitat#
En moltes organitzacions, una decisió té una cara identificable. Si canvia l'horari d'atenció, hi ha una persona o un àmbit que signa la instrucció. Si es modifica un criteri per accedir a un ajut, acostuma a haver-hi una norma, una data d'entrada en vigor i una via per preguntar. Quan la modificació viu dins d'una eina contractada, la cadena es difumina. El proveïdor diu que ha lliurat una funció; l'equip tècnic explica que ha activat una opció; l'àrea de servei afirma que continua atenent segons el procediment; i qui rep el resultat es queda sense interlocutor.
En moltes organitzacions, una decisió té una cara identificable. Si canvia l'horari d'atenció, hi ha una persona o un àmbit que signa la instrucció.
Aquesta absència no és només administrativa. La Nora necessita saber si l'hora de dijous és el resultat d'una valoració clínica, d'una regla de priorització o d'un error de dades. També necessita saber què pot fer si el formulari ha entès malament la seva situació. Si algú amb una barrera d'idioma, una discapacitat o un telèfon compartit respon d'una altra manera, la regla pot repartir temps i atenció de manera desigual sense que el biaix aparegui en cap reunió. La invisibilitat tècnica converteix una pregunta pública —qui rep primer un recurs escàs— en un detall que sembla pertànyer només a una pantalla.
Anomenar “intel·ligència artificial” qualsevol sistema que ordena casos tampoc no aclareix el problema. Algunes regles són simples i d'altres depenen de models complexos. En tots dos casos hi ha una elecció humana prèvia: quines dades compten, quin resultat es busca, quan s'aplica una excepció i quin cost s'accepta si el sistema s'equivoca. Una organització ha de poder anomenar aquestes eleccions sense refugiar-se en una etiqueta tècnica. La complexitat pot exigir més explicació; mai no menys responsabilitat.
Un registre viu fa que el canvi es pugui discutir#
Una mesura elemental és mantenir un registre viu de les regles que afecten drets, accés, prioritat o tracte. No cal publicar secrets de seguretat ni exposar informació personal. Cal que hi hagi una fitxa entenedora: quin procés toca la regla, quina decisió influeix, quina informació utilitza, des de quan opera, quin equip n'és propietari i quina és la data prevista de revisió. Si hi ha un proveïdor, la fitxa ha d'indicar quina part controla i quina manté la institució. Si canvia una versió, el registre ha de conservar la versió anterior i la raó del canvi.
“Viu” és la paraula important. Un document creat en comprar un programa i oblidat en una carpeta no serveix per descobrir que una actualització ha alterat els resultats. La regla de la Nora pot modificar-se perquè el proveïdor ajusta un llindar, perquè l'ajuntament afegeix una pregunta nova o perquè el servei decideix reduir visites sense avisar. Cadascuna d'aquestes alteracions mereix una empremta: qui l'ha proposada, quina evidència la justificava, quins grups podrien quedar afectats i qui ha autoritzat que entrés en funcionament. Registrar no garanteix una bona decisió, però permet veure-la, discutir-la i corregir-la abans que es converteixi en costum.
Aquest registre també canvia la conversa dins de la institució. L'equip tècnic deixa de rebre l'encàrrec ambigu de “fer que prioritzi millor” i pot demanar una definició concreta de prioritat. El personal d'atenció pot consultar per què una persona veu una resposta determinada sense inventar explicacions. La direcció pot comparar els resultats promesos amb els reals. I la ciutadania disposa d'una porta raonable per preguntar, sense haver de demostrar abans coneixements de programació.
La propietat institucional no es pot subcontractar#
El proveïdor pot desenvolupar el programari, però no hauria de convertir-se per això en l'únic posseïdor del criteri públic. Quan una regla decideix l'accés a una visita, una beca, una inspecció o una prestació, la institució usuària ha de tenir una persona responsable amb nom i funció. Aquesta persona no ha de programar cada línia. Sí que ha de poder respondre quin objectiu persegueix la regla, amb quins límits s'utilitza, qui la pot aturar i què passa quan arriba una reclamació.
Assignar propietat institucional evita un altre error habitual: que ningú no se senti autoritzat a aturar un sistema que ja està produint danys. Si la recepció detecta que moltes persones arriben sense saber per què no han obtingut visita, necessita un canal per elevar el problema. Si un professional observa resultats estranys, necessita que l'observació activi una revisió, no pas una cadena infinita de correus. El propietari del procés ha de tenir autoritat i obligació de coordinar aquesta resposta amb equips tècnics, jurídics, d'atenció i, quan correspongui, amb representants de les persones afectades.
La responsabilitat tampoc no acaba quan l'eina funciona com s'esperava. Pot ser que la regla ordeni correctament les dades que rep i, tanmateix, amplifiqui una desigualtat prèvia. Una persona sense connexió estable pot abandonar el formulari abans d'arribar a la pregunta que obre la prioritat. Una altra pot no entendre un terme mèdic. Mirar només la precisió tècnica amaga aquest efecte. La propietat institucional inclou revisar l'experiència completa: qui aconsegueix entrar, qui comprèn la decisió, qui pot corregir una dada i qui es rendeix abans de demanar ajuda.
Avisar abans que la regla tingui conseqüències#
Un avís previ no exigeix aclaparar ningú amb una política de vint pàgines. Pot ser una explicació breu i situada: “Utilitzem les respostes d'aquest formulari per ordenar les visites; si la teva situació canvia o creus que la prioritat no reflecteix la teva necessitat, pots demanar revisió per telèfon, presencialment o per aquest canal”. Aquest missatge reconeix que la classificació existeix i ofereix una sortida abans que el resultat es converteixi en un fet irreversible.
L'avís ha d'arribar abans de l'impacte, no només després d'una queixa. Si una actualització farà que certes sol·licituds passin a una cua diferent, l'organització pot comunicar-ho als equips, provar-ho amb casos diversos i habilitar suport accessible. No tots els canvis requereixen una campanya pública, però tots els canvis que alteren oportunitats necessiten una avaluació proporcional del risc. Canviar el color d'un botó no és el mateix que canviar la lògica que decideix a qui es truca avui.
Les vies de revisió importen tant com l'avís. Una persona no hauria d'haver d'explicar tota la seva vida a un chatbot per demanar que algú miri el seu cas. Hi ha d'haver un recorregut humà, amb terminis clars i una resposta que digui què s'ha revisat. Revisar no significa prometre sempre un resultat diferent; significa reconèixer que una regla pot no captar circumstàncies rellevants i que la institució conserva el deure de valorar-ne els efectes.
Revisar els canvis, no solament el producte inicial#
La pregunta útil no és “funciona la IA?”, sinó “què ha canviat aquesta regla en el repartiment real de temps, atenció i possibilitats?”. Per respondre-la, el servei pot fixar revisions després de cada canvi significatiu: comparar temps d'espera, taxes d'abandonament, peticions de revisió i resultats entre grups que podrien rebre un tracte desigual. Els indicadors no substitueixen el testimoni de qui utilitza el servei, però poden revelar que una millora aparent deixa algú sistemàticament enrere.
La revisió necessita possibilitat de tornar enrere. Abans de desplegar una modificació convé definir qui la pot suspendre, quin senyal activaria aquella suspensió i com es conservarà la versió anterior. Aquesta disciplina és habitual en sistemes segurs: es prova, s'observa, es registra i es corregeix. Aplicar-la a regles d'atenció pública significa acceptar que les persones no són un entorn de prova silenciós.
La Nora no necessita veure el codi de l'aplicació per rebre un tracte digne. Necessita saber que la visita de dijous respon a un criteri identificable, que algú n'assumeix el criteri i que pot demanar ajuda si el resultat no descriu la seva situació. Un registre viu, una propietat clara, un avís previ i una revisió real no frenen la tecnologia. Li donen el lloc que ha de tenir a Pacoverso: una eina al servei de persones que poden comprendre-la, discutir-la i demanar que canviï quan deixa de cuidar.
