Spiegabilità dell’IA: guida a conformità e governance

In sintesi

• La spiegabilità è la capacità di descrivere, in termini che una persona può comprendere, perché un sistema di IA ha prodotto un determinato output. Non coincide con l’interpretabilità, che riguarda il funzionamento interno del modello.
• Con il regolamento europeo sull’IA la spiegabilità passa dalla buona pratica all’obbligo giuridico: l’articolo 13 impone ai sistemi ad alto rischio una trasparenza sufficiente, e l’articolo 86 riconosce alle persone interessate un diritto alla spiegazione a partire dal 2 agosto 2026.
• Il quadro di gestione del rischio del NIST colloca l’IA spiegabile e interpretabile tra le sue sette caratteristiche di un’IA affidabile, e la norma ISO/IEC 42001 si attende che la spiegabilità sia gestita e documentata.
• Un programma di governance deve produrre più tipi di spiegazione, che coprano motivazione, responsabilità, dati, equità, sicurezza e impatto, e non un unico dato tecnico.
• La spiegabilità è verificabile. Il lavoro vero consiste nel documentare quali spiegazioni fornite, a chi, e come le garantite lungo l’intero ciclo di vita dell’IA.

Che cosa significa spiegabilità nell’IA (e che cosa non è)

La spiegabilità indica la facoltà di descrivere il comportamento di un sistema di IA in un linguaggio accessibile a una persona. La distinzione più utile per orientarsi ritorna di continuo nelle pagine che dominano i risultati di ricerca. Come afferma Splunk, la spiegabilità risponde alla domanda sul perché un modello ha prodotto un risultato, mentre l’interpretabilità risponde a come il modello funziona al suo interno. I due concetti sono collegati, vengono spesso confusi, ma non sono intercambiabili. Una seconda distinzione affina il quadro. L’Alan Turing Institute separa la trasparenza, l’essere aperti su come e perché un sistema viene usato, dalla spiegabilità, il poter fornire ragioni chiare e accessibili per uno specifico output. La trasparenza è un atteggiamento. La spiegabilità è un prodotto: un resoconto che un pubblico definito può effettivamente utilizzare. Conviene inoltre separare le spiegazioni globali da quelle locali. Una spiegazione globale descrive il comportamento di un modello in generale, sull’intero spazio degli input. Una spiegazione locale rende conto di una singola decisione, il prestito negato o la transazione segnalata. Le domande di conformità sono quasi sempre locali, perché la persona interessata vuole capire il proprio caso, non il modello in astratto. Una piattaforma di governance dell’IA deve sostenere entrambe le prospettive, senza mai confonderle.

Spiegabilità e interpretabilità

Se da questa guida volete trarre una sola distinzione, sia questa, perché la domanda di ricerca al riguardo non si attenua e la posta regolatoria vi dipende. L’interpretabilità è una proprietà del modello. Una regressione lineare o un albero decisionale breve sono interpretabili perché una persona può seguire il percorso dall’input all’output leggendo il modello stesso. La spiegabilità è più ampia. È la capacità di produrre un resoconto comprensibile di un risultato anche quando il modello è una rete profonda i cui pesi interni nessuno può leggere direttamente. Il quadro di gestione del rischio del NIST propone una formulazione che i team di governance possono riprendere: la spiegabilità riguarda i meccanismi che stanno alla base del funzionamento di un sistema di IA, mentre l’interpretabilità riguarda il significato del suo output nel contesto della finalità per cui è stato progettato. Nella pratica l’interpretabilità è spesso trattata come un sottoinsieme della spiegabilità. Si può disporre di un resoconto spiegabile di un modello non interpretabile, ed è esattamente la situazione della maggior parte delle imprese.

Perché la spiegabilità diventa un requisito di conformità

