Test agente AI aziendale: come validarlo prima del go-live

Un agente AI che risponde bene nella demo non è un agente pronto. È una delle asimmetrie più costose dell’adozione aziendale: il software tradizionale, se funziona in test, funziona in produzione, perché è deterministico. Un agente no. Lo stesso prompt, lo stesso giorno, può produrre due traiettorie diverse, e una delle due può chiamare lo strumento sbagliato con i parametri giusti, o quello giusto con i parametri sbagliati. Per questo un test agente AI aziendale non è una sessione di prove manuali davanti a una chat, ma una pipeline di validazione con soglie dichiarate prima di iniziare.

Gartner stima che oltre il 40% dei progetti di agentic AI sarà cancellato entro fine 2027, per costi in escalation, valore di business poco chiaro e, terza causa, quella che ci interessa qui, controlli di rischio inadeguati. Non è un problema di modelli. È un problema di collaudo. Questo articolo spiega cosa si misura, con quali numeri si decide il go-live, e dove finisce quello che un team interno riesce a fare da solo.

In questo articolo scoprirai:

• Perché «facciamo qualche prova e vediamo come risponde» non è un collaudo
• Il test set di prompt: quanti casi servono e come si costruiscono
• Output giusto, percorso sbagliato: valutare la traiettoria e non solo la risposta
• Come si misura il tasso di allucinazione di un agente aziendale
• Red teaming light sui guardrail: gli attacchi da provare prima del go-live

Perché «facciamo qualche prova e vediamo come risponde» non è un collaudo

Il metodo più diffuso per validare un agente prima del rilascio è anche il più inutile: qualcuno del team apre la chat, prova otto o dieci richieste rappresentative, osserva che le risposte sembrano sensate e dichiara chiuso il test. Funziona per un prototipo. Non funziona nel momento in cui l’agente smette di essere un generatore di testo e diventa un attore con credenziali, strumenti e memoria, la differenza che abbiamo descritto in dettaglio in cosa sono gli agenti AI.

La differenza è sostanziale e va nominata, perché è la ragione per cui le checklist di QA tradizionali non si trasferiscono. Un chatbot sbagliato produce una frase sbagliata; un agente sbagliato produce un’azione sbagliata, un ordine emesso, un rimborso approvato, un record scritto su un CRM, una mail inviata a un cliente. IBM, nella sua trattazione del testing degli agenti AI, lo formula così: il collaudo non consiste nel verificare che l’output sia conforme alle aspettative, ma che resti motivato, accurato e sicuro qualunque sia l’input. Sempre IBM riporta un dato che spiega da solo il divario: l’80% dei CIO e CTO intervistati ha un mandato di trasformazione AI, ma solo l’11% si sente completamente pronto per la scala di implementazione prevista.

Cosa cambia quando l’agente ha accesso agli strumenti aziendali

Le prove manuali coprono il percorso felice, cioè la richiesta ben formulata da un utente collaborativo. In produzione arrivano richieste ambigue, contraddittorie, formulate male, e ogni tanto qualcuno che prova deliberatamente a far dire o fare all’agente qualcosa che non dovrebbe. A questo si aggiunge il fatto che le prove manuali non sono riproducibili: non esiste un confronto fra la versione di oggi e quella di due settimane fa, quindi non esiste modo di sapere se una modifica al prompt ha migliorato qualcosa o ha rotto un caso che prima funzionava. È lo stesso motivo per cui molti progetti restano bloccati allo stadio dimostrativo: abbiamo analizzato altrove le quattro cause per cui i POC si bloccano, e l’assenza di un criterio di validazione ripetibile è la più frequente.

Il test set di prompt: quanti casi servono e come si costruiscono

Il primo artefatto di un collaudo serio è un insieme di casi di prova scritti a mano, versionati come codice ed eseguibili a comando. Nella pratica dei team che gestiscono agenti in produzione l’ordine di grandezza iniziale è di alcune decine di casi, non centinaia, purché coprano quattro famiglie distinte: percorso felice, casi limite del processo, input avversariali e scenari di fallimento previsto, cioè le situazioni in cui la risposta corretta è «non posso farlo» o «passo a un collega umano».

