Una xifra pot revelar una demora, una errada repetida o una barrera d'accés. També pot desplaçar l'atenció cap a allò que és fàcil de comptar i allunyar-la del que importa a les persones. Quan una aplicació demana informació per mesurar el seu rendiment, la pregunta no és únicament quin indicador millorarà. Cal saber quines dades s'incorporen, quines conseqüències tindrà la mesura i si la recerca d'eficiència converteix una necessitat d'ajuda en un rastre permanent.

Els panells mostren percentatges, temps mitjans, abandonaments i recorreguts. Cap d'aquestes dades no és neutral per si mateixa. Triar una mètrica defineix quin problema mereix ser vist i quina experiència queda fora del càlcul. Una resposta ràpida pot ser inútil; una interacció curta pot voler dir que una persona va desistir; un compte inactiu pot reflectir que no tenia dispositiu, idioma o confiança suficients.

Mesurar amb cura exigeix separar la millora del servei de la vigilància de qui l'utilitza. Un equip necessita evidències per corregir errades, però no necessita construir una biografia de cada consulta. La privacitat es fa pràctica quan es decideix abans què no es recollirà, quant temps es conservarà allò imprescindible i qui podrà revisar una incidència concreta.

Una mètrica no conté tot el propòsit d'un servei#

Les aplicacions solen prometre decisions basades en dades. L'expressió pot descriure una pràctica útil: comprovar quantes persones troben una informació, detectar una caiguda del sistema o saber si un formulari produeix errades. El problema apareix quan la xifra es tracta com una descripció completa de la realitat. Si l'objectiu declarat és facilitar una cita, l'indicador no hauria d'empènyer a demanar ubicació precisa, contactes o historial de navegació que no calen per reservar-la.

Les aplicacions solen prometre decisions basades en dades. L'expressió pot descriure una pràctica útil: comprovar quantes persones troben una informació, detectar una caiguda del sistema o saber si un formulari produeix errades.

L'Agència Espanyola de Protecció de Dades recorda que el tractament ha de ser adequat, pertinent i limitat al necessari. Aquesta idea permet convertir una discussió abstracta en un disseny concret. Per conèixer la càrrega d'un servei pot ser suficient el nombre agregat de sol·licituds per franja horària. Per localitzar una errada tècnica pot bastar un identificador temporal i una versió de l'aplicació. Desar el contingut íntegre, el dispositiu i tots els passos posteriors exigeix una raó addicional, clara i comprovable.

També convé mirar quines conductes premia l'indicador. Un sistema que valora només la reducció de trucades pot dificultar el telèfon, encara que una conversa sigui la via més accessible per a moltes persones. Un altre que persegueix formularis acabats pot amagar l'opció de sortir sense compartir dades. L'eficàcia no equival a portar tothom pel recorregut més barat per a l'organització. Ha d'incloure la possibilitat de triar un canal, demanar una explicació i corregir una informació equivocada.

La qualitat necessita més d'un senyal. Juntament amb els temps de resposta es poden revisar reclamacions, accessibilitat, errades confirmades, comprensió dels avisos i èxit de les derivacions humanes. Cap mètrica no substitueix el judici, però diversos senyals redueixen el risc que una xifra còmoda es converteixi en mandat. Un informe honest explica què no es pot concloure amb les dades disponibles i evita presentar una correlació com si fos una intenció o una capacitat individual.

Abans de registrar, convé descriure tot el recorregut#

Una petició de dades poques vegades acaba a la pantalla on s'introdueixen. Pot passar per un proveïdor d'identitat, una eina analítica, un sistema de còpies, un equip de suport i un contracte de manteniment. Per això un inventari útil no es limita al nom dels camps. Ha d'indicar finalitat, base aplicable, destinataris, ubicació, termini de conservació, accés intern, subencarregats i mètode d'eliminació. Si el recorregut no es pot explicar amb claredat, la recollida difícilment serà proporcionada.

El Reglament General de Protecció de Dades estableix minimització, limitació de finalitat i limitació del termini de conservació. No són fórmules per a una política extensa; són proves de disseny. Es pot substituir una data exacta per un interval? Es pot mesurar una errada sense emmagatzemar un text sensible? Es pot separar el compte necessari per a un tràmit de l'analítica opcional? Cada resposta que redueix una dada redueix també el dany possible davant un accés indegut, un canvi de proveïdor o una interpretació fora de context.

