AI Act, articolo 9: trasformare i rischi in controlli e prove verificabili

Che cosa tratta questa guida e che cosa resta fuori

L’articolo 9 del regolamento europeo sull’intelligenza artificiale (AI Act) impone ai fornitori di sistemi di IA ad alto rischio di istituire, attuare, documentare e mantenere un sistema di gestione dei rischi. L’idea pratica sviluppata in questa guida è semplice: collegare ogni rischio individuato a una misura e definire come verificare se tale misura contribuisce a ridurlo.

La guida si limita a questo articolo. Non è una spiegazione completa del regolamento, una valutazione giuridica di un prodotto né un metodo sufficiente, da solo, per decidere se un sistema è ad alto rischio. Inoltre, non trasforma ogni strumento di IA in un sistema soggetto all’articolo 9. Occorre innanzitutto stabilire se il sistema e la finalità del suo impiego rientrano nell’ambito pertinente del regolamento. Solo allora ha senso utilizzare questa matrice come supporto operativo.

L’articolo stabilisce obblighi per i fornitori di sistemi di IA ad alto rischio. Questo non significa che chiunque utilizzi un sistema debba automaticamente istituire e mantenere il sistema di gestione dei rischi richiesto ai fornitori. Gli obblighi di altri soggetti, come i deployer, vanno analizzati separatamente. Per orientarti nel quadro più ampio, consulta anche le guide di Inferama su sicurezza, confronto tra sistemi e scoperta di strumenti di IA: non sostituiscono la verifica degli obblighi applicabili al caso specifico.

Nel corso dell’articolo distinguiamo due livelli. «Requisito del regolamento» indica quanto previsto dall’articolo 9. «Raccomandazione operativa» indica un modo pratico di organizzare il lavoro che può aiutare a dimostrare e documentare il processo, ma che non va confuso con un modulo o un campo imposto letteralmente dalla norma.

Verifica preliminare: il sistema rientra nell’ambito?

Prima di registrare i rischi ai sensi dell’articolo 9, identifica il sistema concreto e la finalità prevista. La classificazione non dipende soltanto dal fatto che il prodotto utilizzi un modello avanzato, che l’organizzazione lo consideri sensibile o che i risultati possano avere conseguenze importanti. Il regolamento definisce i sistemi ad alto rischio attraverso categorie e condizioni; la classificazione può dipendere dal modo in cui il sistema viene utilizzato e dalla funzione che svolge.

Come prima verifica, descrivi con precisione l’uso effettivo e previsto: chi utilizza il sistema, chi riceve o usa i risultati, quale decisione o processo supporta e in quale contesto viene integrato. Confronta poi questa descrizione con le disposizioni pertinenti del regolamento, comprese le categorie applicabili e le condizioni o eccezioni che possono incidere sulla classificazione. Se hai dubbi sulla categoria, sul ruolo dell’organizzazione o sull’applicazione temporale di un obbligo, chiedi una revisione giuridica prima di trattare una conclusione provvisoria come un dato certo.

Non classificare un sistema soltanto in base a una descrizione commerciale, alla tecnologia utilizzata o al nome di una categoria. Uno stesso sistema può avere impieghi diversi: la valutazione deve concentrarsi sul caso d’uso specifico che intendi esaminare. L’esempio di selezione delle candidature presentato più avanti è ipotetico e serve a mostrare come documentare un rischio. Non afferma che tutti i sistemi di selezione delle candidature abbiano automaticamente la stessa classificazione giuridica.

Annota quali informazioni sostengono la conclusione preliminare: documentazione del prodotto, finalità dichiarata, descrizione del processo e condizioni di deploy. Se la conclusione dipende da presupposti ancora da confermare, segnalali come questioni aperte. In questo modo eviti che la matrice trasformi un’ipotesi di classificazione in una premessa apparentemente definitiva.

Dal contesto a un rischio analizzabile

