Quando si introduce un sistema di intelligenza artificiale in azienda, uno degli errori più frequenti è confondere il superamento di alcuni test con l’affidabilità del sistema nel tempo. Un modello può comportarsi bene durante una demo, rispondere correttamente a una serie di domande preparate e superare benchmark molto avanzati.
Ma l’ambiente reale è diverso: cambiano gli utenti, cambiano i documenti, cambiano i prompt, cambiano i modelli e cambia la knowledge base. Per questo la governance dell’AI non può essere ridotta a una mera verifica iniziale.
Una nuova ricerca pubblicata il 21 agosto 2026 da Anthropic Alignment Science offre un esempio molto chiaro del problema.
Nel lavoro “Fine-Tuned Lie Detectors Failed to Generalize”, i ricercatori hanno addestrato rilevatori per riconoscere menzogne prodotte da modelli linguistici open source e hanno poi verificato come questi detector si comportassero su casi diversi da quelli utilizzati durante il fine-tuning.
Il risultato principale è significativo: i detector addestrati funzionano relativamente bene sui dati vicini a quelli di training, ma la loro capacità si riduce sensibilmente quando devono affrontare casi fuori distribuzione. In questi scenari, i sistemi fine-tuned superano di poco semplici baseline basate sul prompting, mentre in diversi casi modelli più grandi usati direttamente come giudici ottengono risultati migliori.
La ricerca riguarda un problema specifico, quello della rilevazione delle menzogne nei modelli, e non dimostra che tutti i sistemi di controllo AI siano inefficaci. Sarebbe una generalizzazione impropria. Il messaggio più utile per le aziende è un altro: un controllo non è affidabile soltanto perché funziona sui dati con cui è stato progettato.
Dalla demo ai casi reali: dove iniziano i problemi
In un ambiente aziendale, un sistema AI viene continuamente esposto a situazioni che non erano presenti durante la fase iniziale di test:
- un nuovo documento entra nella knowledge base;
- un utente formula una domanda con una terminologia diversa;
- una procedura aziendale viene aggiornata;
- il modello viene sostituito con una versione più recente
- il sistema RAG modifica il ranking delle fonti recuperate.
Ognuno di questi cambiamenti può influire sulla risposta.
Per questo una piattaforma AI enterprise dovrebbe essere valutata non soltanto come un singolo modello, ma come una catena di componenti:
- input dell’utente,
- retrieval,
- documenti selezionati,
- prompt di sistema,
- eventuale cronologia,
- modello generativo,
- strumenti utilizzati e risposta finale.
Se cambia uno di questi elementi, può cambiare il risultato!
Il concetto di generalizzazione discusso dalla ricerca Anthropic diventa quindi molto concreto. Un controllo progettato per intercettare un comportamento problematico deve funzionare anche quando cambia il contesto. Se invece riconosce soltanto schemi molto simili a quelli osservati durante l’addestramento, rischia di creare un falso senso di sicurezza.
Un esempio semplice è la verifica automatica di una risposta RAG. Se un sistema viene testato soltanto su cinquanta domande preparate dagli sviluppatori, potrebbe ottenere risultati eccellenti. Ma gli utenti reali possono formulare la stessa richiesta in cento modi diversi oppure chiedere informazioni che attraversano più documenti, versioni e periodi temporali.
La qualità reale emerge solo quando il sistema viene valutato su scenari rappresentativi dell’organizzazione.
La governance AI richiede eval continue
Da qui nasce un principio importante per l’AI aziendale: le valutazioni devono diventare parte del ciclo operativo.
Un’organizzazione dovrebbe conservare un insieme di domande reali e casi critici da utilizzare come benchmark interno. Quando cambia il modello, il prompt, il sistema di retrieval o la knowledge base, quelle domande possono essere rieseguite per capire se la qualità è migliorata oppure peggiorata.
Questo approccio consente anche di separare problemi differenti.
Se una risposta è sbagliata, il problema potrebbe non essere il modello ma potrebbe:
- essere stato recuperato il documento sbagliato?
- esserci una versione obsoleta nella knowledge base?
- mancare una fonte necessaria?
- il prompt avere dato istruzioni troppo generiche?
Senza tracciabilità è difficile distinguere queste cause.
Per questo il controllo della knowledge base diventa una componente della governance AI. Un sistema dovrebbe poter mostrare quali fonti sono state utilizzate, quali informazioni sono state fornite al modello e, quando possibile, quale percorso ha portato alla risposta.
La stessa logica vale per gli AI Agent. Se un agente può inviare email, aggiornare un gestionale o eseguire un workflow, un errore non produce più soltanto una risposta inesatta: può trasformarsi in un’azione. I test devono quindi includere non solo la qualità del testo generato, ma anche i limiti operativi dell’agente.
Perché il modello migliore non risolve il problema
La ricerca Anthropic evidenzia anche un altro elemento interessante: modelli più grandi usati tramite prompting possono, in alcuni casi, rilevare meglio le menzogne rispetto a detector specializzati addestrati con fine-tuning.
Non significa che la soluzione sia semplicemente utilizzare sempre un modello più grande. Significa che l’architettura di controllo deve essere valutata empiricamente.
In alcuni workflow può funzionare bene un secondo modello che verifica il primo. In altri casi può essere più utile un controllo deterministico. In altri ancora è necessario combinare retrieval, regole, scoring e revisione umana.
La scelta dovrebbe dipendere dal rischio e dal processo.
Un’attività di brainstorming interno può tollerare una percentuale maggiore di errore. Una risposta su una procedura fiscale, una pratica amministrativa o un documento contrattuale richiede invece controlli più forti e fonti verificabili.
Questa distinzione è importante anche in termini di costi: applicare lo stesso livello di verifica a ogni richiesta può essere inefficiente. Un sistema maturo dovrebbe poter modulare modello, controlli e workflow in base alla criticità del compito.
Gol-IA e il controllo dell’intera catena informativa
È in questo scenario che si colloca Gol-IA: l’obiettivo del progetto non è creare semplicemente un’interfaccia per interrogare un LLM, ma costruire un hub nel quale gestire modelli, utenti, knowledge base, fonti, retrieval, conversazioni e workflow.
Per realtà con pochi utenti, l’intero sistema può essere eseguito localmente con modelli open source, mantenendo documentazione e chat nell’infrastruttura dell’organizzazione. Per realtà con carichi maggiori è possibile utilizzare modelli esterni quando serve maggiore capacità, mantenendo però localmente la knowledge base e inviando soltanto il contesto selezionato necessario alla risposta.
Questa architettura permette di costruire un livello di governance più chiaro: sapere quali fonti sono presenti, quali informazioni vengono recuperate e quale modello viene utilizzato.
Soprattutto, consente di introdurre valutazioni interne costruite sulle domande reali dell’organizzazione.
Una consulenza AI efficace dovrebbe partire proprio da questo punto. Prima ancora di chiedersi quale sia il modello più potente, bisogna identificare i processi, classificare il rischio delle attività e definire come misurare se il sistema sta realmente migliorando il lavoro.
La ricerca di Anthropic ricorda che i controlli possono fallire quando il mondo reale si allontana dai dati di test. Per le aziende la conseguenza è pratica: l’AI non va soltanto implementata. Va continuamente verificata nel contesto in cui viene utilizzata.
Lascia un commento