Monitoraggio agente AI: dashboard e KPI da controllare

Un agente AI che risponde ai clienti, apre ticket o interroga un gestionale non si comporta come un’applicazione tradizionale: due esecuzioni identiche possono costare cifre diverse, seguire percorsi diversi e finire una bene e una male. Per questo il monitoraggio di un agente AI non è un pannello di cortesia da guardare a fine trimestre, ma lo strumento con cui si decide ogni settimana se l’agente sta lavorando o sta accumulando danni silenziosi. Questo articolo elenca i riquadri che una dashboard deve mostrare, spiega come si legge ogni numero, quale variante guardare, con cosa confrontarla, quali riferimenti di mercato esistono, e quale decisione ciascuno dovrebbe far scattare. È il lato della lettura e del presidio: come si producono i segnali lo abbiamo raccontato altrove.

In questo articolo scoprirai:

• Monitoraggio di un agente AI: di quale problema stiamo parlando
• Perché il monitoraggio applicativo classico non vede quello che fa l'agente
• I cinque gruppi di segnali che una dashboard di agente deve mostrare
• Latenza: quale numero guardare davvero (e perché la media mente)
• Tasso di escalation: il riquadro che dice se l'agente sta lavorando
• Accuratezza: come si misura la qualità delle risposte in esercizio
• Costo per interazione: il riquadro che salta quando nessuno lo guarda
• Drift: il guasto che non fa scattare nessun allarme
• Chi guarda la dashboard: perché in MIMIR il presidio fa parte del servizio

Monitoraggio di un agente AI: di quale problema stiamo parlando

Prima una disambiguazione che fa risparmiare tempo: con la stessa espressione, in italiano, si indicano due cose diverse. La prima è il rilevamento dei bot delle AI che visitano il tuo sito, un tema di traffico e di protezione dei contenuti. La seconda, quella di cui parliamo qui, è la sorveglianza di un agente che tu hai messo in esercizio: un sistema che riceve richieste, ragiona, chiama strumenti esterni e produce un esito per cui la tua azienda risponde.

La differenza rispetto a un software normale è che l’agente non ha un percorso di esecuzione fisso. Sceglie quanti passi fare, quali strumenti invocare, quando fermarsi. Se non sai come funziona questa catena di decisioni, la guida sugli agenti AI spiega il meccanismo; qui diamo per acquisito che l’agente sia già in produzione.

Perché il monitoraggio di un agente AI parte dalla variabilità

Il punto pratico è che la variabilità va misurata, non tollerata a occhio. TrueFoundry lo dice con un esempio che chiunque abbia messo un agente online riconosce: una singola esecuzione può costare 0,05 dollari e la successiva 2,00 dollari, perché la seconda ha fatto più passi, ha riletto più contesto, ha ritentato una chiamata fallita. Nessuna di queste informazioni compare in un log di richieste HTTP. È la stessa ragione per cui IBM tratta l’osservabilità degli agenti come una disciplina a sé rispetto al monitoraggio applicativo.

Da qui discende tutto il resto. La dashboard di un agente non serve a rassicurare: serve a rendere visibile una distribuzione di comportamenti, non una media. E soprattutto serve a legare ogni numero a una decisione, cambiare un prompt, limitare uno strumento, spostare il traffico su un altro modello, rimettere un umano nel percorso. Un riquadro che non fa scattare nessuna decisione si può togliere.

Perché il monitoraggio applicativo classico non vede quello che fa l’agente

Gli strumenti di application monitoring nascono per un mondo in cui una richiesta entra, una risposta esce e lo stato HTTP dice come è andata. Sentry lo riassume in modo tagliente: gli strumenti standard riportano che «POST /api/chat ha restituito 200 in 4,2 secondi», mentre dentro quei 4,2 secondi l’agente ha fatto cinque chiamate al modello e alla terza ha scelto lo strumento sbagliato, riportando un’informazione obsoleta. Tecnicamente è un successo. Per il cliente è una risposta falsa.