La provenienza dei casi conta più del numero. Un test set inventato a tavolino misura l’immaginazione di chi l’ha scritto, non il comportamento degli utenti. PostHog, nella sua guida al testing degli agenti, raccomanda di costruire il dataset partendo dai fallimenti reali: feedback negativi, ticket di supporto, picchi di errore, cluster anomali nelle tracce. Chi non ha ancora traffico di produzione parte dal materiale che l’azienda già possiede, lo storico dei ticket dell’help desk, le mail ricorrenti, i casi che il processo attuale gestisce peggio: lo stesso materiale da cui si parte per costruire un agente su misura. Vale la pena arrivare a questo punto avendo già fatto l’audit dei dati prima del pilot: un test set costruito su dati incoerenti valida un agente contro una realtà che non esiste.

Prompt avversariali: le categorie da coprire prima del rilascio

Gli input avversariali non sono solo tentativi di jailbreak. Sono anche richieste fuori perimetro («puoi darmi lo sconto del 40%?»), richieste che contengono premesse false («come mi avete confermato ieri…»), richieste che mescolano due intenti, e richieste che chiedono all’agente di rivelare le proprie istruzioni. Ogni categoria va rappresentata nel test set con almeno qualche caso, e ciascuno deve avere un esito atteso scritto: non «vediamo cosa risponde», ma «deve rifiutare e proporre l’escalation». Se non sapete formulare l’esito atteso, il problema non è il test, è che la policy aziendale su quel caso non esiste ancora. Sulla costruzione degli input vale la pena aver messo mano prima ai fondamentali del prompt engineering.

Output giusto, percorso sbagliato: valutare la traiettoria e non solo la risposta

Qui sta l’errore più sottile del collaudo amatoriale. Un agente può arrivare alla risposta corretta per la strada sbagliata: interrogando tre volte lo stesso strumento, o interrogandone uno che non doveva toccare, o indovinando il risultato invece di recuperarlo. Se si valuta solo l’output finale, quella traiettoria passa il test, e poi in produzione, su un caso leggermente diverso, l’indovinello non funziona più.

IBM struttura la valutazione su tre livelli: test di componente sui singoli strumenti e sulla gestione della memoria, test di traiettoria sul percorso di ragionamento completo, test end-to-end su compiti realistici con giudizio umano strutturato. Le metriche che ne escono sono quattro e vanno dichiarate prima: success rate (quanti casi l’agente completa), tool precision (se sceglie lo strumento giusto con i parametri giusti), coerenza della traiettoria, e la coppia latenza/costo. Stack AI, nel suo framework di QA per agenti, aggiunge un’indicazione che cambia il modo di leggere i numeri: si ottimizza il costo per compito riuscito, non il costo per token. Un modello più economico che sbaglia il 20% in più costa di più, perché ogni fallimento genera un secondo tentativo o un intervento umano.

LLM-as-a-judge: come si valuta chi valuta

Con decine di casi e più esecuzioni per caso, la valutazione manuale non scala. La pratica corrente è usare un secondo modello come giudice, con una rubrica scritta in linguaggio naturale. Databricks, nella sua trattazione della valutazione degli agenti, avverte però che i giudici basati su LLM portano bias propri e vanno calibrati su un campione revisionato da esperti umani. In pratica: prima si fanno valutare a mano trenta o quaranta casi da chi conosce il processo, poi si verifica che il giudice automatico concordi, e solo allora lo si lascia girare da solo. Un giudice non calibrato non misura l’agente: misura sé stesso.

Come si misura il tasso di allucinazione di un agente aziendale

«Tasso di allucinazione» è un’espressione comoda ma imprecisa, e in un contesto aziendale va scomposta in cose misurabili. La metrica centrale è la groundedness, cioè la verifica che ogni affermazione dell’agente sia sostenuta da informazione effettivamente recuperata e non da un’assunzione del modello. È misurabile solo se l’agente lavora su fonti tracciabili: per questo la qualità dell’architettura di recupero, il tema che abbiamo trattato nella guida al RAG, determina il tetto massimo di accuratezza raggiungibile, indipendentemente dal modello scelto.

