Hai mappato i tuoi sistemi AI, hai scoperto che almeno uno ricade nella categoria "alto rischio", e adesso devi fare l'audit. Bene. Cattiva notizia: non esiste ancora uno standard ISO consolidato per l'AI Act. Buona notizia: il regolamento e le linee guida CE permettono di costruire un framework operativo già oggi. Questo articolo è il metodo che usiamo in studio. Lo lascio qui per intero, perché chi deve farlo abbia almeno una mappa.
Come fare un audit AI Act per sistemi ad alto rischio: metodo operativo in 7 fasi
L'audit AI Act per sistemi ad alto rischio è la procedura tecnica che verifica la conformità di un sistema AI ai requisiti del Regolamento (UE) 2024/1689, articoli 8-15. Non è un audit legale. Non è un check di sicurezza informatica. È un'analisi strutturata che attraversa documentazione tecnica, dataset di training, processi di supervisione umana, robustezza, accuratezza, e tracciabilità.
Si fa prima della messa sul mercato (per provider) o prima dell'attivazione (per deployer in contesti critici). Va ripetuto a ogni modifica sostanziale del sistema o ogni 12 mesi, comunque.
Vediamo come si struttura, fase per fase.
Cosa qualifica un sistema come "alto rischio"
Prima di partire con l'audit, devi confermare che il sistema in oggetto sia davvero ad alto rischio. Molti audit partono male perché il classifying è approssimativo. I sistemi ad alto rischio sono definiti nell'Annex III dell'AI Act e includono otto categorie principali: identificazione biometrica, infrastrutture critiche, istruzione e formazione professionale, occupazione e gestione del personale, accesso a servizi essenziali (credito, assicurazioni), forze dell'ordine, immigrazione e controllo frontiere, amministrazione della giustizia e processi democratici.
Un sistema rientra nella categoria solo se utilizzato in uno di questi contesti e se influenza materialmente l'esito di una decisione che riguarda persone fisiche. Un algoritmo di smart bidding su Google Ads non è alto rischio. Un sistema di scoring per la concessione di un prestito è alto rischio. Un chatbot di customer care non è alto rischio. Un sistema di triage in pronto soccorso è alto rischio.
Se hai un dubbio sulla classificazione, risolvilo prima. Auditing su un sistema sbagliato è tempo perso. Auditing fatto male un sistema corretto può costare fino al 3% del fatturato globale.
Fase 1 – Definizione dello scope e dei confini del sistema
Prima ora di lavoro, prima ancora di toccare codice o documentazione. L'audit AI Act non "audita" "l'azienda" o "il prodotto". Audita un singolo sistema AI identificato univocamente. Significa che devi delimitare con precisione cosa entra nel perimetro:
- Nome ufficiale del sistema e versione del modello (es. Credit Scoring Engine v2.3.1)
- Provider effettivo: chi ha sviluppato il modello, chi lo distribuisce, chi lo deploya
- Contesto operativo: dove gira, con quali integrazioni, con quale livello di intervento umano
- Categorie di utenti finali impattati: persone fisiche, persone giuridiche, entrambe
- Boundary tecnici: cosa è parte del sistema AI e cosa è il sistema ospitante (un database condiviso, un CRM, un'API esterna).
Deliverable di fase: documento di scope di 2-3 pagine firmato dal responsabile del progetto. Senza questo, l'audit non è difendibile davanti a un'autorità.
Fase 2 – Verifica della documentazione tecnica (Art. 11)
L'Articolo 11 del regolamento richiede una documentazione tecnica completa per ogni sistema ad alto rischio, conforme all'Annex IV. Questo documento deve esistere prima dell'audit, non essere prodotto durante.
L'audit verifica che la documentazione contenga, come minimo: descrizione generale del sistema con scopo, sviluppatore, versione; specifiche dei dati di training, validazione e test; descrizione dell'architettura del modello e dei suoi parametri principali; metodologia di training e ottimizzazione; sistema di gestione dei rischi attivo durante il ciclo di vita; misure di supervisione umana implementate; metriche di accuratezza, robustezza e cybersecurity; descrizione del sistema di monitoraggio post-mercato.
Se uno solo di questi blocchi manca o è incompleto, l'audit si ferma qui. La documentazione tecnica non è un nice-to-have: è la base difensiva in caso di controllo. Senza, il sistema è non-conforme by default.
Deliverable di fase: matrice di conformità documentale, con per ciascuna delle 9 sezioni Annex IV lo status: complete / partial / missing, e per le incomplete una lista di gap.
Fase 3 – Audit dei dataset di training, validazione, test (Art. 10)
L'Articolo 10 è probabilmente il più sottovalutato e il più tecnicamente complesso. Riguarda la data governance del sistema AI. L'audit verifica che i dataset usati siano: pertinenti rispetto allo scopo dichiarato del sistema; sufficientemente rappresentativi della popolazione di destinazione; privi di errori statistici noti, ove possibile; coerenti con i requisiti di accuratezza richiesti; documentati nelle loro origini, metodologie di raccolta, pre-processing applicato, e bias noti.
In pratica significa: chiedere al data team la data sheet di ogni dataset, verificare i protocolli di sampling, controllare l'esistenza di test di fairness, accertarsi che il preprocessing non introduca distorsioni sistematiche.
Trabocchetto frequente: i dataset di terzi (acquistati o open source) non sono esenti da queste verifiche. Anzi, sono spesso il punto di fragilità maggiore perché il provider del sistema non conosce realmente come sono stati costruiti. Deliverable di fase: report di data governance con valutazione qualitativa di ciascun dataset usato, segnalazione dei bias residui, e raccomandazioni di mitigation.
Fase 4 – Verifica della supervisione umana (Art. 14)
Questa fase è dove la maggior parte dei sistemi cade. La supervisione umana non è "c'è un umano nel processo". È un set di requisiti specifici. Il sistema deve essere progettato in modo che persone fisiche possano: comprendere le capacità e i limiti del sistema; rimanere consapevoli della tendenza all'automation bias; interpretare correttamente l'output; decidere in autonomia di non usare l'output o di sovrascriverlo; fermare il sistema attraverso un meccanismo di "stop" accessibile.
L'audit verifica che queste capacità siano strutturalmente possibili, non solo dichiarate. Significa testare l'interfaccia, intervistare gli operatori reali, verificare i log degli override, controllare che esistano procedure di escalation.
Esempio concreto: un sistema di scoring del rischio creditizio dove l'addetto può "rifiutare l'output AI" cliccando un pulsante, ma poi non ha visibilità sui criteri usati né può proporre alternative, non soddisfa l'Art. 14. La supervisione è formale ma non sostanziale.
Deliverable di fase: rapporto sulla supervisione umana con elenco delle capacità verificate, gap rispetto ai requisiti, e raccomandazioni di redesign dell'interazione.
Fase 5 – Test di accuratezza, robustezza, cybersecurity (Art. 15)
Qui l'audit diventa più tecnico. L'Articolo 15 richiede livelli adeguati di accuratezza, robustezza e cybersecurity, dichiarati nella documentazione e mantenuti durante tutto il ciclo di vita. Per accuratezza: il sistema deve dichiarare metriche misurabili (precision, recall, F1, error rate a seconda del task) e mantenerle entro soglie note. L'audit verifica i test di accuratezza eseguiti, la frequenza, e se le metriche dichiarate corrispondono a quelle reali in produzione.
Per robustezza: il sistema deve essere resiliente a errori, anomalie, e cambiamenti dell'ambiente operativo. Si verifica con stress test, test di drift detection, test di degradazione controllata.
Per cybersecurity: il sistema deve essere protetto contro attacchi avversari noti, inclusi data poisoning, model evasion, model inversion. L'audit verifica i controlli implementati, non solo le policy dichiarate.
Deliverable di fase: test report tripartito con risultati quantitativi per ciascuno dei tre assi, comparati con le soglie dichiarate nella documentazione tecnica.
Fase 6 – Verifica del logging e tracciabilità (Art. 12)
L'Articolo 12 impone che i sistemi ad alto rischio mantengano log automatici delle proprie operazioni, in modo da garantire tracciabilità ex post. Questi log devono includere, come minimo: timestamp di ogni inferenza, identificativo dell'input, output prodotto, eventuali interventi umani, configurazione del modello al momento dell'inferenza. La conservazione deve essere proporzionata al rischio e al ciclo di vita del sistema – tipicamente non meno di 6 mesi per sistemi a impatto medio, fino a diversi anni per sistemi a impatto alto.
L'audit verifica che il logging sia attivo, immutabile, protetto da accessi non autorizzati, e che esista una procedura documentata di accesso ai log in caso di indagine.
Trabocchetto frequente: molti team confondono i log applicativi (per debug) con i log di tracciabilità AI Act. Non sono la stessa cosa. I log AI Act devono essere strutturati per finalità di audit terzo, non per finalità di sviluppo interno.
Deliverable di fase: scheda di conformità logging con esempio di log estratto, tempo di retention, e procedura di accesso documentata.
Fase 7 – Risk management system (Art. 9) e piano di monitoraggio post-mercato (Art. 72)
L'ultima fase chiude il cerchio. L'AI Act non chiede un audit una tantum: chiede un sistema di gestione del rischio continuativo (Art. 9) e un piano di monitoraggio post-mercato (Art. 72). Il risk management system deve identificare i rischi noti e prevedibili del sistema, stimare e valutare i rischi che possono emergere quando il sistema è in uso, prevedere misure di mitigation, e iterare il processo continuamente.
Il monitoraggio post-mercato deve raccogliere dati sulle performance reali del sistema una volta deployato, identificare incidenti gravi entro 15 giorni (Art. 73), e alimentare il risk management system con i dati raccolti. L'audit verifica che entrambi i sistemi siano formalizzati, attivi, e con ruoli responsabili assegnati. Non è sufficiente che esistano in policy – devono essere operativi.
Deliverable finale dell'audit: dossier completo con i 7 deliverable di fase + un executive summary di 2-3 pagine che dichiari lo status complessivo (conforme / conforme con riserve / non conforme), le priorità di intervento, e il calendario di follow-up.
Durata realistica di un audit AI Act per un sistema ad alto rischio
Per un sistema di complessità media (un modello in produzione con dataset documentati e qualche integrazione esterna), l'audit completo richiede tipicamente: 3-5 giornate di lavoro effettivo del consulente lead, 2-3 giornate complessive dell'audit team, 4-6 settimane di durata calendario considerando le interazioni con il cliente, e un budget anche di migliaia di euro per audit standalone e fee mensili più contenuti se inserito in un engagement continuativo.
Audit più rapidi esistono, ma producono dossier che non reggono un'indagine seria. Audit più lenti sono giustificati solo per sistemi enterprise complessi (multipli modelli interagenti, regulated industry, scope multi-paese).
I tre errori più frequenti nell'audit AI Act
Errore 1 – Iniziare dall'audit invece che dalla classificazione. Si finisce per applicare il framework alto rischio a sistemi che non lo sono, sovra-investendo. O peggio: si saltano sistemi che lo sono, sotto-investendo. Errore 2 – Auditare solo la documentazione. La carta non basta. Un sistema può avere documentazione perfetta e implementazione inadeguata. L'audit deve sempre testare il sistema reale, non solo leggere quello dichiarato. Errore 3 – Trattare l'audit come evento, non come processo. L'AI Act richiede aggiornamenti continui. Audit una tantum significa essere conformi a una data e non conformi sei mesi dopo. Costoso e inutile.
Cosa fare se non hai un team interno per farlo
Se la tua azienda non ha un team con competenze trasversali (legali, data science, security, processi), l'opzione realistica è l'audit affidato a un consulente esterno con metodo strutturato. Il deliverable, in ogni caso, deve restare tuo: il dossier diventa parte del fascicolo aziendale di compliance, accessibile in caso di controllo da parte dell'autorità nazionale designata. Se vuoi capire come questo metodo si applica al tuo caso concreto, possiamo fare un primo briefing di 30 minuti per chiarire scope, scadenze, e priorità. Scrivimi qui.
Andrea Testa è docente di AI Act al CIELS e di AI Marketing all'Università IULM. Membro AIPIA. Diamond Google Ads Product Expert. Per audit AI Act su sistemi ad alto rischio, consulenza strategica e formazione AI literacy del team, richiedi un briefing.