L’articolo 9 prevede un processo continuo e iterativo che copre il ciclo di vita del sistema. Per iniziare in modo utile, descrivi il contesto d’uso prima di elencare i possibili danni. Lo stesso risultato del sistema può avere conseguenze diverse a seconda di chi lo interpreta, degli altri controlli presenti e della possibilità che una persona corregga un errore prima che produca effetti.

Il regolamento fa riferimento ai rischi noti e ragionevolmente prevedibili per la salute, la sicurezza e i diritti fondamentali quando il sistema è utilizzato conformemente alla sua finalità prevista. Richiede inoltre di stimare e valutare i rischi che possono emergere nell’uso previsto e in condizioni di uso improprio ragionevolmente prevedibili. È quindi opportuno esaminare entrambi, senza trattare ogni possibilità remota come un rischio dimostrato.

Per ciascuno scenario, tieni distinti tre elementi: ciò che sai, l’ipotesi che vuoi verificare e il danno possibile. Per esempio, può essere un dato di fatto che il sistema produca una classificazione; un’ipotesi che la mancanza di alcuni dati aumenti la probabilità di una classificazione errata; e un possibile danno che una persona venga esclusa da una fase di valutazione senza un controllo adeguato. La prova dovrà stabilire se l’ipotesi è fondata e in quali condizioni.

Includi le persone potenzialmente interessate e le condizioni che possono modificare il risultato: qualità o assenza dei dati, lingua, ambiente d’uso, intervento umano, dipendenza da altri componenti e cambiamenti nel processo. Non fingere una certezza che non hai. È preferibile indicare quali informazioni mancano e come intendi raccoglierle, invece di presentare come misurazione un’ipotesi priva di riscontri.

Dal rischio a una misura pertinente

Dopo aver descritto lo scenario, definisci quale cambiamento potrebbe prevenire o ridurre il rischio e perché ti aspetti che funzioni. L’articolo 9 richiede misure di gestione dei rischi adeguate e rivolte ai rischi individuati. Stabilisce inoltre che i rischi siano eliminati o ridotti il più possibile dal punto di vista tecnico attraverso una progettazione e uno sviluppo adeguati; quando non possono essere eliminati, occorre applicare misure appropriate di mitigazione e controllo.

In pratica, una misura può riguardare la progettazione del sistema, la sua configurazione, le istruzioni o il modo in cui viene integrato nel processo. La scelta dipende dal rischio e dal sistema. Non dare per scontato che un avviso nell’interfaccia o un generico controllo umano siano sufficienti: descrivi che cosa farà la misura, quando si applica, chi può intervenire e quali sono i suoi limiti. Se, per un deploy adeguato, una persona deve ricevere informazioni o formazione, specifica che cosa deve sapere e come le verrà fornito; l’articolo contempla anche informazioni e formazione per i deployer, ove opportuno.

La motivazione di una misura deve essere collegata al meccanismo del rischio. Se il problema ipotizzato è che dati incompleti producano risultati inaffidabili, un controllo che si limita a registrare la data di esecuzione potrebbe non intervenire sulla causa. Si potrebbero invece valutare sistemi che rilevano dati incompleti, impediscono l’uso di un risultato non valido senza revisione o avvisano chi utilizza il sistema. Sono possibilità da verificare, non soluzioni universali: la prova deve mostrare se sono pertinenti ed efficaci nel contesto specifico.

Tieni presente che il regolamento collega la gestione dei rischi alle conoscenze e allo stato dell’arte, oltre che alla finalità prevista e all’uso improprio ragionevolmente prevedibile. La documentazione dovrebbe quindi spiegare perché è stata scelta una misura e quali informazioni hanno sostenuto la scelta. Se la misura non elimina il rischio, annota ciò che resta e le condizioni in cui il controllo potrebbe non funzionare.

Progettare le prove prima di eseguirle