Microsoft, nella documentazione del suo AI Red Teaming Agent, isola una categoria specifica chiamata ungrounded attributes: risposte che contengono inferenze non fondate su attributi personali, dati demografici, stato emotivo, inventati a partire dal contesto. In un agente di customer care è esattamente il tipo di errore che genera un reclamo. Accanto a questa, Microsoft misura la task adherence: se l’agente raggiunge l’obiettivo dell’utente rispettando le regole e le procedure previste, senza omissioni né azioni non autorizzate.

Quando l’agente inventa perché lo strumento ha fallito

Il caso peggiore non è l’agente che inventa dal nulla. È l’agente che inventa dopo che una chiamata a uno strumento è fallita in silenzio: l’API va in timeout, il record non esiste, il campo torna vuoto, e il modello, invece di fermarsi, produce una risposta plausibile che riempie il buco. È un fallimento invisibile a chi guarda solo l’output, perché l’output è ben scritto e credibile. Si intercetta solo confrontando le tracce delle chiamate con il testo prodotto, il che significa che l’osservabilità non è un accessorio del post-go-live: è uno strumento di collaudo. Anthropic, nella sua analisi su come costruire agenti efficaci, insiste sul punto: l’agente deve ricevere a ogni passo un riscontro verificabile dall’ambiente, risultato dello strumento, esito dell’esecuzione, altrimenti gli errori si compongono invece di correggersi.

Red teaming light sui guardrail: gli attacchi da provare prima del go-live

Non serve un’esercitazione di sicurezza offensiva completa per validare un agente aziendale. Serve una passata sistematica sulle categorie di rischio che riguardano specificamente i sistemi agentici, che non sono le stesse dei modelli linguistici. L’OWASP Top 10 for Agentic Applications, pubblicata il 9 dicembre 2025 con il contributo di oltre cento esperti, codifica dieci categorie da ASI01 a ASI10. Le quattro che un collaudo aziendale deve toccare sempre, secondo la lettura del documento: Agent Goal Hijack (dirottamento degli obiettivi via contenuti esterni), Tool Misuse (uso improprio di strumenti legittimi per istruzioni ambigue o permessi eccessivi), Memory & Context Poisoning (corruzione della memoria a lungo termine o dei dati RAG, che condiziona in modo permanente le decisioni future) e Identity and Privilege Abuse.

Sul piano operativo, Microsoft misura l’esito di queste prove con una metrica sola: l’Attack Success Rate, cioè la percentuale di attacchi riusciti sul totale dei tentativi. Le strategie di attacco disponibili nel suo strumento, che poggia sul framework open source PyRIT, vanno dalle codifiche banali (Base64, ROT13, Leetspeak, inversione dei caratteri) fino agli attacchi multi-turno e al Crescendo, che alza gradualmente la posta su più scambi finché la difesa cede. È significativo che gli attacchi più efficaci non siano i più sofisticati: un rifiuto che regge alla domanda diretta spesso non regge alla stessa domanda scritta al contrario.

Prompt injection indiretta: l’attacco che non arriva dall’utente

La categoria che i team interni sottovalutano di più è la prompt injection indiretta (XPIA): istruzioni malevole nascoste dentro fonti esterne, una mail, un PDF, una pagina web, una scheda di un CRM, che l’agente recupera via tool call e interpreta come comandi. Non serve un utente ostile: basta che l’agente legga un documento che qualcun altro ha preparato. Il perimetro da testare non è la chat, è ogni fonte da cui l’agente legge. Microsoft misura qui l’ASR sulle categorie agentiche specifiche: azioni proibite, fuga di dati sensibili, aderenza al compito. E mette in guardia su un punto che vale anche per chi costruisce test in casa: le valutazioni automatiche usano modelli generativi, quindi sono non deterministiche e producono falsi positivi, i risultati vanno riletti da una persona prima di agire. Se l’agente si collega a sistemi esterni via protocolli standard, il tema si estende: ne abbiamo parlato nella guida agli MCP Server.

Carico sulle integrazioni e staging con dati sintetici

