Gestione del rischio IA: dai framework a un programma operativo unico

In sintesi

• La gestione del rischio IA è un programma operativo unico, non un glossario di framework: un ciclo di responsabilità che identifica, valuta, mitiga e monitora i danni di ogni sistema di IA in produzione.
• Un programma efficace fa convergere NIST AI RMF, ISO/IEC 42001 con ISO/IEC 23894 e l’Article 9 dell’EU AI Act sullo stesso insieme di controlli, titolari e prove, invece di gestire tre percorsi separati.
• I rischi si distribuiscono su quattro famiglie: dati, modello, sicurezza operativa e diritti fondamentali. Ognuna richiede misure e metriche proprie.
• Gli artefatti durevoli (inventario dei sistemi IA, registro dei rischi, mappatura dei controlli, prove, firma sul rischio residuo) sono ciò che un revisore o un organismo notificato esamina davvero.
• Senza un sistema operativo per la governance dell’IA che tenga insieme questi elementi, il rischio resta sparso tra fogli di calcolo e conoscenza tacita, quindi impossibile da dimostrare in sede di audit.

Che cos’è la gestione del rischio IA?

La gestione del rischio IA è la disciplina che individua, misura, riduce e sorveglia i danni che un sistema di intelligenza artificiale può produrre lungo tutto il suo ciclo di vita, dalla progettazione fino al ritiro. L’oggetto non è soltanto il modello: comprende i dati che lo alimentano, le decisioni che genera, le persone che ne subiscono gli effetti e il contesto operativo in cui viene impiegato. Un modello di scoring creditizio e un assistente conversazionale interno presentano profili di rischio molto diversi, anche quando condividono la stessa architettura tecnica. La differenza rispetto alla gestione tradizionale del rischio d’impresa sta nella natura del sistema che si vuole governare. Il rischio finanziario o operativo classico presuppone processi deterministici e ripetibili: date le stesse premesse, l’esito è prevedibile. Un modello di IA, invece, è probabilistico e sensibile ai dati. Il suo comportamento può degradare nel tempo senza che nessuno tocchi una riga di codice e produrre risultati corretti in media ma gravemente errati su singoli casi. Per questo la disciplina si avvicina, ma non coincide, con la conformità nella gestione del rischio applicata ad altri ambiti. Anche il confronto con il rischio di cybersicurezza è utile ma parziale. La sicurezza informatica difende un perimetro da attori ostili e da vulnerabilità note. La gestione del rischio IA include quel perimetro, ma vi aggiunge danni che nascono dal funzionamento normale del sistema: una discriminazione statistica, una spiegazione fuorviante, un errore che colpisce sempre lo stesso gruppo di persone. Il rischio è insito nel modo in cui il modello apprende e generalizza, e va quindi trattato con strumenti di valutazione specifici, non con i soli controlli ereditati dalla sicurezza. Questa distinzione determina quali competenze servono nel gruppo di lavoro e quali prove un auditor si attende.

Perché la gestione del rischio IA è cruciale adesso

La pressione più concreta arriva dalla normativa. Per i sistemi ad alto rischio, l’EU AI Act impone al fornitore di istituire, attuare, documentare e mantenere un sistema di gestione del rischio, descritto nell’Article 9 come un processo continuo e iterativo esteso a tutto il ciclo di vita, sottoposto a riesame sistematico e programmato. Non si tratta di una valutazione una tantum da archiviare, ma di un meccanismo vivo, sottoposto a riesame periodico, che deve identificare i rischi per la salute, la sicurezza e i diritti fondamentali e mantenere accettabile il rischio residuo. Al vincolo giuridico si sommano quello reputazionale e quello operativo. Un modello che si degrada silenziosamente può erodere ricavi e fiducia prima che qualcuno se ne accorga, mentre continua a restituire risposte apparentemente plausibili. Il quadro non si limita all’Unione europea: normative come il Colorado AI Act estendono obblighi analoghi ad altre giurisdizioni, e chi fornisce sistemi su scala internazionale deve gestire più regimi in parallelo. Esiste poi un problema di visibilità che precede qualsiasi controllo. Molte organizzazioni non sanno con esattezza quanti sistemi di IA siano in uso al proprio interno, perché reparti e singoli dipendenti adottano strumenti in autonomia. Questo fenomeno, noto come shadow AI, significa che una parte del rischio non è nemmeno mappata. Non si può governare ciò che non si conosce: per questo il primo passo di ogni programma serio consiste nel costruire un inventario affidabile dei sistemi effettivamente in funzione. In Italia, l’attenzione del Garante per la protezione dei dati personali verso i trattamenti automatizzati rende questa mappatura ancora più urgente per chi elabora dati personali.