Per anni la spiegabilità è vissuta negli articoli di ricerca e nei manifesti sull’IA responsabile. Ora vive nella legge e in norme certificabili, e questo cambia chi deve occuparsene e perché. Il quadro del NIST nomina l’IA spiegabile e interpretabile come una delle sette caratteristiche di un’IA affidabile, accanto a valida e affidabile, sicura, protetta e resiliente, responsabile e trasparente, rispettosa della riservatezza, ed equa con i pregiudizi dannosi sotto controllo. Il NIST è volontario, ma è diventato il linguaggio comune del rischio legato all’IA, e la maggior parte dei programmi aziendali vi ancora i propri controlli. La ISO/IEC 42001, prima norma certificabile per i sistemi di gestione dell’IA, trasforma questo linguaggio in qualcosa di verificabile. L’organizzazione che punta alla certificazione deve dimostrare che la spiegabilità è governata: che viene considerata al momento di scegliere i modelli, che le spiegazioni vengono prodotte dove le parti interessate ne hanno bisogno, e che esiste la prova a sostegno. Il NIST dice che cosa affrontare; la ISO 42001 fornisce un sistema di gestione per dimostrare che lo avete affrontato. I due si completano, e molti programmi fanno girare il quadro all’interno della norma. Lo spostamento decisivo è giuridico. Il regolamento sull’IA rende un grado sufficiente di spiegazione un obbligo vincolante per i sistemi ad alto rischio e offre alle persone una via per richiederla. È un mondo diverso da una lista di buone pratiche, ed è la ragione per cui la spiegabilità appartiene ora a una tabella di marcia di conformità e non soltanto all’arretrato dei data scientist.

Che cosa richiede il regolamento sull’IA, per ruolo e per livello di rischio

Il regolamento non impone un obbligo uniforme. Assegna doveri distinti a fornitori e deployer e li modula secondo il livello di rischio. Stabilire bene questa corrispondenza è la differenza tra un programma difendibile e un esercizio di carte bollate.

Fornitori di sistemi ad alto rischio (articolo 13)

L’obbligo centrale grava su chi immette sul mercato un sistema ad alto rischio. L’articolo 13, paragrafo 1 stabilisce che «i sistemi di IA ad alto rischio sono progettati e sviluppati in modo tale da garantire che il loro funzionamento sia sufficientemente trasparente da consentire ai deployer di interpretare l’output di un sistema e di usarlo adeguatamente». Il verbo interpretare è voluto: il deployer deve poter attribuire un senso a ciò che il sistema indica. Questo dovere passa soprattutto per le istruzioni per l’uso. L’articolo 13 esige che siano concise, complete, corrette e chiare, e il paragrafo 3 elenca ciò che devono contenere, tra cui le caratteristiche del sistema, il suo livello di accuratezza, i suoi limiti noti e le sue capacità tecniche di spiegare l’output. La spiegazione non è dunque un supplemento; fa parte della documentazione che il fornitore consegna. Sostiene anche l’articolo 14 sulla sorveglianza umana, perché una persona non può sorvegliare davvero un sistema di cui non sa interpretare l’output.

Deployer e diritto alla spiegazione (articolo 86)

Il regolamento raggiunge anche l’organizzazione che usa il sistema. L’articolo 86 prevede che ogni persona interessata soggetta a una decisione adottata dal deployer sulla base dell’output di un sistema ad alto rischio elencato nell’allegato III, quando tale decisione produce effetti giuridici o la incide in modo analogamente significativo e negativo per la sua salute, la sua sicurezza o i suoi diritti fondamentali, «ha il diritto di ottenere dal deployer spiegazioni chiare e significative sul ruolo del sistema di IA nella procedura decisionale e sui principali elementi della decisione adottata». È un diritto delle persone e un dovere dei deployer, e diventa applicabile il 2 agosto 2026. Una banca, un assicuratore o un datore di lavoro che gestisce un sistema ad alto rischio deve essere pronto a spiegare una specifica decisione sfavorevole alla persona che la subisce, in termini chiari, su richiesta. È una spiegazione locale, su richiesta, con una scadenza.

La trasparenza dell’articolo 50 non è spiegabilità

Vale la pena nominare una trappola. L’articolo 50 impone doveri di trasparenza ad alcuni sistemi a rischio limitato, per esempio avvisare una persona che sta interagendo con un chatbot o etichettare i contenuti sintetici. Sono obblighi di informazione, e non equivalgono a spiegare una decisione. Un sistema può soddisfare l’informativa dell’articolo 50 e non dovere nulla ai sensi degli articoli 13 o 86, e viceversa. Trattate le due cose come linee distinte del vostro programma di conformità, perché un banner informativo non sia mai scambiato per una spiegazione.

I sei tipi di spiegazione che un programma di governance dovrebbe produrre

