Després de l'estrena d'una aplicació comença la feina que decideix si el servei mereix confiança. L'ús real posa a prova permisos, explicacions i registres. Cada dada que es demana ha de tenir una finalitat actual, concreta i comprensible.

Una aplicació pot necessitar informació per mantenir una sessió, resoldre una incidència o protegir un compte. Això no fa necessari tot el que hi ha en un telèfon ni justifica conservar dades per si algun dia serveixen.

El manteniment responsable escolta els errors sense convertir cada ús en un perfil. Un registre tècnic pot localitzar una caiguda o una incompatibilitat sense guardar converses, contactes, moviments o lectures.

Quan una actualització canvia un permís, afegeix analítica o canvia de proveïdor, cal explicar-ho abans de demanar acceptació. Una nota amagada no permet decidir; una explicació propera al canvi sí.

Minimització, seguretat i reparació han de treballar juntes. Cal poder retirar permisos opcionals, corregir una dada, demanar una alternativa i saber quan s'eliminarà un registre.

Després de publicar, cal revisar les suposicions#

Abans del llançament, cada camp té una justificació prevista: correu per confirmar un compte, adreça per lliurar una comanda, idioma per mostrar contingut. L'ús real pot revelar que una funció gairebé no es fa servir, que una alternativa sense compte és suficient o que un proveïdor rep més informació de la prevista. L'inventari de dades s'ha de revisar amb aquestes evidències.

Abans del llançament, cada camp té una justificació prevista: correu per confirmar un compte, adreça per lliurar una comanda, idioma per mostrar contingut.

Revisar no vol dir obrir tota l'activitat individual. Pot voler dir comptar errors de manera agregada, revisar exemples voluntaris i reproduir una errada en un entorn de prova. La pregunta important és quines dades calen per reparar un problema concret, no quantes se'n poden obtenir.

El RGPD fixa minimització, limitació de finalitat i limitació de conservació. Després de l'estrena, aquests principis serveixen com una llista: identificar l'objectiu actual, separar el necessari de l'opcional, posar data d'eliminació i comprovar qui hi accedeix. Un registre útil durant una migració pot no tenir cap sentit poques setmanes després.

La transparència ha d'acompanyar l'evolució. Si una actualització incorpora diagnòstics, ha de dir què mesura, per què, durant quant temps i com es pot desactivar si és opcional. Si dona una resposta automàtica, ha d'explicar els límits i oferir revisió humana quan calgui context.

Mesurar una incidència sense mesurar una vida#

Les dades de funcionament són útils per reparar. Un recompte de pantalles que no carreguen, una versió del sistema o un identificador temporal poden revelar un error. No cal conservar el text de cada cerca ni associar permanentment cada pulsació a una identitat. La telemetria és diagnòstic, no un arxiu de conducta.

Cal separar l'analítica del servei essencial. Una persona ha de poder consultar una cita, descarregar un document o demanar orientació sense acceptar mesures opcionals destinades a productes futurs. Rebutjar-les no ha de comportar un accés pitjor ni un botó inútil.

El xifratge, el control d'accessos i les proves de restauració redueixen riscos, però no legitimen una recollida excessiva. La primera protecció és no tenir dades innecessàries. La segona és saber quin sistema les rep, quin proveïdor les tracta i quan s'eliminen.

Les mètriques necessiten context. Un abandonament d'un formulari pot indicar confusió, problema d'accessibilitat, connexió lenta o decisió legítima de no seguir. No autoritza a perseguir qui ha sortit ni a deduir-ne la intenció. Abans d'afegir seguiment, cal revisar el text, provar accessibilitat i oferir ajuda.

Cas primer: ubicació després d'una actualització#

Una aplicació municipal mostrava biblioteques i punts d'atenció. Al principi demanava ubicació precisa i permanent per ordenar resultats. Després del llançament es va veure que la majoria de persones cercava el mateix barri i que una adreça escrita funcionava igual. El permís continu revelava rutines sense millorar el servei.

L'equip va substituir-lo per una cerca manual i un permís d'una vegada per al mapa. Va conservar només comptadors agregats d'errors i va eliminar identificadors en acabar la investigació. La pantalla explicava que la localització era voluntària i oferia una llista accessible. Aprendre no exigia observar més, sinó formular una pregunta més petita.

També es van revisar contractes i còpies. El proveïdor de mapes rebia una consulta limitada i no un historial de llocs per a publicitat. Es va documentar el termini dels registres. Qui rebutjava el permís obtenia el mateix horari i telèfon. El servei era menys invasiu i més fàcil d'explicar.

Cas segon: un informe amb documents privats#

Una aplicació de tràmits permetia enviar captures per comunicar un error. Algunes contenien números d'expedient, adreces, noms de menors o documents sencers. L'equip havia d'entendre la incidència, però guardar tots els adjunts en una carpeta compartida convertia el suport tècnic en un risc.

El formulari va afegir avís clar, vista prèvia i eines per ocultar zones sensibles. Per als errors repetibles es demanaven versió, hora aproximada i passos, no una captura per defecte. Els casos excepcionals eren per a personal autoritzat, amb accés limitat i data d'eliminació. El suport no copiava dades íntimes a notes internes.

Això facilitava la reparació: els informes tenien estructura, els errors es podien agrupar i la informació innecessària deixava de circular. Si calia una prova addicional, se n'explicava el motiu i es demanava de manera precisa.

Cas tercer: recomanacions que semblaven decisions#