Le principali categorie di rischio IA

Ragionare per categorie evita di trattare il rischio IA come un blocco indistinto. Ciascuna famiglia richiede prove, metriche e responsabili diversi, e la stessa applicazione può ricadere in più famiglie insieme.

Rischi legati ai dati

I dati sono la materia prima di ogni modello e la prima fonte di rischio. La scarsa qualità (valori mancanti, etichette errate, campioni non rappresentativi) si traduce in previsioni inaffidabili. La provenienza incerta espone a problemi di licenza e di legittimità dell’uso. Il trattamento di dati personali solleva questioni di privacy che vanno affrontate a monte, spesso attraverso una valutazione d’impatto sul trattamento o sui diritti fondamentali. A questi si aggiunge il data poisoning, cioè la manipolazione deliberata dei dati di addestramento per introdurre comportamenti dannosi. Controllare la filiera dei dati è la condizione preliminare di ogni affermazione sull’affidabilità del sistema.

Rischi legati al modello

Il modello introduce rischi propri, indipendenti dalla qualità dei dati. Il bias algoritmico produce esiti sistematicamente sfavorevoli verso determinati gruppi, anche in assenza di intenzione discriminatoria. Il drift descrive il decadimento delle prestazioni quando la realtà si allontana dai dati di addestramento. Nei modelli generativi si aggiunge l’allucinazione, cioè la produzione di contenuti plausibili ma falsi. La robustezza misura quanto il modello resti stabile di fronte a input insoliti o perturbati. Misurare questi rischi richiede test mirati e metriche adeguate: i benchmark per i modelli linguistici offrono un punto di partenza, ma vanno integrati con valutazioni sul caso d’uso specifico.

Rischi operativi e di sicurezza

Una volta in produzione, il sistema è esposto a minacce che ne toccano funzionamento e sicurezza. Gli attacchi avversari, catalogati in modo sistematico da MITRE ATLAS, sfruttano le peculiarità dei modelli di IA per estrarre dati, aggirare i controlli o forzare comportamenti indesiderati. L’uso improprio, deliberato o accidentale, comprende l’impiego del sistema fuori dallo scopo previsto, un rischio rilevante per i modelli di IA per finalità generali, riutilizzabili in contesti non previsti dal fornitore. Vanno infine garantite disponibilità e continuità del servizio: un sistema integrato in un processo critico eredita i requisiti di resilienza dell’infrastruttura che lo ospita.

Rischi etici, giuridici e per i diritti fondamentali

L’ultima famiglia riguarda gli effetti del sistema sulle persone. La discriminazione, quando un modello penalizza gruppi protetti, è al tempo stesso un rischio etico e una violazione giuridica. La mancanza di trasparenza impedisce alle persone di comprendere e contestare le decisioni che le riguardano: qui la spiegabilità dei sistemi di IA diventa un requisito operativo, non un abbellimento. La supervisione umana, prevista dalla normativa europea per i casi ad alto rischio, richiede che una persona competente possa intervenire, sospendere o ribaltare una decisione automatizzata. Sono i rischi più difficili da quantificare e per questo i più insidiosi, perché sfuggono alle metriche puramente tecniche.

Il ciclo di vita della gestione del rischio IA

Il valore di un programma non sta nell’elenco dei rischi, ma nel ciclo che li tiene sotto controllo nel tempo. Un ciclo unico (identificare, valutare, mitigare, monitorare) permette di trattare rischi eterogenei con lo stesso linguaggio, gli stessi titolari e le stesse prove. Le quattro fasi che seguono non sono sequenziali una sola volta: si ripetono, perché ogni cambiamento del sistema o del contesto rimette in moto il ciclo.

Identificare e mappare

Tutto parte dalla conoscenza di ciò che si possiede. La fase di identificazione costruisce e mantiene l’inventario dei sistemi IA, ne descrive il contesto, lo scopo previsto, i dati utilizzati e le persone potenzialmente interessate. Questa fase corrisponde alla funzione Map di NIST AI RMF e alle attività di identificazione del rischio di ISO/IEC 23894. Ancorare l’inventario a un framework di governance dell’IA evita che la mappatura resti scollegata dal resto del programma, perché ogni valutazione successiva poggia su questa base.

