Non c'è conferenza di settore dove non compaiano decine di nuovi metodi di Explainable AI: attribuzioni di feature, contrafattuali, sparse autoencoder. Eppure, quando si guarda a ciò che accade nei flussi di lavoro reali — in ambito sanitario, legale, finanziario — quelle spiegazioni finiscono quasi sempre cestinate. Non guidano decisioni, non correggono errori, non restituiscono feedback ai modelli. È un fiume di carta tecnica che scorre parallelo alla pratica, senza mai incontrarla.

La ragione, secondo un netto position paper che sta circolando tra i revisori di ICML, NeurIPS e ICLR, non sta nella qualità degli algoritmi ma nell’assenza di fondamenta condivise: formulazioni del problema vaghe, obiettivi di valutazione sotto-specificati e, soprattutto, la mancanza di pipeline end-to-end che integrino le spiegazioni in cicli di feedback con l’umano nel loop. Il team ha analizzato centinaia di lavori e intervistato practitioner XAI, trovando schemi ricorrenti che bloccano il progresso cumulativo: si accumulano metriche ad-hoc senza sapere per chi siano progettate, si valuta la fedeltà di un’attribuzione senza misurare se un operatore sappia tradurla in azione.

Per chi oggi porta in produzione LLM in architetture on-premise — spinte da requisiti di sovranità del dato, conformità GDPR o semplicemente da TCO favorevoli su carichi costanti — questo vuoto metodologico ha un costo immediato. Un modello self-hosted che decide su una richiesta di credito, su una diagnosi differenziale o su un contratto deve rendere conto del proprio ragionamento non per una checklist astratta, ma per alimentare un processo decisionale di cui l’umano conserva la regia. Senza pipeline strutturate per ricevere, interpretare e restituire al modello il significato operativo di una spiegazione, il concetto stesso di “auditabilità” diventa un ornamento: si produce il report, si archivia, si va avanti. Ma il sistema non impara dall’interazione, e l’illusione di controllo rischia di cristallizzare bias anziché risolverli.

Il vero scarto segnalato dalla ricerca è quindi tra due velocità: da un lato una comunità XAI che si auto-valuta con esperimenti scollegati dalla realtà operativa; dall’altro un’industria che, nei contesti più regolati, ha bisogno di sistemi in cui la spiegabilità sia un meccanismo vivo, innestato nel training continuo e nel monitoraggio. È un disallineamento che ricorda i primi anni del software testing, quando ci si accontentava di coverage metrics senza interrogarsi su cosa stessero realmente proteggendo. Chi si muove in anticipo per costruire pipeline di feedback explanation-driven — magari partendo da ambienti controllati on-premise, dove l’accesso ai dati e ai segnali di supervisione è pieno — può guadagnare un vantaggio competitivo non replicabile da chi resta aggrappato a black box cloud-hosted con API opache.

Il position paper chiude con una checklist concreta per invertire la rotta: formulare il problema XAI partendo dall’utente finale e dalla sua capacità d’azione, definire metriche di successo ancorate a decisioni reali, ingegnerizzare il loop di ritorno. Per i lettori di AI-RADAR, il messaggio profondo è che la partita dell’on-premise non si gioca solo su GPU e VRAM, ma sulla possibilità di costruire attorno ai modelli un’infrastruttura di significato che manca ancora nel mainstream.