Una plataforma de formació recomanava cursos segons opcions guardades. Es va proposar afegir temps de lectura, hores de connexió, edat i notes lliures de tutors. Aquestes senyals incompletes podien convertir-se en una imatge estable de capacitat o interès i en una classificació difícil de qüestionar.

L'organització va limitar el sistema a ordenar continguts voluntaris. Va excloure notes lliures, va prohibir emprar el resultat per negar matrícula o suport i va mostrar una explicació simple. Es podia desactivar i demanar orientació humana. Les proves usaven dades controlades i resultats agregats, no historials detallats indefinits.

Una predicció útil no és autoritat sobre una persona. Qui consulta poc pot compartir dispositiu, tenir poc temps, preferir un altre format o no confiar en la plataforma. Si la tecnologia afecta oportunitats, cal que la incertesa sigui visible, les conseqüències limitades i la correcció possible.

Un manteniment que permet reparar#

La revisió periòdica pot començar amb una funció nova, una incidència de seguretat, un proveïdor diferent o una queixa repetida. En cada revisió cal registrar finalitat, camps, destinataris, permisos, termini, riscos i alternativa. No cal publicar detalls que facilitin un atac, però sí poder explicar el recorregut de les dades.

L'AEPD, el Comitè Europeu de Protecció de Dades i el marc de riscos d'IA de NIST coincideixen en una idea: governar és continu. Cal identificar context, mesurar impactes i gestionar respostes mentre el servei funciona, no només aprovar-lo al principi.

La reparació inclou drets d'accés, rectificació i supressió. No han de ser una cursa d'obstacles ni obligar a repetir detalls sensibles. Si una automatització intervé en una decisió rellevant, cal una explicació i revisió adequades. La persona no ha de carregar amb l'opacitat de l'arquitectura.

L'accessibilitat també és privacitat. Un avís llarg, un consentiment confús o un canal digital únic poden anul·lar una elecció real. Text clar, tecnologies de suport, telèfon, atenció presencial i alternatives sense seguiment permeten exercir el límit de dades.

Després de l'estrena apareixen conseqüències concretes. Escoltar errors, reduir permisos, retirar dades inútils i corregir explicacions imprecises manté l'aplicació dins la seva finalitat. Un bon manteniment observa prou per reparar i preserva la possibilitat d'usar un servei sense deixar una petjada desproporcionada.

Convertir les incidències en decisions verificables#

Una bona revisió posterior no acaba quan s'ha tancat un tiquet. L'equip ha de poder relacionar cada canvi amb el problema que el justifica, la dada que s'ha fet servir i la data en què tornarà a comprovar la decisió. Aquesta traça no és un expedient sobre les persones usuàries: és memòria de responsabilitat per a l'organització. Evita que un permís temporal esdevingui permanent perquè ningú no recorda per què es va demanar, i permet explicar una modificació a suport, auditoria o a la persona afectada.

És útil distingir els senyals que serveixen per detectar un problema dels que serveixen per confirmar-lo. Un augment agregat d'errors pot avisar que cal investigar. Per confirmar una causa, potser n'hi ha prou amb provar una versió concreta del navegador o amb demanar voluntàriament els passos que ha seguit una persona. Saltar directament a recollir identificadors persistents o contingut complet és una mala drecera: amplia la superfície de risc abans de saber si aquella informació respondrà la pregunta.

Les decisions també han de tenir propietari. Qui incorpora un SDK, modifica una pantalla de consentiment o contracta un servei extern ha de saber quin inventari s'actualitza i qui revisa les condicions del proveïdor. Les biblioteques de tercers poden canviar la seva configuració, transmetre dades de diagnòstic o introduir noves finalitats. Per això convé revisar versions, configuracions per defecte i fluxos de xarxa després de cada actualització important, no només quan hi ha una notícia o una queixa.

Comunicar un canvi sense traslladar-ne la càrrega#

Explicar no consisteix a enviar una notificació genèrica que digui que la privacitat és important. Cal anomenar el canvi: per exemple, que l'aplicació conservarà un codi de sessió durant set dies per detectar fraus, o que deixarà d'enviar informes de fallada a un proveïdor anterior. També cal dir què pot fer la persona: continuar sense l'opció, modificar-la des dels ajustos, demanar ajuda o consultar una explicació més completa. La claredat permet controlar; l'ambigüitat obliga a confiar a cegues.

Quan un canvi és essencial per seguretat o per complir una obligació, l'explicació encara importa. No tot es resol amb consentiment, i presentar com a opcional allò que no ho és pot confondre. La pantalla ha de separar la base del servei de les millores voluntàries, indicar el període de conservació i no condicionar una funció aliena a l'acceptació d'analítica. Si hi ha dubtes, el canal d'atenció ha de poder respondre amb informació concreta, no limitar-se a repetir l'enllaç d'una política.

Finalment, cal mirar si la reparació ha funcionat sense crear una nova exclusió. Després de retirar un permís, les persones que utilitzen lector de pantalla, connexions lentes o dispositius antics han de poder completar igualment la tasca. Després d'afegir un control, la seva opció ha de mantenir-se entre sessions i no ressuscitar després d'una actualització. El manteniment de dades és bo quan redueix riscos i, alhora, fa que l'alternativa respectuosa sigui tan practicable com la ruta més invasiva.

Fonts institucionals: Agència Espanyola de Protecció de Dades, aepd.es; Comitè Europeu de Protecció de Dades, edpb.europa.eu; NIST, AI RMF; OCDE, Principis d'IA.