Valutare e misurare

Identificati i rischi, occorre stimarne probabilità e impatto e, dove possibile, misurarli con test riproducibili. Alla valutazione qualitativa, che ordina i rischi per gravità, si affianca la misurazione quantitativa: accuratezza per sottogruppi, tassi di errore, indicatori di robustezza, metriche di equità. La funzione Measure di NIST AI RMF e le attività di analisi e valutazione di ISO/IEC 23894 inquadrano questa fase, mentre l’Article 9 richiede esplicitamente di stimare e valutare i rischi e di usare i test per individuare le misure.

Mitigare e gestire

La mitigazione traduce la valutazione in controlli concreti: filtri sui dati, vincoli sull’output, soglie di confidenza, meccanismi di supervisione umana, limiti d’uso documentati. Ogni controllo va assegnato a un responsabile e collegato al rischio che riduce. Al termine resta sempre un rischio residuo, cioè la quota che le misure adottate non eliminano. La normativa europea impone che tale rischio residuo sia giudicato accettabile, e questo giudizio deve essere formalizzato: una firma, una data, un responsabile identificabile. Questa fase corrisponde alla funzione Manage di NIST AI RMF e al trattamento del rischio previsto da ISO/IEC 23894, integrato dai controlli dell’Annex A di ISO/IEC 42001.

Monitorare e rivedere

Nessuna mitigazione è definitiva. Il monitoraggio continuo osserva il drift, la qualità dell’output e i nuovi rischi, e collega il sistema a una procedura di risposta agli incidenti. Il monitoraggio della conformità dei sistemi di IA trasforma i controlli statici in un presidio permanente, mentre la sorveglianza post-commercializzazione impone di reagire agli eventi reali. Quando si verifica un malfunzionamento grave, entrano in gioco gli obblighi di segnalazione degli incidenti previsti dalla normativa. Questa fase chiude il ciclo e lo riapre: le informazioni raccolte alimentano una nuova identificazione, in linea con la natura continua e iterativa richiesta sia da NIST AI RMF sia dall’Article 9.

Framework e standard

I tre riferimenti principali non sono alternativi ma complementari: descrivono lo stesso lavoro da angolazioni diverse. Ricondurli a un unico programma, come illustra la mappatura tra NIST, ISO 42001 ed EU AI Act, evita di duplicare gli sforzi.

NIST AI RMF

Il NIST AI RMF, pubblicato dal NIST nel 2023, organizza il lavoro attorno a quattro funzioni fondamentali: Govern, Map, Measure e Manage. Come precisa il documento NIST AI 100-1, Govern è trasversale, perché definisce cultura, ruoli e strutture che sostengono tutte le altre funzioni. I gruppi di lavoro, in pratica, partono da Map per stabilire il contesto, proseguono con Measure per valutare probabilità e impatto e concludono con Manage per trattare i rischi, come descritto nelle risorse del NIST AIRC. Il framework è volontario e iterativo, adattabile a organizzazioni di ogni dimensione.

ISO/IEC 42001 e ISO/IEC 23894

I due standard ISO svolgono ruoli distinti e vanno letti insieme. ISO/IEC 42001 definisce un sistema di gestione dell’IA (AIMS) certificabile: stabilisce il «che cosa» e il «dove», cioè la struttura organizzativa, le politiche e i processi di governo. ISO/IEC 23894 fornisce invece la guida sul processo di gestione del rischio, il «come»: identificazione, analisi, valutazione e trattamento lungo il ciclo di vita. La relazione tra i due è precisa: ISO/IEC 42001 importa ISO/IEC 23894 come metodo di riferimento per le proprie clausole sul rischio, come documentato dalla pagina ufficiale ISO. Chi punta alla certificazione ottiene così una struttura verificabile e un metodo coerente.

EU AI Act, Article 9

L’Article 9 dell’EU AI Act è l’unico dei tre ad avere forza di legge per i sistemi ad alto rischio. Richiede un sistema di gestione del rischio istituito, attuato, documentato e mantenuto come processo continuo e iterativo esteso a tutto il ciclo di vita, con riesame sistematico. Impone di identificare i rischi per salute, sicurezza e diritti fondamentali, di stimarli e valutarli, di adottare misure mirate e di giudicare accettabile il rischio residuo. Consente inoltre di combinare questo processo con quelli richiesti da altre norme dell’Unione, evitando duplicazioni. La tabella che segue mostra come le tre fonti si allineino sullo stesso programma.