Un agente che passa tutte le valutazioni di qualità può comunque rompersi al primo lunedì mattina, quando trenta persone lo usano insieme. Le prove di carico su un agente non misurano il modello: misurano le integrazioni. Cosa succede quando il CRM va in rate limit, quando un’API risponde in otto secondi invece che in uno, quando due esecuzioni concorrenti scrivono sullo stesso record. Perché una prova di carico sia un collaudo e non un’impressione, servono quattro grandezze messe a verbale prima del go-live. Primo: il numero di utenti concorrenti simulati, che va portato almeno al doppio del picco previsto nella prima settimana, se il processo coinvolge trenta persone, si prova a sessanta sessioni parallele. Secondo: il p95 della latenza end-to-end con gli strumenti in catena, misurato sull’intera traiettoria e non sulla singola chiamata al modello, con una soglia dichiarata (per un agente conversazionale interno, l’ordine di grandezza usuale è sotto i 10 secondi; per uno batch può essere molto più alto, ma va scritto). Terzo: il comportamento atteso a rate limit raggiunto, l’agente deve degradare in modo esplicito, cioè mettere in coda o dichiarare all’utente che non può procedere, mai inventare il dato che l’API non gli ha restituito. Quarto: il numero massimo di retry e la finestra di idempotenza sulle azioni irreversibili, per esempio non più di tre tentativi con backoff esponenziale e una chiave di idempotenza valida almeno 24 ore su pagamenti, ordini e invii al cliente. La domanda operativa da porre è se l’agente, davanti a un timeout, riprova, e se riprovando esegue due volte un’azione che andava eseguita una volta sola. L’idempotenza sulle azioni irreversibili è un requisito di collaudo, non un dettaglio implementativo.

Il tutto va fatto in un ambiente che somigli alla produzione senza esserlo. Microsoft usa l’espressione purple environment: un ambiente non di produzione configurato con risorse realistiche, per osservare l’agente in condizioni verosimili. I dati sintetici servono a popolare quell’ambiente senza esporre dati reali, ed è la stessa Microsoft ad ammettere il limite della scelta: i dati sintetici non rappresentano le distribuzioni del mondo reale, quindi un agente validato solo su di essi resta parzialmente non misurato. Va detto, non nascosto.

Cosa chiede l’AI Act sui test di robustezza

Per i sistemi classificati ad alto rischio, questa non è più buona pratica ma obbligo. L’articolo 15 dell’AI Act richiede un livello appropriato di accuratezza, robustezza e cybersicurezza costante lungo tutto il ciclo di vita, impone che i livelli di accuratezza siano dichiarati nelle istruzioni d’uso, e nomina esplicitamente le vulnerabilità da presidiare: data poisoning, model poisoning, adversarial examples, attacchi alla confidenzialità. Chi vuole un quadro completo degli obblighi e delle scadenze lo trova nella nostra guida su cosa prevede l’AI Act. Sul versante metodologico, il NIST AI Risk Management Framework, con le quattro funzioni Govern, Map, Measure, Manage e il Generative AI Profile pubblicato il 26 luglio 2024, è il riferimento più usato per dare una struttura a questa documentazione.

Dal test al go-live: shadow mode, canary e le soglie che decidono

Il passaggio in produzione non è un interruttore. È una sequenza di esposizioni crescenti, ognuna con un criterio di uscita numerico. The Pedowitz Group propone una progressione in sei fasi che è la più concreta che abbiamo trovato: sandbox in CI quotidiana con dati sintetici, valutazioni automatiche contro soglie, red teaming, shadow mode su traffico reale per una o due settimane (l’agente elabora ma non agisce, e si confronta ciò che avrebbe fatto con ciò che ha fatto l’operatore umano), canary release su un pubblico limitato con budget rigido, monitoraggio continuo.

Le soglie che quella stessa fonte propone come criterio go/no-go danno l’ordine di grandezza: successo delle azioni sensibili ≥ 98% in canary, tasso di escalation ≤ 5% in partenza e decrescente, quality score ≥ 0,8 su rubrica, costo per risultato non superiore alla baseline meno 15%, e capacità di disattivare l’agente in meno di 60 secondi. Sono numeri da calibrare sul proprio processo, un agente che emette pagamenti e uno che smista ticket non hanno la stessa tolleranza, ma il principio è che i numeri esistano e siano scritti prima, non negoziati dopo davanti al primo incidente. Il kill switch, in particolare, è la voce che si dimentica più spesso: senza di esso un errore in produzione dura quanto serve a convocare una riunione. Su come si struttura questa transizione abbiamo scritto una guida dedicata: da pilot a produzione.

