Evals, guardrail e controllo delle allucinazioni

Un agente AI che risponde in modo convincente ma inventa una procedura, consulta un documento superato o invia un ordine senza le dovute verifiche non è un problema di stile. È un rischio operativo. Evals, guardrail e controllo delle allucinazioni sono quindi componenti architetturali indispensabili per portare l’intelligenza artificiale nei processi aziendali con risultati misurabili.

La differenza tra una demo efficace e un sistema pronto per la produzione si vede qui. In una demo conta la qualità percepita della risposta. In un ambiente enterprise contano anche correttezza, autorizzazioni, fonti utilizzate, azioni eseguite, tempi di risposta, gestione delle eccezioni e possibilità di ricostruire ogni decisione. L’AI che agisce, non soltanto risponde, deve poter dimostrare perché ha agito e entro quali limiti.

Perché le allucinazioni non si eliminano con un prompt

Un modello linguistico genera testo sulla base di probabilità. Non possiede, per sua natura, una conoscenza certificata del contesto aziendale né una garanzia intrinseca di veridicità. Può formulare una risposta plausibile anche quando i dati sono incompleti, ambigui o assenti. Questo fenomeno viene chiamato allucinazione.

Ridurre il problema a un singolo prompt del tipo “non inventare informazioni” è una scorciatoia. Può migliorare alcuni comportamenti, ma non sostituisce un’architettura di controllo. Se il sistema recupera documenti non pertinenti, se le versioni delle policy non sono governate o se l’agente può chiamare un’API senza validazioni, il prompt non basta.

In azienda le allucinazioni assumono forme diverse. Un copilota commerciale può attribuire a un cliente condizioni contrattuali non previste. Un assistente tecnico può suggerire una procedura manutentiva basandosi su un manuale obsoleto. Un agente collegato all’ERP può interpretare male un codice articolo e creare una richiesta errata. Il danno non deriva solo dalla risposta sbagliata, ma dalla sua capacità di entrare nel flusso operativo.

Per questo il controllo va progettato su più livelli: qualità e aggiornamento dei dati, retrieval, istruzioni di sistema, validazione dell’output, autorizzazioni, limiti sulle azioni, supervisione umana e monitoraggio continuo.

Evals, guardrail e controllo delle allucinazioni: tre livelli distinti

I tre concetti vengono spesso usati come sinonimi. Non lo sono. Lavorano insieme, ma rispondono a domande diverse.

Gli evals misurano la qualità del sistema. Rispondono alla domanda: l’agente sta svolgendo correttamente il compito per cui è stato progettato? I guardrail impongono vincoli durante l’esecuzione. Rispondono alla domanda: cosa può o non può fare, dire, leggere o scrivere? Il controllo delle allucinazioni è l’insieme delle tecniche che limita risposte non fondate e rende esplicita l’incertezza.

Un sistema può avere guardrail molto rigidi e fornire comunque risposte inutili. Può essere valutato con ottimi risultati su un set di test, ma fallire quando riceve un documento nuovo o una richiesta ambigua. Può citare correttamente una fonte e interpretarla in modo errato. La qualità reale nasce dall’integrazione di questi livelli, non dall’adozione isolata di uno strumento.

Gli evals trasformano la qualità in una metrica

Senza valutazione, la qualità di un agente viene giudicata con impressioni soggettive: “sembra funzionare”, “ha risposto bene a cinque domande”, “il team è soddisfatto”. Sono segnali utili, ma non sono una base sufficiente per una decisione di rilascio.

Un programma di evals parte da casi rappresentativi del lavoro reale. Non solo domande frequenti, ma richieste ambigue, documenti contraddittori, dati mancanti, permessi insufficienti, eccezioni di processo e input ostili. Ogni caso deve avere criteri verificabili: risposta corretta, fonti ammesse, azione attesa, azione vietata, tempo massimo e necessità o meno di escalation umana.

Per un sistema RAG, le metriche devono separare due problemi: recuperare i contenuti giusti e generare una risposta fedele a quei contenuti. Se il retrieval fallisce, il modello può essere eccellente e produrre comunque un risultato sbagliato. Se il retrieval è corretto ma la risposta aggiunge dettagli non presenti nelle fonti, il problema è nella generazione o nelle regole di citazione.

Gli evals devono essere eseguiti prima del rilascio, a ogni aggiornamento del modello, dopo modifiche alla knowledge base e durante l’esercizio. Un nuovo listino, una diversa tassonomia documentale o una variazione nelle API del gestionale possono cambiare il comportamento dell’agente. La qualità non è un obiettivo, ma uno standard da verificare continuamente.

