L’intelligenza artificiale generativa sta entrando sempre più profondamente nei processi aziendali. L’AI aziendale non viene più utilizzata soltanto per scrivere testi o sintetizzare documenti: i modelli vengono collegati a knowledge base, archivi interni, email, database, applicazioni e workflow operativi.
In questo scenario la domanda non è più soltanto se un modello riesca a produrre una risposta corretta: diventa altrettanto importante capire quanto il suo comportamento sia stabile, spiegabile e verificabile.
Il 21 agosto 2026 Anthropic ha pubblicato una nuova ricerca intitolata “Would This Change Your Answer? Evaluating Explanations of LLM Behavior in the Wild with Counterfactual Experiments“. Il lavoro introduce CHIVE, acronimo di “Counterfactual Hypothesis Investigation Via Edits“, una pipeline agentica progettata per individuare comportamenti inattesi dei modelli linguistici e testarli modificando in modo controllato parti dei prompt.
La ricerca ufficiale è disponibile qui: Anthropic Alignment Science — CHIVE.
L’obiettivo è molto concreto: verificare se una spiegazione apparentemente convincente del comportamento di un modello aiuti davvero a prevedere cosa succederà quando cambiano alcuni elementi del contesto. È una distinzione importante, perché nel mondo dei large language model è relativamente facile formulare una spiegazione plausibile a posteriori. Molto più difficile è dimostrare che quella spiegazione descriva davvero una relazione causale utile.
CHIVE prova le spiegazioni cambiando il prompt
Il principio alla base di CHIVE è quello degli esperimenti controfattuali.
Se pensiamo che un modello abbia commesso un determinato errore a causa di una parola, della struttura del prompt o di un’informazione presente nel contesto, possiamo modificare quell’elemento e verificare se il comportamento cambia realmente.
In termini semplici, una buona spiegazione dovrebbe produrre previsioni verificabili.
Anthropic utilizza CHIVE per analizzare comportamenti reali e inattesi degli LLM. La pipeline individua un comportamento, formula ipotesi sulle possibili cause e sperimenta modifiche ai prompt per verificare quali elementi incidano effettivamente sul risultato. Ogni indagine produce quindi una spiegazione e, soprattutto, una serie di esperimenti misurati che permettono di valutarla.
Uno dei risultati più interessanti riguarda tre strumenti di interpretabilità basati sulle attivazioni interne del modello: activation oracle, natural-language autoencoder e sparse autoencoder.
Secondo Anthropic, fornire questi strumenti agli agenti incaricati di prevedere l’esito delle modifiche controfattuali non ha migliorato le prestazioni rispetto a un agente che aveva soltanto accesso alla trascrizione della conversazione. La ricerca mostra invece risultati più promettenti addestrando modelli a prevedere come determinate modifiche ai prompt cambieranno il comportamento.
Questo non significa che la ricerca sull’interpretabilità sia inutile. Significa piuttosto che comprendere il comportamento reale di un LLM rimane un problema molto più complesso di quanto possa suggerire una spiegazione generata dal modello o l’accesso a determinate rappresentazioni interne.
Per le aziende la spiegazione non può sostituire la verifica
Il tema diventa particolarmente importante quando un LLM viene utilizzato in un ambiente aziendale.
Supponiamo che un assistente AI risponda a una domanda utilizzando documentazione interna. Se il risultato è errato, un’organizzazione può essere tentata di attribuire l’errore direttamente al modello: “non ha capito la domanda”, “ha interpretato male il documento” oppure “ha dato troppo peso a questa informazione”.
Ma il comportamento finale dipende da molti elementi diversi:
- la domanda dell’utente può essere stata formulata in modo ambiguo;
- il sistema RAG può aver recuperato documenti poco pertinenti;
- la knowledge base può contenere versioni obsolete della stessa procedura;
- il prompt di sistema può aver fornito istruzioni troppo generiche;
- la cronologia della conversazione può aver introdotto informazioni non più rilevanti;
- un documento può avere un titolo corretto ma contenuto non aggiornato.
In un sistema aziendale serio, attribuire genericamente l’errore al modello non è quindi sufficiente.
Serve sapere quale contesto è stato selezionato, quali documenti sono stati recuperati, quali istruzioni sono state applicate e come varia la risposta modificando ciascuno di questi elementi.
La ricerca CHIVE rafforza proprio questo principio: le spiegazioni diventano realmente utili quando possono essere sottoposte a test.
La governance della knowledge base diventa decisiva
Questo porta direttamente al tema della governance della knowledge base aziendale.
Un sistema RAG permette di fornire a un modello informazioni proprietarie recuperate da documenti, email, siti web, database o altre fonti. Il vantaggio è evidente: il modello può rispondere sulla base della conoscenza specifica dell’organizzazione senza dover essere riaddestrato su tutti i dati.
Ma il valore del RAG dipende dalla qualità del contesto che viene recuperato (ed è qui che Gol-IA è migliore rispetto ai sistemi RAG tradizionali!).
Se la knowledge base non è controllata, il modello può ricevere informazioni obsolete, contraddittorie o non autorizzate. Se non è possibile sapere quali fonti hanno contribuito a una risposta, diventa difficile ricostruire un errore. Se tutte le informazioni vengono inviate indiscriminatamente a un modello esterno, aumenta inoltre l’esposizione del patrimonio informativo aziendale.
Per questo una piattaforma AI enterprise dovrebbe permettere di controllare almeno quattro livelli: quali fonti entrano nella knowledge base, quali utenti possono accedere a determinate informazioni, quali contenuti vengono recuperati per una specifica domanda e quale modello viene utilizzato per elaborare quel contesto.
L’osservabilità diventa quindi parte integrante dell’affidabilità.
Non basta avere una risposta. È utile poter ricostruire il percorso che ha portato a quella risposta e confrontarlo con comportamenti alternativi quando si modifica il contesto.
Testare l’AI sui processi reali dell’organizzazione
Un altro messaggio importante della ricerca Anthropic riguarda il modo in cui le aziende dovrebbero valutare i propri sistemi AI.
I benchmark generali aiutano a confrontare i modelli, ma non possono prevedere con precisione come un sistema si comporterà sui documenti, sulle procedure e sulle domande reali di una specifica organizzazione.
Un modello eccellente nei benchmark può comunque fallire in un workflow aziendale se il retrieval recupera informazioni sbagliate. Al contrario, un modello più piccolo può risultare perfettamente adeguato quando riceve un contesto selezionato correttamente.
Le aziende dovrebbero quindi costruire set di domande e casi di test basati sui propri processi. Ogni modifica al modello, al prompt, alla knowledge base o al sistema di retrieval dovrebbe poter essere confrontata con questi casi per capire se la qualità migliora o peggiora.
È una logica simile a quella dei test software: non ci si limita a chiedere se il programma “sembra funzionare”, ma si verifica sistematicamente il comportamento su scenari conosciuti.
Questo approccio diventa particolarmente importante con l’arrivo degli AI Agent. Un agente può prendere una risposta del modello e trasformarla in un’azione: inviare un messaggio, aggiornare un database, classificare una pratica o avviare un workflow. In questo scenario un comportamento inatteso non rimane necessariamente confinato a un testo sbagliato.
La verifica deve quindi riguardare l’intera catena:
domanda → retrieval → contesto → modello → risposta → eventuale azione.
Più la catena diventa articolata, più osservabilità e test assumono valore.
Gol-IA: separare modello, dati e governance per l’AI aziendale
Questo è uno degli obiettivi alla base di Gol-IA.
Gol-IA non nasce come semplice interfaccia per interrogare un large language model. L’obiettivo è creare un hub AI nel quale l’organizzazione possa gestire in modo centralizzato modelli, utenti, documentazione, knowledge base, fonti, retrieval, chat e workflow.
Per studi professionali e aziende con un numero limitato di utenti, l’intera infrastruttura può essere mantenuta on-premise utilizzando modelli open source eseguiti localmente. Documentazione aziendale, knowledge base e conversazioni possono quindi restare fisicamente all’interno dell’organizzazione.
Per realtà con carichi maggiori è possibile adottare un’architettura ibrida. La documentazione e il sistema RAG possono rimanere locali, mentre un modello esterno viene utilizzato soltanto per i task che richiedono maggiore capacità. In questo caso il provider esterno riceve il contesto selezionato necessario a produrre la risposta, non necessariamente l’intero patrimonio documentale.
Questa architettura non garantisce automaticamente la conformità all’AI Act o ad altre normative: gli obblighi dipendono dal caso d’uso, dal ruolo dell’organizzazione e dalle caratteristiche del sistema. Tuttavia, separare dati, retrieval e modello può aumentare il controllo sull’esposizione delle informazioni e rendere più semplice applicare principi di minimizzazione, tracciabilità e governance.
La ricerca CHIVE di Anthropic mostra quanto sia complesso spiegare in modo affidabile il comportamento di un modello linguistico. Per le aziende la conseguenza pratica è chiara: non bisogna affidarsi soltanto alla reputazione del modello o alla plausibilità delle sue spiegazioni.
Serve progettare sistemi nei quali il comportamento possa essere osservato, testato e confrontato sui casi reali dell’organizzazione.
È qui che una piattaforma come Gol-IA e una corretta Consulenza AI possono fare la differenza: non scegliendo semplicemente “il modello migliore”, ma costruendo l’architettura, la knowledge base, i controlli e i test necessari perché l’intelligenza artificiale diventi uno strumento operativo realmente governabile.
Lascia un commento