Cosa fa un partner AI che il team interno di solito non è attrezzato a fare

Nulla di quanto descritto qui è oltre le capacità di un buon team IT. È però oltre il suo tempo e, soprattutto, oltre la sua esperienza pregressa: chi ha passato dieci anni a collaudare software deterministico ha ottimi riflessi per bug riproducibili e nessuno strumento mentale per un sistema che sbaglia il 4% delle volte in modo diverso ogni volta. Il divario non è di competenza ma di categoria, ed è il motivo per cui i progetti falliscono su controlli di rischio inadeguati, la terza causa della previsione Gartner con cui abbiamo aperto.

Il metodo di test che un partner porta già calibrato

Quello che un partner porta è prima di tutto un metodo già calibrato: il test set come asset versionato che cresce a ogni incidente invece di essere ricostruito ogni volta, il giudice automatico tarato su casi revisionati da chi conosce il processo, le categorie OWASP tradotte in prove eseguibili sul vostro perimetro, e le soglie di go-live decise insieme al business prima che ci sia un incidente da giustificare. E porta, quando serve, la raccomandazione meno commerciale di tutte: Anthropic invita a cercare la soluzione più semplice possibile e ad aumentare la complessità solo quando migliora dimostrabilmente i risultati, spesso, davanti a un processo ben definito, la risposta giusta è un workflow deterministico e non un agente. Un partner che non vi dice mai di non costruire l’agente vi sta vendendo un prodotto, non un servizio.

Il presidio del test dopo il go-live

C’è poi la parte che inizia il giorno dopo il rilascio, ed è quella che distingue una fornitura da un accompagnamento. Microsoft, dopo aver testato oltre cento prodotti di AI generativa, arriva a tre conclusioni di cui due contano qui: il red teaming non si automatizza del tutto, perché dipende in modo determinante dall’esperienza umana; e le mitigazioni non eliminano il rischio, quindi la sicurezza di un sistema AI non è mai «finita», richiede cicli ripetuti di test, misura e correzione. Tradotto in termini aziendali: qualcuno deve guardare le tracce ogni settimana, riportare i fallimenti nel test set, e rieseguire le prove a ogni cambio di modello o di prompt. È esattamente il lavoro che descriviamo nei primi 30 giorni con un agente AI e che prosegue con la formazione del team dopo il go-live.

Se state valutando un agente per la vostra azienda e non avete ancora un criterio scritto per dire «è pronto», il punto di partenza sensato è a monte: capire se l’organizzazione è pronta. Noi di MIMIR lavoriamo su entrambi i lati: costruiamo l’agente e restiamo a presidiarne il collaudo, l’onboarding e le settimane successive al rilascio, perché un agente consegnato senza un metodo di validazione è un prodotto, non una soluzione. Se avete un processo in mente e volete capire se regge un test serio prima di metterlo davanti a clienti o colleghi, parliamone.

Fonti:

• Gartner, Over 40% of agentic AI projects will be canceled by end of 2027
• Digital Applied, Le cause delle cancellazioni dei progetti agentic AI
• IBM, Il testing degli agenti AI
• PostHog, Guida al testing degli agenti AI
• Stack AI, Framework di QA per agenti prima della produzione
• Databricks, Che cos’è la valutazione degli agenti
• Microsoft, AI Red Teaming Agent (Azure AI Foundry)
• Microsoft, Tre lezioni dal red teaming di oltre cento prodotti di AI generativa
• Anthropic, Building effective agents
• OWASP, Top 10 for Agentic Applications 2026
• Giskard, Lettura della OWASP Top 10 for Agentic Applications
• AI Act, Articolo 15: accuratezza, robustezza e cybersicurezza
• NIST, AI Risk Management Framework
• The Pedowitz Group, Rollout sicuro degli agenti AI in sei fasi