La stessa osservazione arriva da LangChain in una forma ancora più scomoda: un’esecuzione può concludersi correttamente e restituire comunque un risultato pessimo. Il codice di stato e la qualità semantica sono due assi indipendenti, e una dashboard che ne mostra uno solo dà una sicurezza che non esiste.

Tracce gerarchiche e standard aperti nel monitoraggio di un agente AI

Il rimedio adottato dal settore è la traccia gerarchica: ogni passo dell’agente diventa uno span annidato. Sentry cita le operazioni gen_ai.invoke_agent per il ciclo completo, gen_ai.request per la singola chiamata al modello e gen_ai.execute_tool per l’uso di uno strumento. Non è una convenzione di un singolo fornitore: Microsoft dichiara esplicitamente che la propria funzionalità di agent observability in Azure Monitor si basa sulle OpenTelemetry Generative AI Semantics, e la vista «Dettagli agente» di Application Insights consolida su quella base gli agenti di Microsoft Foundry, di Copilot Studio e di terze parti.

Per l’azienda che sta scegliendo, questo è l’unico dettaglio tecnico davvero strategico: se la telemetria segue uno standard aperto, i dati restano tuoi anche quando cambi fornitore di agenti o di dashboard. Come si strumenta il sistema perché quei segnali esistano, log, tracce, obiettivi di servizio, lo abbiamo trattato nell’articolo sull’osservabilità degli agenti AI in produzione.

I cinque gruppi di segnali che una dashboard di agente deve mostrare

Una dashboard utile non è una lista di metriche: è un ordinamento. La tassonomia più chiara in circolazione, quella di groundcover, raggruppa i segnali in cinque famiglie, e una dashboard a cui manca uno dei cinque gruppi ha un punto cieco strutturale, non una lacuna cosmetica.

Le cinque famiglie di metriche di un agente AI in produzione

Token e uso del modello: token in ingresso e in uscita per ogni chiamata, modello e fornitore usati, distribuzione della spesa tra agenti e percorsi. Latenza ed errori: tempo di risposta complessivo e per singolo passo, chiamata al modello, invocazione di strumenti, recupero documenti, con conteggio e classificazione degli errori. Percorso e passi dell’agente: quanti passi ha fatto, quali nodi ha attraversato, quanti tentativi e cicli ha ripetuto, quale ramo di policy ha scelto. Uso degli strumenti: frequenza di chiamata, durata, tasso di fallimento e qualità degli argomenti passati a ciascuno strumento. Valutazione e qualità dell’output: punteggi strutturati su riuscita del compito, correttezza, aderenza ai dati recuperati e rispetto delle policy.

Come si traducono in riquadri concreti

Nella pratica dei prodotti la traduzione è abbastanza standardizzata. La dashboard di Splunk AppDynamics per il monitoraggio degli agenti mostra token totali, in ingresso e in uscita, richieste totali e riuscite, latenza media delle chiamate al modello, tempo al primo token, andamento temporale dei token per individuare i picchi e una classifica dei primi dieci modelli per volume di invocazione con i rispettivi tassi di successo e fallimento. Aggiunge inoltre i segnali del database vettoriale: numero medio di documenti recuperati, punteggi di similarità e latenza dell’operazione di ricerca. Quest’ultimo blocco è quello che manca più spesso, ed è quello che spiega la maggior parte delle risposte sbagliate quando l’agente lavora su documenti aziendali, il meccanismo è quello descritto nella guida al RAG, e la trappola dei risultati «vicini ma sbagliati» è raccontata nel pezzo sulla similarità coseno.

Latenza: quale numero guardare davvero (e perché la media mente)

La latenza di un agente è la metrica più facile da mostrare e la più facile da leggere male. Il primo errore è guardare la media: in un sistema dove alcune esecuzioni fanno due passi e altre dodici, la media descrive un utente che non esiste. Sentry raccomanda di tracciare p50 e p95 separatamente per agente e per modello; TrueFoundry va oltre e chiede la terna P50, P90 e P99 su due grandezze distinte, il tempo al primo token e il ritardo fra un token e l’altro.

