16/04/2026 10:45 h.
Com garantir una IA municipal auditable i sota control públic?
Després d’haver explorat el marc jurídic inicial del Reglament Europeu d’IA (vegeu article 1) i els pilars de la gestió de qualitat, la gestió de riscos, la supervisió humana i la governança de dades (vegeu article 2), entrem ara en una fase clau del desplegament de la intel·ligència artificial a l’administració local: entendre com ha de funcionar el sistema en la pràctica, com s’ha de controlar un cop entra en servei i com es tradueixen totes aquestes obligacions en contractes públics segurs.
En aquest bloc ens endinsem, d’una banda, en els requisits tècnics que estableix l’Article 15 del RIA —transparència, precisió, solidesa i ciberseguretat—, és a dir, en allò que garanteix que el sistema no només funciona, sinó que és auditable i resilient davant d’errors o atacs. D’altra banda, analitzem què passa quan la IA “surt al carrer”: la necessitat de registres, traçabilitat, vigilància contínua i gestió d’incidents per assegurar que el sistema no es desvia del seu comportament previst en l’ús real.
Finalment, tanquem el cercle amb una mirada pràctica a la contractació pública. Les guies del Sandbox de l’AESIA culminen amb un manual de checklist que permet a l’ens local transformar les obligacions del RIA en requisits concrets dins dels plecs, assegurant que la conformitat no és un tràmit final, sinó un element integrat al llarg de tot el cicle de vida del sistema.
La transparència no és una opció, sinó una obligació de disseny (Article 13 RIA). El sistema s'ha de desenvolupar de manera que els seus resultats siguin interpretables pel responsable del desplegament. Això implica que el proveïdor ha de lliurar instruccions d’ús en format digital que incloguin des de la identitat del proveïdor fins a les limitacions de rendiment i les mesures de supervisió humana.
En què consisteix?
Qualitat d’un sistema d’IA de ser enterament interpretable i comprensible per totes les persones que interactuen durant tot el seu cicle de vida.
Són necessàries tècniques d’explicabilitat.
Perquè?
Són sistemes complexos, cal generar confiança.
Cal entendre el funcionament i poder interpretar els resultats
Quan?
En el disseny i desenvolupament
En les instruccions d’ús
En informació específica
Mesures per portar-ho a terme
Al disseny i desenvolupament
- Verificació del compliment de tots els requeriments definits
- Verificació funcionament en usos indeguts raonablement previsible
- Transparència en les dades utilitzades
- Detallar del més global a més particular
- Adaptar llenguatge
- Gestionar la complexitat: escollir el model més simple que compleixi els requeriments.
- Utilitzar mètriques integrades en el cicle de vida del sistema
- Aplicar prudència
- Utilitzar causalitat i minimitzar correlacions
- Utilitzar contrafactualitat* (perquè una acció i no una altre i en quines circumstàncies l’acció hauria estat una altre. Pe. Justificar denegacions de subvencions i quan s’hauria acceptat)
Amb instruccions d’ús amb informació concisa, completa, correcta i clara que sigui pertinent, accessible i comprensible.
I informació específica que inclogui, entre d'altres:
- Identitat i dades de contacte del proveïdor
- Característiques, capacitats i limitacions del funcionament
- Finalitat
- Nivell de precisió, solidesa i ciberseguretat
- Riscos per usos imprevistos
- Explicació dels resultats
- Impacte en les persones i col·lectius
- Dades d’entrada
- Informació de sortida
- Canvis i funcionament predeterminat
- Mesures de supervisió humana
- Recursos informàtics i de hardware necessaris
- Descripció dels arxius de registre (ubicació i tipus d’informació continguda)
La precisió és la mesura quantitativa que indica si el sistema compleix la seva finalitat prevista. El RIA exigeix que aquests nivells siguin consistents durant tot el cicle de vida. No n'hi ha prou amb una xifra inicial; el proveïdor ha de definir llindars mínims acceptables a partir dels quals el sistema s'hauria de reentrenar o, fins i tot, aturar.
Mesures per portar-ho a terme
Pre-processament de les dades
- Representatives de la finalitat prevista
- Sense biaixos
- Per comparar resultats de diferents models, s’hauran d’entrenar i validar amb els mateixos conjunts de dades
- Caldrà documentar les tasques de pre-entrenament
Sobre-aprenentatge: Els conjunts de dades d’entrenament, prova i validació seran diferent
Ús de models apropiats: S’escolliran els més simples que satisfacin els requeriments establerts
Incertesa: El resultat anirà acompanyat d’un valor indicatiu de la confiança del resultat (pe. %)
Avaluació
- Bateria de proves: d’unitat i d'estrès
- Test d’integració per validació dels requeriments, segons la finalitat prevista i la precisió establerta
- Mecanismes per al seguiment i monitorització de la precisió i rendiment un cop en producció
Garantir la precisió: El proveïdor ha de facilitar els mecanismes per notificar la necessitat de supervisió humana
Un sistema sòlid és aquell que manté el seu rendiment davant d'errors en les dades d'entrada o canvis en l'entorn operatiu. La Guia 10 posa èmfasi en la degradació segura: si el sistema detecta que no pot operar correctament, ha de tenir mecanismes per interrompre el funcionament de forma controlada per evitar danys.
Propietats: Fiabilitat, Estabilitat, Sensibilitat, Rellevància, Assequibilitat
Ciberseguretat específica per a IA (Guia 11)
L'IA té vulnerabilitats úniques que el programari tradicional no coneix. Cal protegir el sistema contra l'enverinament de dades (data poisoning), els atacs adversaris (inputs dissenyats per enganyar el model) i els atacs a la confidencialitat del propi model.
Registres i Traçabilitat (Guia 12)
El sistema ha de generar registres esdeveniments automàtics (logs) durant tota la seva vida útil (Article 12 RIA). Aquests registres han de recollir els períodes d'ús, les dades d'entrada i, en sistemes biomètrics, la identitat de qui valida els resultats. L'ens local els ha de conservar durant un mínim de sis mesos.
Vigilància Continua (Guia 13)
És el procés pel qual el proveïdor recull i analitza l'experiència real d'ús per verificar que el sistema continua sent segur. Es materialitza en un Pla de Vigilància previ a la posada en marxa que ha de descriure com es detectaran les anomalies i quins indicadors s'usaran per mesurar-les.
Gestió d’Incidents Greus (Guia 14)
Davant d'una fallada que posi en risc la salut, la seguretat o els drets fonamentals, la reacció ha de ser immediata. El proveïdor ha de notificar els incidents greus a les autoritats (com l'AESIA) en terminis molt estrictes: des de 2 dies per a infraestructures crítiques fins a un màxim de 15 dies per a la resta de casos.
Documentació Tècnica (Guia 15)
És el "dossier mestre" que recull tota la informació del sistema (arquitectura, gestió de riscos, dades, proves) i que ha d'estar disponible per a les autoritats durant 10 anys des de la posada en marxa. La documentació tècnica ha d'incloure, entre d'altres:
Targeta model (Model Card)
Constitueixen una eina de transparència, solidesa i documentació tècnica imprescindible. Ha de contenir:
- La finalitat prevista, els col·lectius afectats, les consideracions ètiques, riscos i recomanacions.
- La dimensió del model incloent el tipus de model base, nombre de paràmetres en les configuracions clau, data de publicació, detalls de l’entrenament, validació i avaluació.
- Mesures de precisió, llindars de decisió, mesures d’incertesa i variabilitat, mesures de càlcul i origen dels valors, interpretabilitat del model, adaptabilitat i ús responsable
Targeta base de dades (Datasheets for datasets)
Donen visió holística de les mètriques de precisió i de la procedència de les dades utilitzades per a l’entrenament del model:
Què comporta tot això en les licitacions?
La contractació d’un sistema d’IA —especialment quan pot ser d’alt risc— obliga a traslladar tots aquests requeriments al Plec de Prescripcions Tècniques i al contracte. No es tracta d’afegir exigències abstractes, sinó de garantir que l’ens local disposarà, des del primer dia, de la informació i les eines necessàries per exercir un control efectiu sobre el sistema.
En primer lloc, cal exigir que el proveïdor acrediti que el sistema compleix els requisits del RIA abans de la seva posada en servei. Això implica la presentació de la Declaració UE de Conformitat, així com de tota la documentació tècnica que permet entendre la finalitat prevista, el context d’ús, les característiques essencials del sistema i del model, i les dades utilitzades per a l’entrenament, validació i prova. Quan el sistema ho requereixi —com en el cas de la biometria— aquesta acreditació haurà d’incloure també el certificat emès per un Organisme Notificat.
Aquesta documentació no es pot lliurar de manera genèrica. El proveïdor ha d’aportar fitxes descriptives clares i sintètiques (Model Cards i Data Sheets) que resumeixin el rendiment del sistema, les seves limitacions, els biaixos detectats i les mesures de mitigació aplicades. Aquestes fitxes són l’eina que permet a l’ens local entendre ràpidament què pot esperar del sistema i en quins punts cal exercir una supervisió reforçada.
La licitació també ha de garantir que el sistema ha estat dissenyat per a la supervisió humana. Això implica definir, ja en el contracte, com serà la Interfície Humà‑Màquina, quins rols tindran els usuaris, quina capacitat real tindrà l’Administració per intervenir, revisar decisions o aplicar una parada segura, i com es facilitarà l’accés als registres del sistema. Sense aquesta capacitat d’intervenció, la supervisió humana queda reduïda a una declaració d’intencions.
Un altre element clau és la vigilància postcomercialització. El proveïdor ha de lliurar abans del desplegament el seu Pla de Vigilància, explicant com monitorarà el funcionament del sistema un cop estigui en ús real, quins indicadors utilitzarà per detectar anomalies i com gestionarà els incidents greus. El contracte ha d’establir clarament els canals de comunicació, els terminis i les responsabilitats compartides en cas de fallada.
Finalment, la licitació ha d’integrar el checklist de requisits del RIA com a eina de verificació. Demanar al proveïdor l’autoavaluació completa del sistema permet a la mesa de contractació valorar el seu nivell de maduresa i identificar, abans de la posada en marxa, quines adaptacions són necessàries. Aquest enfocament assegura que la conformitat amb el RIA no es verifica al final del procés, sinó que es construeix des del disseny, es valida abans del desplegament i es manté durant tota la vida útil del sistema.