La transparència ha d'estar a prop de la decisió. Un enllaç genèric a condicions legals no explica per què una aplicació demana permís d'ubicació per mostrar una oficina ni quant temps desa una consulta. Un avís breu pot distingir entre informació necessària, informació opcional i dades que no s'han d'enviar. Ha d'aclarir igualment si una resposta és automàtica, com demanar revisió humana i què passa si es rebutja una mesura no essencial. Negar-se a una analítica no hauria de bloquejar una ajuda bàsica.

El Marc de Gestió de Riscos d'IA del NIST proposa governar, mapar, mesurar i gestionar riscos de forma contínua. Aplicat a una aplicació que usa mètriques, significa comprovar no només l'exactitud del resultat, sinó l'efecte d'obtenir-lo. Una mesura pot ser tècnicament correcta i, tanmateix, desproporcionada perquè desanima consultes sensibles o amplia l'accés de tercers. El mapa de riscos ha d'incloure aquests efectes socials, no només les errades del programa.

Cas primer: l'aplicació de cites i el mapa massa precís#

Una xarxa de centres públics va crear una aplicació per demanar cita i conèixer el punt d'atenció més proper. L'equip volia reduir absències i va afegir geolocalització contínua, recordatoris vinculats al dispositiu i un registre de rutes dins l'aplicació. El panell va millorar: mostrava quantes persones obrien el mapa i quant trigaven a confirmar. Tanmateix, la informació recollida permetia inferir visites freqüents, hàbits de mobilitat i moments en què una persona buscava ajuda, encara que la majoria de consultes només necessitaven un horari i una adreça aproximada.

La revisió va començar per separar objectius. Per oferir el centre més proper es demanava un codi postal o una cerca manual, no una posició permanent. Per comprovar la utilitat del mapa es mesuraven consultes agregades i errors de càrrega, no trajectòries individuals. Els recordatoris es van fer opcionals i s'eliminaven després de la cita. Quan una persona necessitava canviar una reserva, podia fer-ho per telèfon o presencialment sense obrir l'aplicació ni acceptar notificacions.

El canvi no va deixar l'equip sense informació. Va permetre detectar que una zona mostrava resultats incorrectes, que certs horaris generaven confusió i que la versió antiga fallava en lectors de pantalla. També va evitar convertir la reducció d'absències en una excusa per seguir qui no hi acudia. Una absència pot deure's a feina, cures, transport o una decisió legítima de no continuar. L'indicador serveix per revisar el servei, no per construir explicacions personals que el sistema no pot conèixer.

Cas segon: el portal d'ocupació i la puntuació que es va tornar etiqueta#

Un portal d'ocupació oferia recursos de formació i orientació. Per prioritzar avisos, calculava una puntuació amb freqüència d'accés, clics en ofertes i temps dedicat a cada curs. Després es va proposar incorporar cerques, edat declarada, barri i notes obertes del personal. La proposta prometia una recomanació més ajustada, però convertia senyals incomplets en una imatge estable de motivació, disponibilitat o risc d'atur prolongat.

La institució va fixar un límit funcional: la puntuació només podia ordenar suggeriments voluntaris i no afectar l'accés a prestacions, entrevistes o cursos. Es van retirar les notes lliures i es va prohibir usar l'indicador com a motiu únic d'una decisió. Les persones podien veure que rebien una recomanació automatitzada, desactivar-la i contactar amb orientació humana. L'equip va avaluar l'eina amb dades de prova i grups agregats, sense conservar l'historial detallat de cada navegació per justificar després una inferència.

La lliçó no va ser que tota recomanació sigui perjudicial. Va ser que una xifra d'activitat no equival a una mesura d'interès ni de capacitat. Algú pot consultar poc perquè comparteix ordinador, treballa per torns, cuida una altra persona o prefereix acudir a una oficina. Quan una mètrica passa a influir en oportunitats, la incertesa ha de ser visible i la conseqüència ha de ser limitada. L'ajuda perd legitimitat quan sembla una classificació que no admet explicació ni sortida.

Cas tercer: l'app municipal i la mesura de satisfacció#

Un ajuntament va llançar una aplicació per informar sobre ajudes d'habitatge, terminis i documentació. El contracte d'analítica permetia registrar converses completes, identificadors publicitaris i pàgines visitades abans i després de cada consulta. El propòsit era mesurar satisfacció i detectar respostes poc clares. Però aquest conjunt podia revelar dificultats econòmiques, canvis familiars o una cerca d'habitatge urgent, informació especialment delicada quan prové d'una relació amb un servei públic.