La distinzione conta perché descrive esperienze diverse. Il tempo al primo token è la percezione di reattività: sotto quella soglia l’utente pensa che il sistema sia bloccato. Il ritardo fra token è la fluidità della risposta mentre scorre. Il tempo totale dell’esecuzione è invece la grandezza che conta quando l’agente lavora in autonomia, senza nessuno che guarda lo schermo.

I due errori di lettura della latenza di un agente AI

Il secondo errore è attribuire la lentezza al modello per abitudine. TrueFoundry insiste su un punto operativo: la latenza degli strumenti va misurata come voce separata dal tempo di ragionamento. Se l’agente interroga un CRM lento, il numero da aggredire è quello del CRM, non il prompt. Senza la scomposizione, ogni riunione sulle prestazioni finisce a discutere del modello sbagliato.

Il terzo è più sottile e vale come regola di lettura: sempre TrueFoundry osserva che un picco di latenza va correlato alla profondità del ragionamento, non trattato di per sé come un guasto. Un’esecuzione che ha impiegato il doppio perché ha fatto il doppio dei passi su una richiesta complessa non è un incidente. Un’esecuzione che ha impiegato il doppio facendo gli stessi passi lo è. È la differenza fra un allarme che qualcuno guarda e un allarme che dopo due settimane viene silenziato.

Tasso di escalation: il riquadro che dice se l’agente sta lavorando

Se un solo numero dovesse finire in cima alla dashboard di un agente rivolto ai clienti, sarebbe la quota di conversazioni chiuse senza intervento umano, e il suo complemento, il tasso di escalation. Teneo definisce il contenimento come la percentuale di interazioni risolte per intero dall’automazione, e distingue esplicitamente la risoluzione dalla deviazione, cioè dal semplice dirottare il cliente su un altro canale senza risolvergli il problema. La stessa coppia contenimento/escalation è il fulcro anche delle dashboard di monitoraggio degli agenti AI nel customer service di Zendesk.

Benchmark di contenimento e il rischio di gonfiare il numero

I benchmark riportati da Teneo aiutano a capire dove ci si trova. Un IVR tradizionale a menu contiene fra il 5% e il 10% delle chiamate; un IVR conversazionale fra il 10% e il 15%; gli agenti vocali di livello chatbot fra il 10% e il 20%; le implementazioni agentiche enterprise sono collocate fra il 60% e il 90%. La forbice è enorme e dipende dal dominio: in un contesto giuridicamente denso, un valore molto più basso può essere un ottimo risultato.

Il rischio è ovvio ed è il motivo per cui questo riquadro non va mai guardato da solo: un tasso di contenimento si può gonfiare peggiorando il servizio, rendendo difficile arrivare all’operatore. Teneo indica i segnali che smascherano la manovra: contatti ripetuti dallo stesso cliente entro sette giorni, CSAT in calo sulle interazioni automatiche, escalation concentrate su tipologie specifiche di richiesta, sentiment negativo nei sondaggi. La raccomandazione è netta: misurare la qualità della risoluzione, non solo la percentuale di contenimento.

Sulla dashboard questo si traduce in tre riquadri da leggere insieme, contenimento, contatti ripetuti a sette giorni, soddisfazione sulle sole conversazioni automatiche, più la scomposizione delle escalation per motivo. Quest’ultima è la miniera: dice esattamente dove l’agente va addestrato o dove va messo un limite. Il collegamento con gli indicatori economici è trattato negli 8 KPI per misurare il ROI di un agente AI.

Accuratezza: come si misura la qualità delle risposte in esercizio

«Accuratezza» è la parola che compare in ogni capitolato e quasi mai in una dashboard, perché nessuno sa quale numero metterci. La risposta operativa del settore è la valutazione automatica continua: si fanno giudicare le risposte da valutatori specializzati e si portano i punteggi sul cruscotto come qualsiasi altra metrica.