La maggior parte dei contenuti concorrenti si ferma a un’unica spiegazione tecnica, un grafico dell’importanza delle variabili, e considera il compito assolto. Un programma di governance richiede di più, perché pubblici diversi hanno bisogno di resoconti diversi della stessa decisione. L’Alan Turing Institute delinea sei tipi di spiegazione che, insieme, danno un quadro completo e che corrispondono bene a ciò che le autorità e le persone interessate chiedono davvero.

• Motivazione: le ragioni di un esito, espresse in termini accessibili anziché attraverso gli ingranaggi del modello.
• Responsabilità: chi risponde del sistema e come una persona può contestare una decisione o chiederne il riesame.
• Dati: quali dati sono stati usati, da dove provengono e come hanno inciso sul risultato.
• Equità: le misure adottate per garantire una decisione non discriminatoria, ciò che lega direttamente la spiegabilità al controllo dei pregiudizi.
• Sicurezza: l’accuratezza, l’affidabilità, la sicurezza e la robustezza dietro l’output.
• Impatto: gli effetti della decisione sulla persona e sulla società.

La stessa fonte ordina la disciplina attorno a quattro massime: essere trasparenti, essere responsabili, considerare il contesto e riflettere sugli impatti. Sono impegni operativi più che slogan. Chiedono a un team di adattare ogni spiegazione al proprio pubblico, di assegnare una responsabilità chiara e di soppesare le conseguenze del fornire, o del negare, una spiegazione. Un’autorità che esamina una decisione sfavorevole raramente si accontenta della sola motivazione; vorrà anche i resoconti di responsabilità, dati ed equità.

Tecniche di spiegabilità e compromessi di governance

Le spiegazioni vengono da qualche parte, e il metodo scelto porta conseguenze di governance. Esistono due grandi famiglie. La spiegabilità intrinseca nasce dall’uso di un modello interpretabile per costruzione, come un modello lineare, un modello additivo generalizzato o un albero decisionale poco profondo. La spiegazione è il modello stesso. Il compromesso sta nel fatto che questi modelli possono rendere meno bene su problemi complessi. La spiegabilità a posteriori si innesta su un modello opaco. Tecniche come SHAP e LIME approssimano quali variabili hanno guidato una specifica previsione. Le spiegazioni controfattuali descrivono il più piccolo cambiamento che avrebbe modificato l’esito, spesso il resoconto più intuitivo per una persona interessata, perché risponde alla domanda su che cosa sarebbe dovuto essere diverso. I modelli surrogati e i metodi di importanza delle variabili offrono una visione globale del comportamento. Il compromesso principale oppone la prestazione predittiva alla facilità di spiegazione. L’istinto di scegliere il modello più accurato e di applicarvi poi uno strumento di spiegazione è comprensibile, ma le spiegazioni a posteriori sono approssimazioni e possono ingannare se prese per verità. La scelta di governance non è quale tecnica sia la migliore in astratto, bensì quale offra al pubblico che avete davanti, un’autorità, un revisore o una persona interessata, un resoconto affidabile per quella decisione. Annotate il metodo, i suoi limiti e la ragione della scelta.

Rendere la spiegabilità un controllo verificabile

Lo scarto tra un principio di IA responsabile e un audit superato è la documentazione. La spiegabilità diventa un controllo quando potete mostrare, per un dato sistema, quali spiegazioni fornite, a chi, con quale metodo e chi ha approvato. L’Alan Turing Institute affianca al suo principio di spiegabilità un modello di gestione dell’assicurazione della spiegabilità, uno strumento iterativo per pianificare, attuare e documentare le attività di spiegazione lungo il ciclo di vita, affinché il chiarimento degli output alle parti interessate sia registrato anziché improvvisato. La struttura conta più del modello specifico. Un controllo praticabile ha quattro parti: un registro dei tipi di spiegazione che ciascun sistema deve fornire e a quali pubblici; la tecnica usata per produrne ciascuno; la prova che la spiegazione fosse davvero disponibile al momento del bisogno; e un responsabile nominato che la riesamina man mano che il modello cambia. È qui che la spiegabilità smette di essere una questione di data science e diventa un programma. Collegare ogni sistema ad alto rischio ai suoi obblighi ai sensi degli articoli 13 e 86, allegare gli artefatti di spiegazione e tenere aggiornata la prova a ogni riaddestramento è esattamente il lavoro che una piattaforma di governance dell’IA è fatta per sostenere. Svolto una volta, a mano, è un progetto. Svolto in continuo, su un intero portafoglio, richiede un sistema di riferimento.

