Siamo pazienti in attesa di responso e il nostro medico ci dice: l’intelligenza artificiale suggerisce che non è il caso di operare. Ma perché, come fa a dirlo? Il medico non è in grado di rispondere. Altro scenario. Un’intelligenza artificiale dice a un militare che in quell’edificio c’è un terrorista, ma nessun civile. Ma come è arrivato a quella conclusione? Chissà. Ma indugiare troppo nella decisione comporta rischi. Medici, militari. Altri rischi però ci sono se scegliamo di fidarci a occhi chiusi.
Man mano che l’AI Gen LLM entra in sistemi critici, ad esempio in sanità soprattutto negli USA e nelle guerre ora in corso in Iran e Ucraina, diventa indifferibile risolvere il vecchio e noto problema della black box del deep learning.
Perché finché non sappiamo come l’AI è arrivata a certe conclusioni, siamo costretti a scegliere tra padella e la brace. Fidarci o no, in entrambi i casi senza cognizione di causa.
Indice degli argomenti
Sicurezza, responsabilità, governance: il problema non è solo tecnico
I punti in questione: capire su che cosa l’AI si sta basando, quanto è affidabile in quel contesto, dove può sbagliare e se un operatore umano è davvero in grado di controllarlo prima che l’errore si propaghi. In sanità, un output sbagliato può orientare male una decisione clinica. Può amplificare bias e discriminazioni ai danni di certe categorie.
Nella difesa, una ricostruzione sbagliata del contesto, una priorità tattica mal giustificata o una raccomandazione automatica poco comprensibile possono comprimere i tempi del giudizio umano proprio quando servirebbe più cautela.
Insomma, è un problema di sicurezza, responsabilità, governance e controllo. Etico e pratico al tempo stesso.
Interpretability ed explainability dell’AI: perché regolatori e istituzioni le mettono al centro
Le parole chiave sono due. Interpretability ed explainability dell’AI.
Non è un caso che questo tema sia salito così rapidamente nell’agenda di regolatori, istituzioni sanitarie, agenzie di standardizzazione e apparati di difesa. L’ente USA NIST include spiegabilità e interpretabilità tra le caratteristiche della trustworthy AI. La WHO insiste sulla necessità di trasparenza, intelligibilità e supervisione nei sistemi AI usati in salute. La FDA americana chiede che il ruolo dell’AI nei dispositivi medici sia descritto in modo comprensibile e verificabile. Il Dipartimento della Difesa americano collega l’uso responsabile dell’AI a principi come traceable, reliable e governable. Sullo sfondo, il punto comune è semplice: in un contesto ad alto rischio non basta ottenere un risultato utile, bisogna poterlo valutare, contestare, ricostruire e, se serve, interrompere.
Che cosa sono interpretability ed explainability
Ma che vogliono dire di preciso explainability e interpretability? La prima indica la capacità di fornire spiegazioni comprensibili dell’output. La seconda indica la possibilità di leggere, almeno in parte, i meccanismi interni che producono quell’output. La distinzione non è sempre tracciata allo stesso modo nei documenti istituzionali e nella letteratura tecnica, ma è diventata centrale con l’ascesa dei large language models e dei sistemi multimodali.
L’explainability riguarda soprattutto quello che il sistema riesce a mostrare all’esterno: perché ha prodotto una certa risposta, quali elementi dichiara di aver considerato, quali fonti richiama, con quali limiti e con quale livello di incertezza. L’interpretability, invece, prova ad andare oltre la superficie e a capire che cosa succede dentro il modello: quali rappresentazioni interne si attivano, quali circuiti o feature entrano in gioco, in che modo un certo input viene trasformato in un certo output.
La differenza conta molto, perché nei modelli generativi la prestazione è cresciuta molto più in fretta della trasparenza. I sistemi producono testi, immagini, sintesi, scenari e raccomandazioni sempre più convincenti, ma questo non significa che sappiamo davvero come arrivano a quei risultati. Per anni il problema principale dell’intelligenza artificiale è stato farla funzionare. Oggi, almeno nei contesti ad alto rischio, il problema è anche capire come e perché funziona, dove fallisce e quanto controllo reale resta in mano agli esseri umani.
Perché contano davvero nei large language models
Con i modelli discriminativi tradizionali la domanda tipica era: “perché questo algoritmo ha classificato un’immagine come tumore?” Con la gen AI la domanda si allarga: “perché il sistema ha prodotto proprio questa diagnosi differenziale, questa sintesi clinica, questo consiglio operativo, questa ricostruzione del quadro tattico, questo piano d’azione?” La generazione di testo o raccomandazioni introduce infatti una catena di rischio più lunga: allucinazioni, errori nel recupero del contesto, inferenze non giustificate, uso improprio di dati sensibili, citazioni imperfette delle fonti, razionalizzazioni a posteriori.
Per questo motivo interpretability ed explainability non sono semplici etichette tecniche. In sanità servono a capire se una risposta si basa davvero su referti, esami, immagini e linee guida pertinenti, oppure se sta solo producendo una sintesi plausibile. In difesa servono a distinguere un’evidenza robusta da un artefatto del dato, a valutare quanto il sistema stia extrapolando oltre quello che sa, a mantenere un controllo umano significativo anche sotto pressione. In entrambi i casi l’obiettivo è che il modello sia abbastanza comprensibile da poter essere usato in modo responsabile.
Fiducia nell’AI non significa fiducia cieca
Qui entra in gioco anche il tema della fiducia. La fiducia, però, non va intesa come adesione psicologica o entusiasmo verso la tecnologia. Nei contesti ad alto rischio la fiducia utile è una fiducia governata: sapere che il sistema è stato testato, che i suoi limiti sono dichiarati, che le fonti possono essere controllate, che il comportamento può essere monitorato, che l’operatore umano può intervenire davvero. Un sistema opaco può anche apparire persuasivo, ma la persuasività non è affidabilità. Anzi, uno dei rischi principali dei modelli generativi è proprio la loro capacità di produrre risposte fluenti e convincenti anche quando sono sbagliate, incomplete o mal fondate.
Perché la questione è decisiva in sanità
La sanità è il settore in cui la richiesta di spiegazioni robuste incontra più direttamente la pratica. Un medico può anche accettare un supporto generativo, ma deve sapere che cosa lo ha orientato: quali referti, quali immagini, quali pattern di laboratorio, quali documenti recuperati, quali limiti sono stati riconosciuti dal sistema e dove resta incertezza. La WHO ha già indicato trasparenza, explainability e intelligibilità come principi essenziali per l’AI in salute, e nella riflessione più recente sui large multimodal models ha esteso il tema ai sistemi generativi usati in cura, ricerca biomedica e sanità pubblica.
Anche la FDA insiste sul fatto che i dispositivi medici abilitati da machine learning e AI debbano rendere comprensibile il ruolo del sistema rispetto all’uso previsto, agli input, agli output, ai limiti e ai rischi. In questa prospettiva, la trasparenza non coincide con una spiegazione elegante o con una narrazione rassicurante. Coincide con un insieme di informazioni e controlli che permettono di valutare sicurezza ed efficacia lungo l’intero ciclo di vita del dispositivo, compresa la sorveglianza post-market.
Gli esempi clinici si stanno moltiplicando: triage, documentazione, sintesi di cartelle, istruzioni perioperatorie, supporto diagnostico, modelli multimodali che integrano testo e immagini, sistemi RAG che recuperano documenti per produrre risposte contestualizzate. Tutto questo mostra che l’ingresso dei LLM nella pratica sanitaria è già iniziato. Ma mostra anche un’altra cosa: la qualità apparente dell’output non basta. Serve sapere da quali fonti deriva la risposta, come sono stati pesati i dati, quali errori sono stati testati, quale ruolo resta al clinico e dove il sistema non dovrebbe essere lasciato operare senza controllo.
Perché la questione è decisiva in difesa
In ambito militare l’errore può produrre effetti irreversibili in tempi molto brevi. Gli usi dell’AI già discussi nei documenti NATO, DoD e nei dibattiti internazionali vanno dall’analisi di intelligence al decision support operativo, dalla cyberdifesa alla logistica, fino ai sistemi autonomi. In questo contesto la spiegabilità non è un accessorio. È una condizione per permettere all’operatore di capire il quadro tattico, anticipare il comportamento del sistema e, se necessario, correggerlo o disattivarlo.
Le cinque AI Ethical Principles del DoD includono traceable, reliable e governable. Non è un dettaglio lessicale. Significa che un sistema dovrebbe poter essere tracciato nelle sue funzioni, valutato nella sua affidabilità e governato da esseri umani in modo effettivo. Sul piano internazionale, la Political Declaration on Responsible Military Use of Artificial Intelligence and Autonomy insiste sulla necessità che il personale comprenda in misura sufficiente capacità e limiti dei sistemi AI e che questi siano sottoposti a test e valutazioni appropriate. L’ICRC ha spinto ancora oltre, sostenendo la necessità di proibire sistemi autonomi imprevedibili che non consentano a un operatore umano di comprenderne, spiegarne o prevederne adeguatamente il funzionamento.
Un sistema generativo che fonde dati da droni, satelliti e sensori può proporre una priorità tattica. Un agente AI in cyberdifesa può suggerire contromisure automatiche. Un sistema di supporto alla pianificazione può sintetizzare scenari e opzioni di ingaggio. In tutti questi casi il problema non è solo se il modello “ci prende” spesso. Il problema è se chi decide può ricostruire su quali segnali si basa il suggerimento, distinguere un elemento robusto da un artefatto, capire il grado di incertezza e fermare il processo prima che un errore entri nella catena decisionale. Nei contesti ad alta velocità, una spiegazione debole equivale spesso a un controllo debole.
Dalla fiducia psicologica all’architettura di controllo
Emerge una esigenza, per accordare fiducia a un modello: stabilire una soglia di controllo adeguata al rischio. Non serve una “spiegazione perfetta” in senso assoluto. Serve capire abbastanza da poter verificare, contestare, correggere e assumersi responsabilità.
È qui che si vede la differenza tra un sistema utile e un sistema governabile. Un modello può essere molto performante ma restare troppo opaco per l’uso in contesti ad alto rischio. Oppure può essere abbastanza accurato, ma mancare di documentazione sulle fonti, sui limiti o sul comportamento in casi anomali. La fiducia, allora, non nasce da una singola tecnica di spiegazione, ma da un’architettura di controlli.
I diversi approcci per capire perché un LLM è arrivato a un certo output
Lo stato dell’arte della ricerca per risolvere il problema non offre una tecnica unica e risolutiva. Offre piuttosto una cassetta degli attrezzi, composta da approcci diversi che rispondono a domande diverse.
Primo approccio: spiegazioni in linguaggio naturale e chain of thought
Il primo approccio è il più intuitivo: chiedere al modello di spiegare la propria risposta. È la strada delle spiegazioni in linguaggio naturale e delle chain of thought. Questo metodo è utile perché rende l’output più leggibile, aiuta l’utente a seguire una traccia argomentativa e può facilitare il debugging o la revisione umana. Ma è anche il più fragile se viene usato come prova del funzionamento interno. Una spiegazione ben scritta non garantisce che il modello abbia davvero seguito quei passaggi.
Le cosiddette chain of thought possono essere utili per mostrare una traccia argomentativa, ma non sono automaticamente una finestra fedele sui processi interni del modello. Possono essere incomplete, fragili, razionalizzate a posteriori o semplicemente costruite in modo convincente senza riflettere con precisione il percorso computazionale che ha portato alla risposta.
Questo punto è importante soprattutto perché i modelli generativi sono bravissimi a spiegarsi in modo plausibile. Possono offrire una motivazione ben scritta, lineare e rassicurante anche quando il processo interno che ha prodotto l’output è stato diverso, parziale o meno ordinato di quanto sembri. Per questo la letteratura più recente insiste su una distinzione netta: una spiegazione linguistica può essere utile per usabilità, debugging o monitoraggio, ma non basta da sola come prova del funzionamento interno.
I limiti delle spiegazioni narrative
Allo stesso tempo sarebbe sbagliato concludere che le chain of thought non servono a nulla. Possono essere segnali utili per monitorare comportamenti anomali, deviazioni o forme di ragionamento sospette. Il punto è non scambiarle per una garanzia piena di fedeltà. Nei contesti ad alto rischio, affidarsi solo alla spiegazione narrativa del modello significa confondere la leggibilità dell’output con la trasparenza del processo.
Secondo approccio: tecniche post-hoc, LIME, SHAP e saliency map
Il secondo approccio è quello delle tecniche post-hoc classiche, cioè metodi che cercano di spiegare una decisione dopo che il modello l’ha già presa. Sono nate prima dell’esplosione della gen AI e restano molto usate, soprattutto in medicina e nell’analisi di immagini. L’idea di fondo è semplice: non si prova ad aprire il modello dall’interno, ma a capire quali parti dell’input hanno pesato di più nel risultato finale. È il caso delle saliency map, che evidenziano le aree di un’immagine più influenti; delle tecniche di feature attribution, che assegnano un peso alle variabili in ingresso; o di metodi come LIME e SHAP, diventati due riferimenti classici della spiegabilità post-hoc. LIME, proposto da Ribeiro, Singh e Guestrin nel 2016, approssima localmente il comportamento del modello con una spiegazione più semplice e interpretabile. SHAP, introdotto da Lundberg e Lee nel 2017, usa i valori di Shapley per stimare quanto ogni variabile abbia contribuito a una singola predizione.
Accanto a LIME e SHAP ci sono altre famiglie di strumenti. Occlusion significa coprire o rimuovere sistematicamente parti dell’input per vedere quanto cambia l’output: se oscurando una porzione di TAC la previsione cambia molto, quella zona probabilmente contava. La visualizzazione dell’attenzione prova invece a mostrare su quali token o regioni il modello si è concentrato di più, anche se “attenzione” non equivale automaticamente a “spiegazione”. Le concept-based explanations fanno un passo ulteriore: invece di dire solo “questa variabile pesa”, provano a collegare la decisione a concetti più umani e riconoscibili. In medicina, a margini irregolari, edema o presenza di certe strutture anatomiche.
Terzo approccio: retrieval-augmented generation e tracciamento delle fonti
Il terzo approccio è quello delle spiegazioni ancorate alle fonti esterne. È la logica della retrieval-augmented generation o RAG: prima di rispondere, il sistema recupera documenti esterni — linee guida, cartelle, referti, protocolli, articoli — e poi costruisce l’output a partire da quel materiale. In questo contesto diventano importanti le citazioni del documento di origine, la provenance dei dati e il tracciamento dell’evidenza. “Provenance” vuol dire poter ricostruire l’origine dell’informazione: quale documento è stato usato, in quale versione, da quale archivio, con quali passaggi di trasformazione. Il logging delle trasformazioni aggiunge un altro livello: registra che cosa è successo lungo la pipeline, per esempio quali documenti sono stati recuperati, filtrati, riordinati o sintetizzati prima della risposta finale.
Se un sistema suggerisce una diagnosi differenziale o una istruzione perioperatoria, il medico ha bisogno di vedere quali fonti cliniche, quali referti o quali documenti di supporto sono stati richiamati.
Quarto approccio: mechanistic interpretability e circuit tracing
Il quarto approccio è il più ambizioso, ed è quello che oggi viene chiamato mechanistic interpretability. Qui l’obiettivo non è chiedere al modello di spiegarsi, né solo verificare le fonti esterne, ma guardare direttamente dentro il modello per capire quali meccanismi interni producono un certo comportamento. Quando si parla di stati interni o attivazioni, ci si riferisce ai valori numerici che i diversi strati del modello producono mentre elaborano l’input. L’idea è che, se riusciamo a leggere questi stati in modo abbastanza ordinato, possiamo iniziare a capire quali “rappresentazioni” il modello sta usando: per esempio se sta attivando una nozione di negazione, di antonimia, di entità medica, di lingua o di pattern sintattico.
Dentro questo filone rientrano varie tecniche che vale la pena approfondire. Il probing consiste nell’addestrare un piccolo classificatore sopra le attivazioni del modello per vedere se, in quel punto, è presente un certo tipo di informazione. In pratica si chiede: “da questi stati interni riesco a capire se il modello ha riconosciuto un certo concetto o sta per compiere una certa azione?” Anthropic ha mostrato nel 2024 che semplici probe lineari potevano rilevare segnali utili in modelli con backdoor prima che il comportamento dannoso comparisse apertamente nell’output. Questo non equivale a una comprensione completa del modello, ma dimostra che alcune informazioni rilevanti possono essere intercettate internamente in modo operativo.
Le sparse autoencoders, o SAE, sono un altro strumento centrale. Servono a scomporre le attivazioni molto dense del modello in “feature” più leggibili, cioè in componenti più sparse e potenzialmente interpretabili. Google DeepMind ha presentato Gemma Scope proprio come una suite aperta di SAE per osservare meglio le rappresentazioni interne dei modelli Gemma. Nella versione più recente, Gemma Scope 2 combina SAE e transcoders per studiare comportamenti più complessi, come jailbreak, meccanismi di rifiuto e possibili discrepanze tra il ragionamento comunicato dal modello e il suo stato interno. È un esempio importante perché mostra il passaggio da spiegazioni statiche e locali a strumenti che cercano di seguire processi multi-step dentro un LLM.
Il circuit tracing prova a fare un passo ulteriore. Non si limita a dire che una certa feature esiste, ma cerca di collegare più feature e passaggi di calcolo in una specie di grafo locale del ragionamento del modello. Anthropic, nel marzo 2025, ha descritto questo approccio come un modo per collegare concetti interpretabili a circuiti computazionali, cioè a sequenze di operazioni interne che trasformano le parole in ingresso nelle parole in uscita. In termini semplici: non più solo “questa parte del modello sembra sensibile a X”, ma “queste parti del modello cooperano in questo ordine per produrre Y”. È una differenza importante perché porta l’interpretabilità più vicino a una ricostruzione causale del comportamento.
Causal tracing, ablation e model editing: verso la verifica causale
Il causal tracing cerca di capire quali componenti interne siano davvero necessarie per un certo output, non solo correlate ad esso. L’ablation consiste nel silenziare o rimuovere temporaneamente una parte del modello per vedere che cosa cambia. Il model editing prova invece a modificare in modo mirato una certa associazione interna. Un caso molto citato è ROME, presentato da Meng e colleghi nel 2022: il lavoro mostra che alcune associazioni fattuali nei modelli GPT possono essere localizzate e aggiornate intervenendo in punti specifici della rete. Il valore di questi studi è che spostano la discussione dalla semplice descrizione al test causale: se tocco questa parte del modello e cambia proprio quel comportamento, allora ho una prova più forte che quel componente contava davvero.
Il motivo per cui tutto questo conta è che la mechanistic interpretability prova a trasformare la trasparenza da racconto plausibile a verifica causale. Con le spiegazioni linguistiche il modello può sempre “raccontare” perché ha risposto in un certo modo. Con gli approcci meccanicistici, invece, si cerca di vedere se esistono componenti interne identificabili, isolabili e manipolabili che spiegano davvero una parte del comportamento osservato. È un programma di ricerca ancora lontano dall’offrire una soluzione completa, ma è quello che promette di più quando l’obiettivo non è solo rendere l’AI più leggibile, bensì capire dove nasce un errore, dove si annida una deviazione e dove si può intervenire in modo mirato.
Monitorabilità: rilevare le deviazioni prima che diventino errori
Infine c’è un livello trasversale che sta diventando sempre più importante: la monitorabilità. Anche quando non possiamo spiegare perfettamente il meccanismo interno, possiamo cercare segnali utili a monitorare deviazioni, comportamenti opportunistici, backdoor o errori sistematici. In questo senso, alcune tecniche di probing o di analisi delle CoT non servono tanto a “spiegare” il modello quanto a rilevare in anticipo che qualcosa sta andando storto.
Combinare i livelli di controllo: la direzione di marcia
Le tecniche sono complementari, ciascuna con limiti noti. Nei contesti a basso rischio può bastare una spiegazione orientativa o la verifica della fonte documentale. In sanità e difesa no. Lì la soglia minima è più alta, perché le decisioni incidono su vita, integrità fisica, diritti e uso della forza.
Per questo la direzione di marcia non è affidarsi a una sola forma di explainability, ma combinare più livelli di controllo: trasparenza sui dati, qualità delle fonti, test rigorosi, monitoraggio dei comportamenti, interpretazione interna quando possibile, audit, validazione, supervisione umana significativa.
Finché la gen AI resta uno strumento per scrivere una mail o riassumere una riunione, l’opacità può essere un costo tollerabile. Quando entra in una corsia ospedaliera, in una rete di cyberdifesa o in un ciclo di comando, sarebbe folle da parte nostra scegliere di fidarci, o di non fidarci, a occhi chiusi.
