La maggior parte delle conversazioni sulla valutazione degli agenti AI si concentra sul team di sviluppo: costruisci un test harness, lanci un benchmark, spedisci quando è tutto verde. Ma se sei il responsabile di business o operations che deve dare il via libera a un agente che gestirà richieste reali di clienti, elaborerà fatture reali o instraderà escalation reali — la questione dei test riguarda anche te.
Questo articolo tratta la valutazione degli agenti AI come strumento del committente: quali criteri di accettazione pretendere prima di firmare, e quali controlli di regressione far girare in modo continuativo dopo il go-live per intercettare i malfunzionamenti silenziosi che emergono nel tempo.
Perché “Ha funzionato nella demo” non è uno standard di sign-off
Una demo è un’esecuzione curata. L’agente gestisce i dieci input che qualcuno sa già che gestisce bene. La produzione è diversa: gli input arrivano in formati inattesi, gli utenti formulano le richieste in modi che nessuno aveva previsto, le API collegate restituiscono risposte di edge case e il modello linguistico sottostante viene aggiornato dal provider.
Ognuno di questi eventi è una potenziale regressione. Senza una suite di eval formale, il primo segnale che ricevi è un reclamo — o peggio, un errore a valle che scopri solo durante un audit.
Il divario tra “funziona nella demo” e “si comporta in modo affidabile in produzione” è esattamente dove la maggior parte dei progetti con agenti AI incontra i primi problemi seri. Le evals colmano quel divario in modo sistematico, invece di sperare che nulla cambi.
I tre livelli di una suite di eval affidabile
Un programma di valutazione ben strutturato copre tre livelli distinti. Non sono alternative — servono tutti e tre.
1. Correttezza funzionale: l’agente fa ciò per cui è stato progettato?
Questo livello verifica il task principale. Per un agente di triage del supporto, significa: classifica correttamente la priorità del ticket? Lo instrada al team giusto? Gestisce un campo mancante senza andare in crash?
Criteri di accettazione concreti da richiedere al fornitore:
- Un test set documentato di almeno 50–100 input rappresentativi (di più per workflow ad alto volume), che copra casi normali, edge case e modalità di fallimento note
- Un tasso di accuratezza target concordato nel contratto — non “best effort”, un numero — es. ≥92% di classificazione corretta sul test set
- La gestione documentata degli input fuori perimetro: cosa fa l’agente quando riceve qualcosa per cui non è stato progettato? Fallisce in modo controllato o produce una risposta sbagliata con sicurezza?
Il test set stesso deve essere parte del deliverable. Se un fornitore non riesce a mostrarti i test case, non hai nessuna baseline.
2. Fedeltà di tool e integrazioni: l’agente interagisce correttamente con i sistemi connessi?
Gli agenti in produzione chiamano tool esterni — CRM, calendari, database, API di pagamento. La correttezza funzionale in isolamento non garantisce il comportamento corretto quando quelle integrazioni sono in gioco.
Questo livello verifica:
- L’agente scrive i dati nei campi giusti, nel formato corretto, nelle condizioni giuste?
- Gestisce errori API, rate limit o schemi di risposta inattesi senza perdere dati silenziosamente?
- Esistono guardrail sugli effetti collaterali — cioè, l’agente rifiuta di compiere azioni irreversibili (eliminare record, inviare email, addebitare carte) senza un passaggio di conferma umana dove la posta in gioco lo richiede?
Per workflow multi-sistema complessi, chiedi al fornitore di dimostrare un failure injection test: restituisci deliberatamente una risposta API malformata e osserva come reagisce l’agente. Un agente che va in panic o produce un fallback allucinato non è pronto per la produzione.
3. Consistenza comportamentale: l’agente si comporta in modo prevedibile con formulazioni e condizioni variabili?
I modelli linguistici sono probabilistici. Lo stesso intento semantico espresso in dieci modi diversi dovrebbe produrre lo stesso risultato. Un agente di supporto che gestisce correttamente “voglio cancellare il mio ordine” ma non instrada “per favore annulla il mio abbonamento” ha un problema di consistenza che emerge solo su scala.
Questo livello prevede tipicamente:
- Paraphrase testing: più formulazioni dello stesso intento
- Input avversariali: tentativi di manipolare l’agente verso azioni fuori perimetro
- Persona boundary testing: l’agente rimane nel suo ruolo definito, o un utente può spingerlo in territori non correlati?
Questo è strettamente legato al profilo di rischio di sicurezza e prompt injection dell’agente — le due preoccupazioni condividono l’infrastruttura di test e dovrebbero essere affrontate insieme.
Come appare una checklist di accettazione minimale
Prima di dare il via libera a un nuovo deployment, dovresti poter rispondere sì a ciascuno dei seguenti punti:
- Esiste un test set documentato ed è stato condiviso con noi come deliverable di progetto
- I target di accuratezza per i task principali sono definiti e sono stati raggiunti sul test set
- La gestione degli edge case e degli errori è stata dimostrata, non solo descritta
- Le integrazioni dei tool sono state testate con connessioni reali (o sandbox realistiche)
- Il comportamento dell’agente sugli input fuori perimetro è definito e testato
- È stata registrata una snapshot di performance baseline così che la regressione sia rilevabile
Questa lista è volutamente breve. Non si tratta di avviare un programma di dottorato in ML evaluation — si tratta di stabilire una baseline difendibile che ti protegga e responsabilizzi il fornitore. Un fornitore a disagio con questa lista è un fornitore di cui diffidare.
Per una visione più ampia di cosa chiedere nella scelta di un partner, la guida alle società di sviluppo agenti AI approfondisce la due diligence sui fornitori.
Controlli di regressione: intercettare il degrado silenzioso dopo il go-live
Superare i test di accettazione al lancio è necessario ma non sufficiente. Gli agenti degradano silenziosamente. Le ragioni sono strutturali:
Aggiornamenti del modello. Il modello linguistico che alimenta il tuo agente verrà aggiornato dal provider — le deprecazioni formali di solito prevedono un preavviso, ma le modifiche alle capacità all’interno di una versione in esecuzione e gli aggiornamenti degli alias predefiniti possono avvenire con notifica limitata o nulla ai singoli clienti. Un aggiornamento del modello che migliora le prestazioni sulla maggior parte dei task può regredirti sulle tue. Senza una suite di regressione che gira a cadenza fissa, lo scopri solo quando gli utenti ti segnalano che qualcosa non va.
Data drift. Il vocabolario e il contesto delle richieste reali degli utenti cambia nel tempo. Un agente di customer support addestrato e testato sul catalogo prodotti dell’anno scorso potrebbe iniziare a instradare male le richieste dopo un cambio di linea prodotto, anche se il modello sottostante è invariato.
Modifiche alle integrazioni. Un’API da cui dipende il tuo agente aggiorna il suo schema. Un nome di campo cambia. Appare un nuovo parametro obbligatorio. L’agente o fallisce o torna a un comportamento non previsto.
Scenario illustrativo: Immagina un agente di elaborazione documenti che gestisce le fatture in arrivo dai fornitori. Al lancio, estrae correttamente le voci e le instrada per approvazione al 94% sul test set. Sei mesi dopo, un fornitore chiave cambia il template della fattura. Senza un controllo di regressione settimanale su un campione fisso di fatture reali, quella precisione potrebbe scendere silenziosamente al 70% prima che qualcuno se ne accorga — ovvero quasi una fattura su tre che finisce in una coda di fallback manuale che avrebbe dovuto essere automatizzata. Il costo del monitoraggio per intercettare questo in anticipo è trascurabile rispetto allo sforzo di riconciliazione a valle.
Il setup di monitoraggio minimale praticabile non è complesso:
- Un golden dataset fisso — un campione curato di 20–50 input di produzione con output corretti noti, tenuto fuori da qualsiasi processo di training o fine-tuning
- Una regression run pianificata — settimanale o dopo qualsiasi modifica infrastrutturale, fai girare l’agente sul golden dataset e confronta gli output con la baseline
- Una soglia di alerting — se l’accuratezza sul golden set scende di più di X punti percentuali rispetto alla baseline, attiva una revisione umana prima che il problema si aggravi
Questo si ricollega direttamente alla questione più ampia di quali KPI dimostrano davvero che un agente funziona — le metriche di regressione dovrebbero confluire nello stesso dashboard operativo dei tuoi KPI di business, non vivere in un silo ingegneristico separato.
Chi è responsabile delle evals — e cosa contrattualizzare
Il fornitore costruisce e gestisce la suite di eval iniziale. Il business possiede i criteri di accettazione e il diritto di vedere i risultati. Dopo il go-live, il monitoraggio continuativo della regressione è una responsabilità condivisa che deve essere esplicita nel contratto o nell’accordo di servizio.
In particolare, chiarisci:
- Chi esegue i controlli di regressione, e con quale cadenza?
- Chi viene notificato quando una soglia di regressione viene superata?
- Qual è lo SLA per indagine e risoluzione dopo una regressione rilevata?
- Riceverai un report di sintesi, o solo un alert?
Non sono domande ostili. Un fornitore con pratiche di sviluppo agenti AI mature avrà risposte pronte, perché esegue questi controlli per la propria quality assurance. La conversazione ti dice molto sulla maturità operativa.
Le organizzazioni attente alla governance potrebbero voler registrare i risultati delle eval come parte di un audit trail di AI governance più ampio — particolarmente rilevante per i settori regolamentati o dove si applica l’EU AI Act. Va notato che la maggior parte degli agenti di automazione B2B (triage del supporto, elaborazione fatture, scheduling) rientra nella categoria a rischio minimo o limitato ai sensi della normativa, non nella categoria ad alto rischio dell’Allegato III che porta gli obblighi documentali più pesanti. Per quegli obblighi ad alto rischio, la scadenza originale di agosto 2026 sarà probabilmente rinviata a dicembre 2027 nell’ambito dell’accordo provvisorio Digital Omnibus, anche se l’adozione formale era ancora in sospeso al momento della pubblicazione.
Le evals sono uno strumento di fiducia, non una formalità
Il punto più profondo è questo: una suite di eval non è overhead burocratico. È la base di evidenze che ti permette di estendere la fiducia a un sistema automatizzato che opera su scala nel tuo business. Senza di essa, stai affidandoti all’intuizione e sperando che nessun edge case emerga nel momento sbagliato.
I committenti che chiedono le evals ottengono agenti migliori. Il processo di definizione dei criteri di accettazione forza la specificità — su cosa l’agente dovrebbe fare, cosa non dovrebbe fare, e come verranno misurate le prestazioni. Quella specificità tende a far emergere aspettative disallineate presto, quando sono ancora economiche da correggere.
Se sei nella fase di valutazione di una proposta di fornitore, stai definendo i criteri di accettazione per un nuovo agente, o cerchi di stabilire il monitoraggio per un agente già in produzione — una call mirata di 30 minuti con il nostro team può aiutarti a identificare i controlli e i criteri specifici per il tuo caso d’uso. Contatta Orange ITS e struttureremo la conversazione attorno alla tua situazione.