La letteratura sull'interpretabilità dei sistemi di apprendimento automatico ha un punto di partenza ormai classico: non esiste una definizione unica di interpretabilità, e la sua necessità nasce quando il problema che il sistema risolve è specificato in modo incompleto rispetto a ciò che conta davvero (Doshi-Velez e Kim, 2017). Nei contesti applicativi che trattiamo, una scrittura contabile, un documento di trasporto, una verifica su dati pubblici, questa incompletezza è la norma: il sistema risponde, ma la responsabilità del risultato resta a una persona. Ne segue che spiegabilità e controllo non sono documentazione accessoria del prodotto: sono proprietà del prodotto, e vanno progettate come le altre, con requisiti, con misure e con il costo che comportano.
Evidenza e inferenza vanno tenute distinte
La prima forma di spiegabilità è concreta e non ha niente di teorico: fonti visibili, passaggi ricostruibili e una distinzione netta fra ciò che il sistema ha osservato e ciò che ha inferito. Un numero letto da un documento e un numero stimato da un modello devono apparire diversi all'utente, perché hanno statuto epistemico diverso: il primo si verifica risalendo alla fonte, il secondo si valuta rispetto a un margine di errore. Confonderli nell'interfaccia significa trasferire all'utente un'ambiguità che il sistema conosceva e ha taciuto.
La ricerca sulle spiegazioni ha inoltre mostrato che una spiegazione efficace è selettiva e contrastiva, risponde cioè alla domanda «perché questo e non altro» con pochi elementi pertinenti, non con l'elenco esaustivo dei fattori (Miller, 2019). Per il progettista la conseguenza è precisa: la spiegazione utile è quella che permette all'utente di raggiungere il dato di partenza in pochi passaggi, non quella che descrive il funzionamento interno del modello.
L'incertezza si progetta, e si calibra
Un sistema maturo non nasconde ciò che non sa. Soglie di confidenza, indicatori di incertezza e percorsi di revisione umana appartengono all'interfaccia, non al manuale. C'è però un requisito preliminare che la pratica trascura spesso: perché una confidenza dichiarata abbia senso, deve essere calibrata, cioè corrispondere empiricamente alla frequenza con cui il sistema ha ragione. È documentato che le reti neurali moderne tendono a essere mal calibrate, sistematicamente più sicure di quanto i loro risultati giustifichino (Guo et al., 2017); esporre all'utente una confidenza non calibrata è peggio che non esporne alcuna, perché veste di misura un'impressione.
Progettare l'incertezza significa anche decidere in anticipo che cosa accade sotto una data soglia: il sistema si ferma, chiede, segnala, instrada a una persona. Sono decisioni di prodotto, e vanno prese prima che il modello esista, perché determinano i requisiti che il modello deve soddisfare e non viceversa.
Il controllo è un'architettura
Versionamento dei modelli, registrazione di ingressi e uscite, monitoraggio delle derive nel tempo, valutazioni ripetibili su insiemi di prova stabili: sono le condizioni per riprodurre un risultato passato e per capire perché un risultato di oggi differisce da quello di sei mesi fa. Senza questa strumentazione un sistema di apprendimento automatico non è governabile: funziona finché funziona e, quando smette, nessuno sa dire da quando né perché. La strumentazione di controllo, va detto, costa: allunga lo sviluppo e non si vede nelle dimostrazioni. È il tipico investimento la cui utilità appare soltanto al primo incidente evitato o ricostruito.
La supervisione umana è un requisito, anche normativo
Il principio «il sistema propone, una persona decide, la decisione resta ispezionabile» non è soltanto una scelta prudenziale: per i sistemi classificati ad alto rischio è un obbligo giuridico. Il regolamento europeo sull'intelligenza artificiale (Regolamento (UE) 2024/1689) dedica alla sorveglianza umana l'articolo 14, richiedendo che i sistemi siano progettati in modo da poter essere efficacemente supervisionati, compresa la capacità di interpretarne l'uscita, di non farvi eccessivo affidamento e di interromperne il funzionamento. La formulazione normativa conferma un punto architetturale: la supervisione effettiva presuppone la verificabilità. Non si può sorvegliare ciò che non si può ispezionare.
Che cosa comporta per chi progetta
Più lavoro di strumentazione e meno effetto scenico. Un sistema verificabile mostra i propri limiti e, in una dimostrazione commerciale, un limite dichiarato impressiona meno di una risposta sicura. È però l'unico modo di portare l'apprendimento automatico dentro processi in cui qualcuno risponde del risultato, ed è il criterio con cui i prodotti Analytiko™ vengono progettati e valutati: ogni uscita distingue l'osservato dall'inferito, dichiara il proprio margine e conserva la catena che la lega all'evidenza.
Riferimenti: Doshi-Velez F., Kim B., «Towards a Rigorous Science of Interpretable Machine Learning», arXiv:1702.08608, 2017 · Miller T., «Explanation in Artificial Intelligence: Insights from the Social Sciences», Artificial Intelligence, 267, 2019 · Guo C. et al., «On Calibration of Modern Neural Networks», ICML 2017 · Regolamento (UE) 2024/1689, articolo 14.
Analytiko · 2 settembre 2026