L’articolo 9 prevede prove dei sistemi di IA ad alto rischio per individuare le misure di gestione dei rischi più appropriate. Stabilisce inoltre che, ove opportuno, le prove siano svolte in diverse fasi dello sviluppo e, in ogni caso, prima dell’immissione sul mercato o della messa in servizio. Il regolamento indica che le prove devono basarsi su metriche e soglie probabilistiche definite in anticipo e adeguate alla finalità prevista. L’articolo non stabilisce una metrica unica valida per tutti i sistemi.

Perché una prova sia utile a prendere una decisione, definisci prima lo scenario che copre, i dati o le condizioni coinvolti, il risultato che osserverai e il criterio che considererai sufficiente. Spiega perché quel criterio è adeguato all’uso previsto. Se lo stabilisci soltanto dopo aver visto i risultati, aumenta il rischio di adattare la valutazione a ciò che è già accaduto e di non rilevare problemi importanti.

Esamina anche le condizioni rilevanti per il rischio: per esempio dati mancanti, cambiamenti di lingua, casi limite, input al di fuori delle condizioni abituali o l’intervento umano previsto. La scelta degli scenari dovrebbe avere una motivazione documentata; non serve elencare casi senza relazione con l’uso. Se utilizzi un campione, spiegane i limiti e indica quali gruppi, situazioni o condizioni non rappresenta. Un risultato favorevole in una prova circoscritta non dimostra, da solo, che il sistema sia sicuro in ogni ambiente.

Il risultato può essere favorevole, insufficiente o inconcludente. Negli ultimi due casi, descrivi che cosa non ha funzionato o che cosa impedisce di concludere, modifica la misura se necessario e definisci una nuova prova. Conserva i risultati e le decisioni pertinenti come evidenza del modo in cui il rischio è stato gestito. L’obbligo di effettuare prove non dovrebbe ridursi alla conservazione di un punteggio: lo scopo è valutare misure adeguate e verificare il comportamento del sistema in relazione alla sua finalità.

Modello pratico: collegare rischio, controllo, prova e decisione

Una riga utile della matrice permette di seguire l’intera logica senza confondere una proposta di controllo con una misura già verificata. Nell’esempio ipotetico di selezione delle candidature, non si afferma che vi siano già prove di un pregiudizio o di un danno. Si mostra quali informazioni occorrerebbe raccogliere prima di decidere se un controllo riduce il rischio ipotizzato.

La misura deve rispondere allo scenario e la prova deve valutare quella misura, non limitarsi a esaminare il sistema in astratto. Nell’esempio, se lo scenario è che un dato mancante influisca su una classificazione che non viene poi controllata, una prova pertinente potrebbe esaminare che cosa accade quando quel dato manca e se si attiva la procedura di revisione prevista. I criteri specifici e il risultato non si possono inventare: vanno definiti e misurati per il sistema reale.

Registra separatamente chi ha preparato la valutazione, chi ha approvato una decisione interna e chi deve esaminare le questioni giuridiche. Attribuire queste funzioni può essere una buona pratica di governance, ma non assegnare all’articolo 9 un ruolo universale che il testo non specifica. La persona o l’entità tenuta ad agire dipende dal ruolo svolto ai sensi del regolamento e dal caso concreto.

Come gestire risultati insufficienti e rischi residui

Un risultato che non raggiunge il criterio previsto non diventa accettabile modificando retroattivamente la soglia. Registra il risultato così come si è verificato, spiega quale condizione non è stata soddisfatta e valuta se sia necessario modificare la progettazione, introdurre o cambiare una misura di mitigazione, intervenire sul processo di deploy o limitare l’uso esaminato. Pianifica poi una nuova valutazione, quando pertinente.

Se la prova non consente di giungere a una conclusione, indica il motivo: dati non adeguati, uno scenario non riproducibile, un campione limitato o una condizione d’uso non osservata. Anche l’incertezza è un’informazione importante. Specifica che cosa servirebbe per chiarirla e chi deve decidere se proseguire l’indagine, limitare l’uso o sottoporre la questione a un livello superiore.