Fase del programma	NIST AI RMF	ISO/IEC 42001 + 23894	EU AI Act Article 9
Governance e responsabilità	Govern	Clausole di leadership e pianificazione	Sistema di gestione del rischio documentato e mantenuto
Identificare e contestualizzare	Map	Identificazione del rischio (23894)	Identificare i rischi per salute, sicurezza e diritti
Valutare e misurare	Measure	Analisi e valutazione (23894)	Stimare e valutare i rischi, test
Trattare e accettare	Manage	Trattamento (23894); controlli dell’Annex A	Adottare misure; rischio residuo accettabile
Monitorare e rivedere	Govern e Manage	Clausole di valutazione e miglioramento	Processo continuo, riesame sistematico

Costruire un programma di gestione del rischio IA: ruoli, artefatti, controlli

Un programma esiste davvero solo quando produce artefatti che qualcun altro può ispezionare. La prima decisione riguarda la responsabilità, perché la gestione del rischio IA non appartiene a una singola funzione: coinvolge il proprietario del sistema, il team tecnico che governa dati e modello, la funzione legale e di conformità e un organo di supervisione che approva il rischio residuo. Definire con chiarezza chi decide, chi esegue e chi firma è la premessa di tutto il resto. Attorno a questi ruoli si costruiscono cinque artefatti durevoli. L’inventario dei sistemi IA elenca ogni sistema in uso, con scopo, titolare e classificazione di rischio. Il registro dei rischi raccoglie i rischi identificati per ciascun sistema, con probabilità, impatto e stato. La mappatura dei controlli collega ogni rischio alle misure che lo riducono e ai responsabili di quelle misure. Le prove documentano l’effettiva attuazione dei controlli: risultati dei test, log, verbali di riesame. La firma sul rischio residuo, infine, registra chi ha accettato quale livello di rischio, quando e con quali motivazioni. Questi artefatti non hanno valore solo interno. Sono esattamente ciò che un revisore o un organismo notificato chiede di vedere, ed è per questo che la loro tracciabilità e verificabilità va progettata fin dall’inizio, non ricostruita a posteriori. Un registro dei rischi mantenuto con continuità, collegato a controlli e prove, trasforma un adempimento in un vantaggio operativo: riduce i tempi di audit e rende ripetibili le decisioni, anche quando l’AgID o un cliente esigente chiede conto di come un sistema è governato.

Errori frequenti nella gestione del rischio IA

Alcuni errori ricorrono con regolarità e vanificano anche i programmi meglio intenzionati. Il primo è trattare la gestione del rischio come un adempimento una tantum: si compila una valutazione all’avvio, la si archivia e non la si aggiorna più. Sia l’Article 9 sia NIST AI RMF sono espliciti nel chiedere un processo continuo, e il monitoraggio permanente è ciò che distingue un presidio reale da un documento morto. Il secondo errore è confondere la gestione del rischio IA con la sola sicurezza informatica, dedicando risorse agli attacchi esterni e ignorando i danni prodotti dal funzionamento normale del modello, come bias e allucinazioni. Il terzo è la mancanza di titolari: senza responsabili nominati, nessuno mantiene il registro e nessuno firma il rischio residuo. Il quarto è la ricerca di un punteggio unico che riassuma tutto: comprimere famiglie di rischio così diverse in un solo numero nasconde proprio i casi limite che causano i danni maggiori. Il quinto, spesso il più costoso, è ignorare i sistemi non censiti: ogni strumento adottato in autonomia dai reparti resta fuori dal perimetro finché non provoca un incidente.

Come AI Sigil rende operativa la gestione del rischio IA

AI Sigil è pensato per i settori regolamentati, dove la gestione del rischio deve reggere l’esame di un auditor. La piattaforma tiene insieme in un unico luogo gli artefatti che questo articolo ha descritto: l’inventario dei sistemi IA, il registro dei rischi, la mappatura dei controlli, le prove e la firma sul rischio residuo. Invece di rincorrere tre framework separati, il programma li fa convergere su un solo insieme di controlli, titolari ed evidenze, allineando NIST AI RMF, ISO/IEC 42001 con ISO/IEC 23894 e l’Article 9. Chi valuta se acquistare uno strumento dedicato o assemblare soluzioni diverse può confrontare le due strade nella comparazione tra piattaforma di conformità e stack di strumenti, per capire quale approccio produca prove difendibili con meno attrito.

Domande frequenti