Microsoft, nel proprio decalogo sull’osservabilità degli agenti, elenca i valutatori che considera fondamentali e che vale la pena adottare come vocabolario comune anche fuori da Azure: risoluzione dell’intento, quanto accuratamente l’agente identifica ciò che l’utente vuole, aderenza al compito, accuratezza nella chiamata degli strumenti e completezza della risposta, affiancati da controlli di sicurezza sui contenuti. L’accuratezza nella scelta dello strumento è il valutatore più sottovalutato: è lì che si annida il caso descritto da Sentry, l’agente che risponde con sicurezza usando la fonte sbagliata.

Valutazione offline, valutazione online e giudizio umano

LangChain aggiunge la distinzione fra valutazioni offline, eseguite prima del rilascio su un insieme di casi noti, e valutazioni online sul traffico reale, che intercettano i fallimenti dipendenti dal contesto, quelli che nessuna suite di test avrebbe prodotto. Le due cose non si sostituiscono: la prima protegge dalle regressioni, la seconda dalla realtà.

Resta il giudizio umano, che non è un ripiego. LangChain descrive code di annotazione in cui revisori di dominio, clinici, giuristi, analisti, product manager, ispezionano campioni di risposte e reimmettono il loro giudizio nel sistema di valutazione. È lo stesso principio della supervisione umana in produzione: un campione settimanale letto da qualcuno che conosce il mestiere vale più di dieci riquadri verdi.

Costo per interazione: il riquadro che salta quando nessuno lo guarda

Il costo è la metrica dove le sorprese sono più brutali, perché cresce senza rompere nulla. Sentry riporta un confronto che merita di essere letto due volte: nello stesso periodo, un modello di fascia alta genera 10.800 dollari di spesa settimanale mentre un modello leggero gestisce un volume equivalente con 645 dollari. Non è un argomento per usare sempre il modello economico, è un argomento per sapere, riquadro alla mano, quanto stai pagando quella differenza e su quali richieste la stai pagando.

I quattro riquadri di costo di un agente AI in produzione

I riquadri minimi sono quattro. Token in ingresso e in uscita separati, perché hanno prezzi diversi e cause diverse: i primi crescono con il contesto che carichi, i secondi con la verbosità delle risposte. Costo per esecuzione, con la sua distribuzione e non solo la media, per intercettare la coda di esecuzioni patologiche, ed è qui che il rapporto di quaranta a uno fra i 0,05 e i 2,00 dollari citati da TrueFoundry smette di essere un aneddoto e diventa la forma della curva da sorvegliare. Ripartizione per modello e per percorso, che è l’unica base seria per decidere dove instradare il traffico. Tasso di riuso della cache, citato da Sentry fra le metriche di efficienza: è la leva che riduce la spesa senza toccare la qualità.

Microsoft, nella documentazione di Application Insights, mostra come si usa questo blocco: si ordinano le tracce per numero di token consumati, si apre l’esecuzione più cara e si guarda cosa è successo. L’esempio riportato è didattico, un contesto del prompt molto ampio combinato con un modello costoso fa esplodere token e costo, e descrive esattamente il mestiere: dal riquadro aggregato alla singola traccia, e dalla traccia alla modifica.

Una precisazione di perimetro: questo è costo operativo, non ritorno dell’investimento. Il costo per interazione dice quanto spendi; se quella spesa valga la pena è un’altra domanda, affrontata in ROI di un agente AI e, sul lato dei prezzi dei modelli, nell’analisi sui costi delle API.

Drift: il guasto che non fa scattare nessun allarme

Il drift è il motivo per cui un agente che funzionava a marzo risponde peggio a settembre senza che nessuno abbia rilasciato niente di rotto. groundcover ne dà la definizione più utile: modifiche ai prompt, aggiornamenti degli strumenti, cambi di modello e variazioni nei dati spostano il comportamento senza passare da un rilascio formale. Non c’è un errore da cercare nei log, perché non c’è un errore: c’è un sistema che si è spostato.

Come si presidia il drift di un agente AI sulla dashboard

Il presidio è di conseguenza comparativo, non a soglia. Si tengono le stesse metriche, punteggi di valutazione, costo, latenza, distribuzione dei percorsi, e si confronta il periodo corrente con un riferimento stabile, facendo scattare l’allarme sullo scostamento. Sulla dashboard significa che ogni riquadro importante ha bisogno di un termine di paragone accanto al valore assoluto. Un numero senza il suo confronto non è un indicatore, è una decorazione.