Non descrivere un rischio come eliminato se l’unica azione svolta è stata ridurne la probabilità o limitarne l’impatto. La documentazione dovrebbe rendere visibili la differenza tra il rischio iniziale, l’effetto delle misure e ciò che non è ancora stato verificato. Così chi esamina il fascicolo può evitare di scambiare un’azione pianificata per un’efficacia dimostrata.

L’articolo 9 richiede di documentare il sistema di gestione dei rischi e le decisioni pertinenti. Come raccomandazione operativa, conserva insieme alla matrice le versioni delle prove, le condizioni di esecuzione, i risultati e il ragionamento alla base delle decisioni. Prima di stabilire i tempi di conservazione, verifica le disposizioni applicabili al sistema e all’organizzazione: questa guida non definisce un periodo universale.

Revisione durante il ciclo di vita e rapporto con altri processi

La gestione dei rischi prevista dall’articolo 9 non è una valutazione unica che termina una volta completata una prova. Deve funzionare come un processo continuo e iterativo lungo il ciclo di vita, con revisioni e aggiornamenti regolari e sistematici. Le informazioni raccolte dopo il deploy possono essere rilevanti per valutare i rischi; l’articolo contempla anche i dati raccolti tramite il monitoraggio post-commercializzazione a cui rimanda il regolamento.

Come proposta organizzativa, definisci quali cambiamenti possono attivare una revisione: modifiche rilevanti del sistema, variazioni della finalità o del contesto d’uso, problemi rilevati, nuove informazioni sui rischi o risultati del monitoraggio. Stabilisci chi riceve queste informazioni e come si decide se aggiornare l’analisi, le misure o le prove. Questi specifici fattori di attivazione sono una raccomandazione per rendere operativa la revisione, non un elenco letterale dell’articolo 9.

Se il sistema è già soggetto a requisiti di gestione dei rischi previsti da un’altra normativa dell’Unione, l’articolo 9 prevede, alle condizioni indicate dal regolamento, che il relativo sistema di gestione possa essere integrato nei processi richiesti da tale normativa o contribuirvi. Non dare per scontato che una procedura esistente soddisfi automaticamente tutti gli obblighi dell’AI Act: verifica quali rischi, evidenze e requisiti copre davvero ciascun processo.

La data di applicazione di un obbligo dipende dalle disposizioni temporali pertinenti e può richiedere la verifica delle modifiche e delle misure transitorie vigenti. Il calendario non si ricava dal solo articolo 9. Prima di fissare una data di conformità, controlla il testo ufficiale vigente e le disposizioni applicabili al tipo di sistema e al ruolo dell’organizzazione. Se la data incide su una decisione imminente, chiedi una consulenza giuridica aggiornata.

Verifiche pratiche prima di concludere la valutazione

Prima di considerare concluso il lavoro, verifica che ogni rischio sia descritto in modo comprensibile e che le osservazioni siano distinte dalle ipotesi. Controlla che ogni misura risponda a un rischio specifico, che la motivazione sia ricostruibile e che la prova includa criteri definiti prima dell’esecuzione. Se una misura non è stata testata, indicane lo stato come «in sospeso»; se una prova copre soltanto determinate condizioni, non estenderne il risultato ad altre.

Verifica inoltre che l’analisi riguardi la finalità e il contesto effettivamente esaminati, consideri i casi di uso improprio ragionevolmente prevedibili pertinenti e non trascuri le persone potenzialmente interessate. Documenta i limiti del lavoro e le questioni che richiedono una revisione giuridica o tecnica. Quando intervengono processi già esistenti, controlla che cosa coprono, quali evidenze forniscono e quali lacune restano.

L’articolo 9 non è una certificazione automatica della sicurezza di un sistema né una garanzia che non si verifichino danni. È il fondamento di un processo di gestione dei rischi che deve essere mantenuto e documentato. L’utilità di una matrice non si misura dal numero di righe, ma dalla possibilità di capire perché è stata scelta una misura, quale prova la sostiene, quale risultato è stato osservato e quali questioni restano aperte.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.