Una demo mostra che un agente AI può funzionare in un caso scelto. Prima del lancio serve qualcosa di diverso: prove ripetibili che mostrino che produce il risultato corretto, usa fonti e strumenti autorizzati, rispetta i limiti e lascia uno stato sicuro quando qualcosa va storto.
La risposta breve
Un agente AI non è pronto perché ha completato una demo o raggiunto una buona media in un test generico.
Prima che risponda ai clienti o compia azioni, costruisci una serie versionata di casi realistici e raccogli evidenze su cinque aspetti:
- il risultato aziendale richiesto si verifica davvero;
- la risposta è fondata sulle informazioni autorizzate e sul contesto corretto;
- l’agente sceglie lo strumento, il record e i parametri corretti;
- si ferma, chiede conferma o passa a una persona quando raggiunge un limite;
- un errore lascia una situazione visibile, sicura e recuperabile.
I casi devono includere lavoro ordinario, variazioni realistiche, informazioni mancanti, tentativi di oltrepassare i limiti e guasti degli strumenti. I criteri di accettazione vanno stabiliti prima di vedere i risultati.
La decisione non è sempre “lanciare” o “non lanciare”. Il risultato può essere: non pronto, da correggere e ritestare, pronto per un progetto pilota limitato oppure pronto per un lancio entro permessi e condizioni di recupero espliciti.
Prima di testare, definisci il compito e il confine
Non puoi testare “un agente AI” in astratto. Puoi testare una versione precisa dell’agente, incaricata di un compito definito, con fonti, strumenti e permessi specifici.
Scrivi prima cinque elementi:
- quale evento avvia il lavoro;
- quale risultato verificabile deve produrre;
- quali informazioni e strumenti può usare;
- quali azioni sono vietate o richiedono approvazione;
- quando deve fermarsi o passare il caso a una persona.
Poi classifica le conseguenze di un errore. Una risposta informativa facilmente correggibile non richiede lo stesso livello di prova di un rimborso, di una modifica a un account o di una decisione che può incidere sui diritti di una persona.
Questo passaggio impedisce un errore comune: valutare come “accurata” una risposta plausibile senza verificare che l’attività aziendale sia stata completata in modo corretto. Se l’agente afferma di avere aggiornato un ticket, l’evidenza non è la frase finale. È lo stato reale del ticket corretto.
Se il problema precedente è capire se il sistema debba essere un agente, un chatbot o una semplice automazione, parti da Agenti AI: cosa sono e quando usarli in azienda. Questo articolo parte dal presupposto che il compito e il confine dell’agente siano già stati scelti.
Costruisci casi che assomigliano al lavoro reale
I prompt ideali dimostrano il percorso previsto. I casi di test devono mostrare anche che cosa succede quando il lavoro non segue quel percorso.
Parti da richieste, documenti, eccezioni e guasti che il processo può incontrare davvero. Anonimizza o ricrea i dati quando necessario. Conserva comunque la struttura che rende il caso difficile: campi mancanti, istruzioni ambigue, record simili, politiche aggiornate, strumenti lenti o risultati parziali.
Una serie compatta dovrebbe coprire almeno queste famiglie:
- casi normali: richieste comuni con informazioni complete;
- variazioni: formulazioni, lingue, ordine dei dati o percorsi diversi ma legittimi;
- informazioni mancanti: l’agente deve chiedere chiarimenti oppure fermarsi;
- casi limite: importi, scadenze, record o condizioni vicini a un confine operativo;
- tentativi avversi: richieste che provano a cambiare le istruzioni, ottenere dati o usare un’autorità non concessa;
- guasti: fonte indisponibile, timeout, risposta incompleta, strumento che fallisce dopo un’azione parziale.
Gli elenchi di minacce, come l’OWASP Top 10 for Agentic Applications, possono aiutare a trovare lacune. Non sostituiscono una valutazione di sicurezza specifica per il sistema, i dati e il settore.
Gli agenti possono produrre percorsi diversi a parità di caso. Ripetere alcuni test aiuta a scoprire errori intermittenti, ma non esiste un numero universale di prove valido per ogni agente. Il volume va deciso in base alla variabilità del compito, alla frequenza prevista e alle conseguenze di un errore.
Compila la scheda delle prove dell’agente
La scheda delle prove dell’agente M4TIC è una sintesi operativa, non uno standard pubblicato e non un modello di certificazione. Per ogni caso conserva scenario, confine atteso, evidenza, conseguenza e decisione. Un semplice “superato” non basta a spiegare che cosa è stato verificato.
Scorri lateralmente nella tabella per confrontare tutte le colonne
| Dimensione | Domanda | Evidenza preferibile | Esempio di errore |
|---|---|---|---|
| Risultato corretto | Il risultato aziendale richiesto si è verificato? | Stato finale verificabile, record o risoluzione confermata | L’agente dichiara il completamento, ma non esiste alcun aggiornamento |
| Risposta fondata | La risposta usa una fonte consentita e il contesto attuale? | Traccia della fonte, verifica della citazione o confronto deterministico | Risposta plausibile ma non supportata; politica superata |
| Strumento e parametri corretti | Ha scelto strumento, record e argomenti sicuri? | Traccia dello strumento, controllo dei parametri e dello stato | Cliente, importo, destinatario o azione errati |
| Rifiuto o passaggio sicuro | Si è fermato o ha passato il caso al confine definito? | Test di confine e verifica dell’esito del passaggio | Agisce senza approvazione o fuori dalla propria autorità |
| Errore recuperabile | Un guasto lascia uno stato sicuro e visibile? | Guasto simulato, limite dei tentativi, log e prova di recupero | Completamento parziale silenzioso, duplicazione o tentativi incontrollati |
Accanto alle cinque dimensioni registra il tipo di caso, la classe di conseguenza, il criterio di accettazione, il valutatore, il risultato osservato, il responsabile e la versione testata.
Tempo di risposta, costo e qualità dell’interazione possono essere importanti. Non sostituiscono però la prova che il compito sia stato completato in modo sicuro.
Il test produce una decisione documentata, non un certificato. L’ambito del rilascio dipende dalle prove e dalle conseguenze di un errore.
Scorri lateralmente nel diagramma su uno schermo stretto
Valuta il risultato e il percorso senza confonderli
Un controllo sul solo messaggio finale può perdere un’azione errata. Un controllo troppo rigido sull’intera sequenza può invece respingere un percorso diverso ma sicuro.
Per questo conviene separare due domande:
- Il risultato finale è corretto? Verifica lo stato reale: prenotazione, ticket, aggiornamento, risposta o passaggio a una persona.
- Le azioni critiche sono state corrette? Controlla gli strumenti ad alto impatto, i record interessati, i parametri e le approvazioni.
Le attuali indicazioni di Microsoft sugli agent evaluator distinguono, tra gli altri aspetti, risultato, aderenza al compito, fondatezza e uso degli strumenti. È un esempio utile di implementazione, non una tassonomia universale.
Non è necessario imporre un unico percorso quando più sequenze producono lo stesso risultato in modo sicuro. È necessario, invece, ispezionare ogni passaggio che può creare un danno, modificare dati o superare l’autorità concessa.
Combina controlli automatici, valutazione assistita e revisione umana
Scegli il valutatore in base all’affermazione che vuoi verificare.
- Controlli deterministici: adatti a stati, campi, parametri, autorizzazioni, formati e regole che hanno una risposta verificabile.
- Valutazione tramite modello: utile per rubriche circoscritte, come pertinenza o completezza, quando è stata confrontata con giudizi umani.
- Revisione umana o specialistica: necessaria per ambiguità, qualità contestuale, casi ad alta conseguenza e decisioni che richiedono competenza di dominio.
Un modello che valuta un altro modello non è automaticamente un arbitro affidabile. Va calibrato su esempi chiari, controllato per errori ricorrenti e affiancato a revisione umana dove la conseguenza lo richiede. La guida di Anthropic sugli eval per agenti raccomanda di progettare attività e valutatori insieme, usare prove ripetute dove serve e verificare i valutatori automatici con giudizi umani.
Nessun singolo metodo copre tutte le cinque dimensioni della scheda. La combinazione è più importante del numero di strumenti di valutazione.
Decidi la soglia in base alle conseguenze
Una media può nascondere l’errore che conta di più.
Immagina che un agente risponda correttamente nella grande maggioranza dei casi, ma una volta esegua un rimborso sul cliente sbagliato. La media non rende accettabile quell’errore. Il caso diventa un blocco al lancio finché autorità, conferma, selezione del record o possibilità di recupero non vengono corrette.
Definisci quindi due tipi di criteri prima del test:
- risultati aggregati utili per osservare qualità, stabilità, costo o latenza;
- errori bloccanti che non possono essere compensati da una buona media.
Le soglie devono essere più rigorose quando l’azione è irreversibile, riguarda diritti, espone dati, crea un costo materiale o rende difficile il recupero. In settori regolati o casi ad alto impatto servono anche revisione legale, di sicurezza e di dominio qualificata. Questo articolo non sostituisce tali verifiche.
Il NIST AI Risk Management Framework tratta test, valutazione, verifica e validazione come attività del ciclo di vita e collega le misure al contesto e al rischio. Il framework è volontario e la versione 1.0 è in revisione: non va trasformato in un obbligo legale generale.
Esegui un lancio limitato e prepara il recupero
Superare i test non dimostra come l’agente si comporterà in ogni situazione futura. Il passo successivo proporzionato è spesso un progetto pilota con esposizione limitata.
Limita una o più dimensioni:
- utenti o clienti ammessi;
- categorie di richiesta;
- strumenti e azioni disponibili;
- importi, volumi o orari;
- necessità di approvazione umana;
- durata del progetto pilota.
Prima dell’avvio, assicurati di poter vedere che cosa è accaduto. Servono log utili, un responsabile delle eccezioni, una procedura di arresto, una gestione dei completamenti parziali e un modo per annullare o correggere le azioni quando possibile.
Prova il recupero, non limitarti a documentarlo. Interrompi una fonte, provoca un timeout controllato e simula un errore dopo un’azione parziale. Verifica che il sistema non nasconda lo stato, non duplichi l’azione e non continui a riprovare senza limite.
Trasforma ogni errore reale in un test di regressione
Un agente cambia quando cambiano il modello, il prompt, le fonti, gli strumenti, i permessi o la politica di passaggio. Una correzione può risolvere un problema e crearne un altro.
Conserva quindi versione, configurazione e risultato di ogni esecuzione. Ogni errore confermato dovrebbe diventare un caso di regressione ripetibile. Riesegui la serie rilevante dopo ogni modifica che può influire sul comportamento.
Il confronto deve rimanere interpretabile. Se cambi contemporaneamente modello, prompt, retrieval e integrazione, sarà difficile capire perché il comportamento sia migliorato o peggiorato. Per quanto possibile, limita le variazioni e registra quelle necessarie.
La regressione non elimina la necessità di monitorare il sistema dopo il lancio. I casi reali continueranno a rivelare combinazioni che la serie pre-lancio non conteneva.
Registra la decisione di lancio
Chiudi il ciclo con un record breve e leggibile. Dovrebbe indicare:
- versione e perimetro testati;
- famiglie di casi incluse;
- evidenza raccolta nelle cinque dimensioni;
- errori bloccanti e limiti conosciuti;
- responsabile della decisione;
- condizioni di monitoraggio e recupero;
- evento che richiederà un nuovo test.
La decisione può essere una delle seguenti:
- Non pronto: mancano confini, evidenze o capacità di recupero essenziali.
- Rivedi e ritesta: il problema è definito e correggibile, ma la versione corrente non supera il gate.
- Progetto pilota limitato: l’evidenza giustifica un’esposizione controllata, non un rilascio completo.
- Lancio entro limiti definiti: i casi e i blocchi concordati sono stati affrontati, con monitoraggio e rollback disponibili.
“Lancio entro limiti definiti” non significa affidabilità garantita. Significa che una versione precisa ha prodotto evidenze sufficienti per un uso preciso, entro condizioni esplicite.
Dopo avere completato la scheda e registrato la decisione, puoi approfondire come M4TIC progetta agenti AI con strumenti, permessi e controllo umano.
Fonti e approfondimenti
Indicazioni primarie dietro questo articolo.
- AI Resource CenterNIST
Risorse correnti sull’AI Risk Management Framework e sulle attività di test, valutazione, verifica e validazione lungo il ciclo di vita.
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence ProfileNIST
Profilo intersettoriale del luglio 2024 che include il test prima dell’impiego tra le considerazioni di gestione del rischio.
- Agent Evaluators for Generative AIMicrosoft Learn
Esempio attuale di valutazione distinta per risultato, aderenza al compito, fondatezza e uso degli strumenti.
- Review the agent evaluation checklistMicrosoft Learn
Indicazioni operative su casi, criteri di accettazione, baseline e regressioni.
- Demystifying evals for AI agentsAnthropic
Guida del 9 gennaio 2026 su prove ripetute, risultati e traiettorie, valutatori misti, calibrazione umana e suite di regressione.
- Top 10 for Agentic Applications 2026OWASP GenAI Security Project
Quadro comunitario corrente per individuare rischi e casi di sicurezza agentica; non è un elenco esaustivo.