Le occasioni di drift più comuni sono prevedibili e vanno annotate sui grafici: il giorno in cui è cambiato il modello, quello in cui è stato riscritto un prompt, quello in cui è stata caricata una nuova versione della base documentale. Senza queste annotazioni, ogni variazione diventa una discussione a memoria.

C’è anche un motivo normativo per conservare tutto questo. L’articolo 12 dell’AI Act impone ai sistemi ad alto rischio la registrazione automatica degli eventi per tutta la durata di vita del sistema, in funzione del rilevamento dei rischi, del monitoraggio successivo all’immissione sul mercato e della sorveglianza da parte di chi lo utilizza, con applicazione dal 2 agosto 2026. Se il tuo agente ricade in quel perimetro, la telemetria smette di essere buona pratica: diventa un obbligo documentale, come spiegato nella guida alla governance degli agenti AI e, sul lato normativo, in cosa prevede l’AI Act e chi deve adeguarsi.

Chi guarda la dashboard: perché in MIMIR il presidio fa parte del servizio

Una dashboard configurata bene e non letta da nessuno è un costo, non un controllo. È il punto in cui si arenano molti progetti: gli strumenti ci sono, i grafici pure, ma nessuno in azienda ha il mandato di aprirli il lunedì mattina e di decidere qualcosa. È una delle ragioni per cui i progetti restano bloccati dopo il proof of concept.

Il ritmo di presidio: continuo, settimanale, mensile

Il ritmo che funziona è a tre velocità. In continuo, solo gli allarmi che richiedono un intervento immediato: agente fermo, tasso di errore degli strumenti fuori scala, spesa oraria oltre il tetto. Ogni settimana, la lettura vera: escalation per motivo, punteggi di valutazione confrontati con la settimana prima, costo per interazione, campione di conversazioni lette da un umano. Ogni mese o a ogni cambiamento rilevante, la revisione del comportamento complessivo e la ritaratura delle soglie. Le soglie iniziali, va detto senza giri di parole, sono quasi sempre sbagliate: i benchmark di mercato, quelli di contenimento visti sopra, i riferimenti di costo e di percentile sulla latenza, servono a capire in quale ordine di grandezza ti trovi, non a fissare il valore d’allarme. Quello si tara sul comportamento osservato nelle prime settimane.

Questo è precisamente il punto in cui in MIMIR non ci limitiamo a consegnare un agente. Configuriamo le dashboard sui processi reali del cliente, definiamo con lui quali numeri fanno scattare quale decisione e restiamo a presidiarli: è la parte di servizio che accompagna il prodotto, dall’onboarding dei primi trenta giorni alla manutenzione successiva al rilascio. Un agente in produzione non è un progetto che finisce, è un sistema che va condotto.

Se stai valutando un agente AI per la tua azienda, o ne hai già uno in esercizio e non sai leggere i numeri che produce, puoi parlarne con noi: partiamo dai tuoi processi e da cosa deve mostrare la tua dashboard, prima ancora che dalla tecnologia. È la parte meno appariscente del lavoro ed è quella che decide se l’agente resterà acceso l’anno prossimo.

Fonti:

• Sentry — AI agent observability: a developer’s guide to agent monitoring
• TrueFoundry — AI agent observability tools
• groundcover — AI agent observability
• Microsoft Learn — Vista Dettagli agente in Application Insights (Azure Monitor)
• Microsoft Azure Blog — Top 5 agent observability best practices for reliable AI
• Splunk AppDynamics — AI agent monitoring
• LangChain — LLM observability tools
• Teneo — Containment rate: benchmark dei call centre e come migliorarlo (2026)
• IBM Think — AI agent observability
• OpenTelemetry — Semantic conventions for generative AI
• AI Act — Articolo 12, conservazione delle registrazioni
• Zendesk — Usare la dashboard per monitorare e gestire gli agenti AI