Quali sono i quattro principali tipi di rischio dell’IA? Le quattro famiglie più diffuse sono i rischi legati ai dati (qualità, provenienza, privacy, data poisoning), i rischi legati al modello (bias algoritmico, drift, allucinazioni, robustezza), i rischi operativi e di sicurezza (attacchi avversari, uso improprio, disponibilità del servizio) e i rischi etici, giuridici e per i diritti fondamentali (discriminazione, mancanza di trasparenza, supervisione umana insufficiente). Uno stesso sistema può ricadere in più famiglie, e ciascuna richiede metriche, controlli e responsabili propri, non un unico punteggio aggregato.

Come viene utilizzata l’IA nella gestione del rischio? Il termine ha due significati da non confondere. Gestire il rischio dell’IA significa governare i danni che i sistemi di intelligenza artificiale possono causare. Usare l’IA per la gestione del rischio significa invece impiegare modelli per attività di risk management in altri ambiti, ad esempio rilevare frodi o individuare anomalie. Nel secondo caso, quei modelli diventano essi stessi sistemi di IA da governare, e vanno quindi inseriti nell’inventario e nel registro dei rischi.

Esiste una «regola del 30%» nella gestione del rischio IA? No. Nessuno dei riferimenti riconosciuti, né NIST AI RMF, né ISO/IEC 42001 con ISO/IEC 23894, né l’Article 9 dell’EU AI Act, definisce una «regola del 30%». È una formula che circola online senza fondamento in alcuna metodologia consolidata. La soglia di rischio accettabile non è un numero universale: dipende dal caso d’uso, dall’impatto sulle persone e dai vincoli normativi, e va stabilita e documentata per ciascun sistema. Diffidare delle percentuali preconfezionate è già un buon principio di governance.

In cosa si differenzia la gestione del rischio IA dalla gestione del rischio di cybersicurezza? La cybersicurezza difende un sistema da attori ostili e da vulnerabilità note, e questa protezione resta necessaria anche per l’IA. La gestione del rischio IA la comprende, ma vi aggiunge i danni che nascono dal funzionamento normale del modello: bias statistici, allucinazioni, drift, decisioni non spiegabili. Questi effetti si producono senza alcun aggressore, perché sono insiti nel modo in cui il modello apprende. Servono quindi competenze e metriche aggiuntive rispetto ai controlli tradizionali di sicurezza.

Quale framework conviene adottare per la gestione del rischio IA? La scelta non è esclusiva, perché i tre riferimenti sono complementari. NIST AI RMF offre un metodo volontario e flessibile per strutturare il programma. ISO/IEC 42001 con ISO/IEC 23894 fornisce un sistema di gestione certificabile e una metodologia di rischio coerente. L’Article 9 dell’EU AI Act è obbligatorio per i sistemi ad alto rischio in Europa. Chi opera nell’Unione parte quindi dagli obblighi dell’Article 9 e li soddisfa appoggiandosi al metodo NIST AI RMF e agli standard ISO.

Chi è responsabile della gestione del rischio IA in un’organizzazione? La responsabilità è condivisa ma va assegnata in modo esplicito. Il proprietario del sistema risponde dello scopo d’uso, il team tecnico governa dati e modello, la funzione legale e di conformità interpreta gli obblighi e un organo di supervisione approva il rischio residuo. La direzione stabilisce la cultura e alloca le risorse, in linea con la funzione Govern di NIST AI RMF. L’elemento decisivo è che ogni artefatto abbia un titolare nominato: senza responsabili identificabili, le prove restano orfane e le decisioni non sono attribuibili in sede di audit.

Conclusione

La gestione del rischio IA rende governabile ciò che altrimenti resterebbe imprevedibile. Il suo valore non sta nel numero di framework citati, ma nella capacità di ricondurre NIST AI RMF, ISO/IEC 42001 con ISO/IEC 23894 e l’Article 9 a un unico ciclo di responsabilità che identifica, valuta, mitiga e monitora i rischi con continuità. Ciò che rende il programma credibile sono gli artefatti durevoli: un inventario aggiornato, un registro dei rischi collegato ai controlli, le prove della loro attuazione e una firma esplicita sul rischio residuo. Sono questi elementi, non le dichiarazioni di intenti, che un revisore o un organismo notificato esamina. Costruirli fin dall’inizio, all’interno di un sistema di governance dell’IA coerente, trasforma un obbligo normativo in un vantaggio operativo duraturo.