Domande frequenti

Qual è la differenza tra spiegabilità e interpretabilità? L’interpretabilità è una proprietà del modello: un modello semplice, la cui logica una persona può leggere direttamente, è interpretabile. La spiegabilità è la capacità più ampia di dare un resoconto comprensibile di un risultato, anche per un modello complesso che nessuno può leggere direttamente. Una formula diffusa dice che l’interpretabilità risponde a come funziona il modello, mentre la spiegabilità risponde al perché un certo output è emerso. Nella governance potete dovere una spiegazione per un modello che di per sé non è interpretabile, ed è la condizione della maggior parte delle imprese. Il diritto alla spiegazione del regolamento sull’IA è già in vigore? Non ancora. L’articolo 86, il diritto delle persone interessate di ottenere dal deployer spiegazioni chiare e significative su una decisione ad alto rischio, diventa applicabile il 2 agosto 2026. Gli obblighi di trasparenza dell’articolo 13 per i fornitori di sistemi ad alto rischio seguono il calendario previsto per tali requisiti. Le organizzazioni che gestiscono sistemi ad alto rischio dovrebbero predisporre fin d’ora la capacità di spiegazione, anziché attendere la scadenza. La spiegabilità si applica a ogni sistema di IA? No. Gli obblighi vincolanti del regolamento riguardano i sistemi ad alto rischio. I sistemi a rischio limitato portano doveri di informazione ai sensi dell’articolo 50, come dichiarare che un contenuto è generato dall’IA, cosa diversa dallo spiegare una decisione. I sistemi a rischio minimo non portano alcun dovere specifico di spiegabilità ai sensi del regolamento. Detto questo, il NIST e la ISO 42001 trattano la spiegabilità come una caratteristica generale di un’IA affidabile, sicché la maggior parte dei programmi maturi ne applica una versione proporzionata all’intero portafoglio. Che cosa conta come buona spiegazione per un’autorità? Un singolo grafico dell’importanza delle variabili raramente basta. Un’autorità che esamina una decisione sfavorevole vuole di norma più resoconti insieme: la motivazione dell’esito, chi è responsabile e come contestarlo, quali dati sono stati usati, le misure di equità adottate e la base di sicurezza dell’output. Adattare la spiegazione al pubblico e documentarla conta quanto il metodo tecnico sottostante. Bastano SHAP o LIME per parlare di spiegabilità? Queste tecniche sono utili, ma sono approssimazioni a posteriori di un modello opaco, non l’intera spiegabilità. Possono ingannare se prese come verità esatta, e rispondono a una domanda tecnica, non alle domande di governance su responsabilità, dati e impatto. Usatele come uno degli elementi, annotatene i limiti e abbinatele alla documentazione e alla responsabilità che rendono la spiegabilità verificabile. Che rapporto c’è tra spiegabilità e sorveglianza umana? Stretto. L’articolo 14 del regolamento richiede una sorveglianza umana effettiva sui sistemi ad alto rischio, e una persona non può sorvegliare davvero un sistema di cui non sa interpretare l’output. La spiegabilità è la condizione preliminare della sorveglianza: senza un resoconto comprensibile del perché il sistema ha prodotto un risultato, l’essere umano nel ciclo approva output alla cieca.

Conclusione

La spiegabilità ha compiuto il passo dal principio all’obbligo. Non basta più dire che un modello è accurato; ai sensi del regolamento sull’IA, del NIST e della ISO 42001 un’organizzazione deve poter dire perché un sistema è giunto a una decisione, in termini che il pubblico giusto può utilizzare, e dimostrarlo. I team che affrontano la cosa come un problema di documentazione e di governance, e non come un trucco tecnico una tantum, saranno pronti per l’articolo 86 nel 2026 e per gli audit che seguiranno. Il primo passo concreto è modesto: elencate i vostri sistemi ad alto rischio, decidete quali spiegazioni ciascuno deve fornire e a chi, e cominciate a conservare la prova. Scoprite come la piattaforma AI Sigil trasforma tutto questo in un controllo ripetibile.