L'equip va substituir el seguiment detallat per una pregunta voluntària al final de la interacció, proves periòdiques amb consultes fictícies i mètriques agregades sobre temes freqüents. Per investigar una errada concreta es va crear un protocol: accés limitat, motiu documentat, revisió per una persona responsable i eliminació o anonimització posterior. L'aplicació va deixar clar que no resolia sol·licituds ni prenia decisions sobre ajudes; les respostes enllaçaven a la font oficial i oferien telèfon i atenció presencial.

El resultat va ser una mesura menys espectacular i més defensable. Es podia saber quins terminis confonien, en quin idioma faltava informació i quins enllaços produïen errors, sense desar una seqüència completa de la vida de qui consultava. La institució no va perdre responsabilitat per recollir menys. Va guanyar la possibilitat d'explicar exactament què observava, per a què i durant quant temps. Aquesta precisió també facilita una reclamació, una auditoria i una correcció quan el servei falla.

La revisió d'una errada necessita límits i reparació#

Conservar alguna evidència pot ser necessari quan una aplicació ofereix una instrucció errònia. Cal poder saber quina versió era activa, quina font es va utilitzar i quines persones podrien haver rebut el mateix resultat. Però investigar no autoritza a obrir tots els registres ni a mantenir converses alienes a la incidència. Un protocol proporcionat delimita data, tipus de dany, persones autoritzades, dades accessibles i data de destrucció. Sense aquests límits, una investigació raonable es pot transformar lentament en vigilància ordinària.

La supervisió humana tampoc no és una llicència per a la curiositat. Els accessos han de respondre a una funció, quedar documentats quan tracten informació sensible i permetre detectar descàrregues o consultes inusuals. Separar l'atenció a les persones de l'anàlisi tècnica redueix exposicions innecessàries. També protegeix els equips: un procediment clar evita que algú hagi d'improvisar amb dades delicades sota pressió i permet elevar excepcions a qui té responsabilitat per autoritzar-les.

Els Principis d'IA de l'OCDE i la normativa europea sobre protecció de dades insisteixen en transparència, responsabilitat i salvaguardes adequades al context. En una aplicació quotidiana, això es pot traduir en accions concretes: una alternativa sense compte quan sigui possible, un termini curt per als registres, contractes que prohibeixin usos inesperats i una forma comprensible d'impugnar un resultat. No cal prometre certesa absoluta. Cal reconèixer què fa el sistema, què no sap i on acaba la seva autoritat.

Els contractes amb proveïdors mereixen la mateixa precisió. Han de dir si les dades serveixen per entrenar models, quins subcontractistes participen, on s'allotgen les còpies, com s'informa d'una incidència i què passa en acabar el servei. Una organització no pot traslladar el seu deure de cura a una clàusula opaca. Qui mostra l'aplicació al públic manté la responsabilitat de conèixer el recorregut de la informació i de poder apagar, corregir o esborrar allò que no correspon conservar.

Mesurar menys pot fer un servei més fiable#

Una organització pot comprovar aquesta idea amb exercicis senzills. Pot intentar resoldre una consulta amb la menor informació possible, demanar una rectificació com si no hi hagués connexió a internet, revisar què passa en rebutjar galetes analítiques i preguntar què pot veure realment cada proveïdor. També pot comparar una mètrica de rapidesa amb missatges de confusió o abandonament. Aquestes proves mostren problemes que una gràfica de rendiment no arriba a representar.

L'accessibilitat forma part d'aquesta revisió. Qui comparteix telèfon, no domina l'idioma de la interfície o no pot llegir un avís llarg pot quedar exposat de manera desproporcionada. Les alternatives han de ser utilitzables, no decoratives: telèfon, presencialitat, text clar, formats accessibles i una via per corregir dades sense narrar de nou detalls íntims. Una pantalla que condiciona tota ajuda a acceptar seguiment no ofereix una elecció significativa.

Una xifra útil conserva el seu lloc quan ajuda a reparar un servei sense reclamar més vida de la necessària. El bon funcionament no es mesura només per clics, temps mitjà o percentatge de finalització. També es mesura per la possibilitat de demanar ajuda sense deixar una petjada excessiva, limitar un permís sense càstig i rebre una revisió quan l'automatització s'equivoca. La privacitat no és un obstacle per millorar: és el límit que impedeix que la millora es confongui amb observar-ho tot.

Fonts institucionals: Agència Espanyola de Protecció de Dades, aepd.es; Comitè Europeu de Protecció de Dades, edpb.europa.eu; Institut Nacional d'Estàndards i Tecnologia, NIST AI RMF; Organització per a la Cooperació i el Desenvolupament Econòmics, Principis d'IA de l'OCDE.