I guardrail definiscono i confini dell’azione

Un guardrail non è solo un filtro per parole inappropriate. In un sistema enterprise è un insieme di controlli che delimita il perimetro operativo dell’AI.

Ci sono guardrail sui dati: l’agente deve accedere soltanto alle informazioni autorizzate per quel ruolo, quella sede, quel cliente o quella funzione. Ci sono guardrail sugli strumenti: può interrogare il CRM, ma non modificare opportunità; può preparare una bozza d’ordine, ma non confermarla; può creare un ticket solo se i campi obbligatori sono completi.

Esistono poi guardrail procedurali. Per esempio, una richiesta di rimborso oltre una soglia deve essere inoltrata a un responsabile. Una variazione di anagrafica bancaria richiede doppia verifica. Un agente che individua incongruenze in una fattura può proporre una correzione, ma non registrarla automaticamente nel sistema contabile.

La regola fondamentale è semplice: più l’azione è irreversibile, regolamentata o economicamente rilevante, maggiore deve essere il livello di verifica. L’automazione totale può essere appropriata per attività ripetitive, a basso rischio e con dati strutturati. Per eccezioni, decisioni sensibili o contesti incompleti serve human-in-the-loop, con un passaggio chiaro di responsabilità alla persona.

Come progettare un sistema che sa anche fermarsi

Il comportamento più affidabile di un agente non è sempre dare una risposta. In molti casi è dichiarare che non dispone di evidenze sufficienti, chiedere un chiarimento, recuperare ulteriori dati o passare la pratica a un operatore.

Questa capacità va progettata esplicitamente. L’agente deve conoscere una soglia di confidenza operativa, distinguere tra fonti autorevoli e contenuti informativi, rilevare conflitti tra documenti e riconoscere quando una richiesta esce dal proprio dominio. Dire “non posso confermarlo con i dati disponibili” è spesso più utile e sicuro di una risposta fluida ma infondata.

Nel RAG, il controllo delle allucinazioni richiede una knowledge base governata: documenti normalizzati, metadati, versioni, data di validità, ownership editoriale e criteri di accesso. Il retrieval deve privilegiare contenuti rilevanti e autorizzati, non soltanto vicini dal punto di vista semantico. Il modello deve essere istruito a rispondere usando esclusivamente le fonti recuperate quando il caso d’uso richiede precisione documentale.

Ma anche la citazione di una fonte non è una garanzia assoluta. Occorre verificare che il passaggio richiamato sostenga davvero l’affermazione generata. Per questo è utile introdurre controlli post-generazione: verifica della presenza delle fonti, confronto tra claim e contenuto recuperato, validazione dei campi strutturati e blocco delle risposte che superano limiti definiti.

Dal monitoraggio tecnico alla responsabilità di processo

Un sistema affidabile lascia tracce. Log di input e output, documenti recuperati, tool chiamati, autorizzazioni applicate, tempi, errori e interventi umani devono essere consultabili per analizzare anomalie e migliorare il servizio.

Il monitoraggio non serve soltanto quando qualcosa va storto. Permette di individuare il degrado progressivo della qualità: domande che ricevono sempre più spesso risposte incomplete, documenti che non vengono più recuperati, strumenti che falliscono, costi che aumentano o percorsi decisionali troppo lunghi. Un agente AI è un componente software in evoluzione, non una funzionalità da installare e dimenticare.

Serve inoltre una governance chiara. Ogni dominio di conoscenza dovrebbe avere un owner business responsabile dell’aggiornamento e della validità dei contenuti. L’IT governa integrazioni, sicurezza, identità e continuità operativa. I responsabili di processo definiscono soglie, eccezioni e livelli di autonomia accettabili. L’AI engineering traduce queste esigenze in orchestrazione, evals, policy e controlli tecnici.

PurpleSoft progetta questa architettura end-to-end perché il valore non risiede nel collegare un modello a una chat, ma nel costruire sistemi AI integrati, controllabili e pronti per la produzione. Software, dati e intelligenza artificiale devono operare nella stessa architettura, con regole verificabili.

Il punto di partenza più utile non è chiedersi quanto sia intelligente un modello. È chiedersi quale decisione o attività l’azienda è pronta ad affidargli, quali evidenze deve usare, cosa non può fare e come si misura un errore. Da queste risposte nasce un agente capace di lavorare davvero, senza chiedere all’organizzazione di fidarsi alla cieca.