L’observability degli agenti AI è la pratica di tracciare passo per passo che cosa fa un agente AI, così che gli ingegneri vedano latenza, costi in token, errori degli strumenti ed esecuzioni fallite. Per chi guida il servizio clienti è solo metà del lavoro. L’altra metà è il monitoraggio della qualità: verificare che l’agente abbia dato al cliente la risposta giusta, rispettato le policy, fatto escalation quando doveva e fatto davvero ciò che ha detto di aver fatto.
In breve
- L’observability tecnica risponde alla domanda “l’agente funziona?”. Il monitoraggio della qualità risponde a “l’agente ha ragione?”. Gli strumenti di observability sono pensati soprattutto per la prima.
- Gli errori più costosi nel servizio clienti sembrano successi nei log: risposte sbagliate su conversazioni risolte, escalation mancate, violazioni di policy e azioni dichiarate ma mai eseguite.
- Una dashboard di monitoraggio utile dà a ogni metrica una definizione, una fonte dati, una soglia di allerta e un unico responsabile. La specifica qui sotto ha 13 righe da copiare.
- Fissi le soglie a partire da una sua baseline di 4 settimane e legga ogni metrica accanto a un registro delle modifiche, così la deriva dopo un aggiornamento di prompt o knowledge base emerge in pochi giorni.
- Una revisione settimanale di 45 minuti che si chiude con correzioni assegnate a una persona evita che la dashboard diventi carta da parati.
Che cos’è l’observability degli agenti AI?
L’observability degli agenti AI consiste nel registrare ogni esecuzione di un agente AI come una traccia: il messaggio del cliente, ogni richiesta al modello, ogni richiesta a uno strumento o a un’API, i dati recuperati e la risposta, con tempi, numero di token ed errori. Gli ingegneri usano queste tracce per correggere i guasti, tenere sotto controllo i costi e mantenere l’agente veloce e disponibile.
Il vocabolario viene dalla gestione operativa del software. Il libro di Google sulla Site Reliability Engineering indica i quattro segnali d’oro del monitoraggio: latenza, traffico, errori e saturazione. L’observability degli agenti AI aggiunge ciò che è specifico dei modelli linguistici: prompt, versioni del modello, uso dei token, recupero delle informazioni e uso degli strumenti. Il settore sta convergendo su un formato dati comune, le convenzioni semantiche OpenTelemetry per l’AI generativa.
Una traccia (trace) è il registro di un’esecuzione dell’agente, e ogni passaggio al suo interno (una richiesta al modello, una ricerca nella knowledge base, la consultazione di un ordine) è uno span. La domanda di questa visibilità è reale: in uno studio del 2025 dell’IBM Institute for Business Value, circa metà dei dirigenti ha indicato “la mancanza di visibilità sui processi decisionali degli agenti come un ostacolo significativo all’implementazione” (IBM).
Qual è la differenza tra observability e monitoraggio della qualità di un agente AI?
L’observability tecnica le dice se l’agente AI ha funzionato: ha risposto in fretta, senza errori, a un costo accettabile. Il monitoraggio della qualità le dice se l’agente aveva ragione: risposta corretta, azione consentita, escalation giusta, cliente in una situazione migliore. Una conversazione può essere perfetta nella traccia e sbagliata per il cliente, e la traccia non lo mostrerà.
LangChain, che sviluppa la piattaforma di observability LangSmith, lo dice chiaramente: gli strumenti di monitoraggio tradizionali “si concentrano su metriche come latenza, traffico, errori e saturazione”, mentre “l’observability degli agenti richiede di monitorare gli input e gli output stessi, non solo le metriche di sistema che li circondano” (LangChain, febbraio 2026).
L’esposizione legale sta dal lato della qualità. Nel caso Moffatt v. Air Canada (2024 BCCRT 149), il chatbot del sito della compagnia aerea disse a un cliente che poteva richiedere una tariffa per lutto in modo retroattivo, cosa che la policy non consentiva. Il tribunale ha condannato la compagnia a pagare e ha scritto che “dovrebbe essere ovvio per Air Canada che è responsabile di tutte le informazioni presenti sul suo sito” (decisione del tribunale). Nessun grafico della latenza avrebbe segnalato quella risposta.
| Observability tecnica | Monitoraggio della qualità | |
|---|---|---|
| Domanda | L’agente funziona, è veloce ed economico? | Dà risposte giuste e compie le azioni giuste? |
| Unità di dati | Traccia e span | Conversazione, valutata con una scheda di valutazione |
| Metriche tipiche | Latenza, tasso di errore, errori degli strumenti, token, costo | Accuratezza, policy, escalation, passaggio all’operatore, sentiment, ricontatto |
| Che cosa non vede | Una risposta sbagliata data con sicurezza che ha chiuso il ticket | Un’integrazione guasta, a meno che non emerga nella conversazione |
| Responsabile abituale | AI engineering, team di piattaforma | Support operations, responsabile QA, responsabile dell’agente AI |
I due livelli si incontrano a metà strada: un loop compare nella traccia come una serie di passaggi ripetuti e nella conversazione come un cliente frustrato. Valutare le conversazioni stesse rispetto a uno standard scritto è ciò che i team di assistenza chiamano controllo qualità degli agenti AI.
Che cosa deve monitorare in un agente AI chi guida il servizio clienti?
Chi guida il servizio clienti deve monitorare sette cose: risposte sbagliate ma contate come risolte, escalation e passaggi all’operatore falliti, violazioni di policy, azioni dichiarate ma non eseguite, loop, cali di sentiment e deriva dopo ogni modifica. Ognuna supera un controllo tecnico di salute del sistema, ed è per questo che ciascuna ha bisogno di una misura propria.
- Sbagliata ma risolta. Il cliente ha smesso di rispondere, quindi l’helpdesk ha contato una risoluzione, ma la risposta era sbagliata. È il cuore degli errori silenziosi che la sua dashboard conta come successi, e le allucinazioni ne sono una delle cause. Lo rivela solo la valutazione del contenuto delle conversazioni risolte.
- Escalation e passaggi all’operatore falliti. Un’escalation mancata è un caso che l’agente ha tenuto quando le sue regole dicono che dovrebbe prenderlo una persona. Un passaggio fallito è un’escalation fatta male: nessun contesto trasmesso, il cliente ripete tutto, oppure nessuno prende in carico il caso in tempo.
- Violazioni di policy. L’agente ha promesso un rimborso, l’esonero da una commissione o un’eccezione che la sua policy non consente. Una sola promessa del genere può bastare perché il management sospenda ogni ulteriore estensione dell’AI finché la compliance non l’ha esaminata.
- Dichiarata ma non eseguita. L’agente dice “il suo rimborso è in arrivo”, ma nel backend non c’è alcun rimborso. La richiesta allo strumento è fallita in silenzio, oppure l’agente ha descritto un’azione che non ha mai tentato. Per intercettarla bisogna riconciliare le trascrizioni con il sistema di riferimento.
- Loop. L’agente fa la stessa domanda tre volte o rimbalza il cliente tra chat e telefono. La traccia mostra un numero di turni elevato; il cliente si sente bloccato e ritorna, oppure disdice.
- Cali di sentiment. Il cliente finisce più arrabbiato di come ha iniziato, anche su un caso tecnicamente risolto. Un aumento su un argomento di solito indica una risposta che l’agente gestisce male.
- Deriva dopo le modifiche. La qualità si sposta quando viene rilasciato qualcosa: una versione del modello, una modifica al prompt, un articolo riscritto, una nuova policy o integrazione. Se legge ogni metrica accanto a un registro delle modifiche, la deriva ha una data e una causa.
Se valga la pena far funzionare l’agente (risoluzione, contenimento, costo per risoluzione, CSAT) è una questione diversa, trattata in come misurare le prestazioni degli agenti AI. Il monitoraggio è il livello sottostante: intercettare ciò che è andato storto questa settimana, finché il problema è ancora piccolo.
La specifica della dashboard di monitoraggio degli agenti AI
Una dashboard di monitoraggio funziona solo se ogni metrica ha una definizione precisa, una fonte dati indicata per nome, una soglia di allerta e un unico responsabile. Senza questi quattro campi un grafico diventa rosso e nessuno si muove. Copi la specifica qui sotto e sostituisca le soglie di esempio, che sono illustrazioni e non benchmark, con i numeri della sua baseline.
| Metrica | Definizione | Fonte dati | Soglia di allerta (esempio) | Responsabile |
|---|---|---|---|---|
| Tasso di sbagliate ma risolte | Quota delle conversazioni risolte dall’AI che non superano il criterio di accuratezza | Valutazione QA delle conversazioni risolte | 0,5 punti sopra la baseline di 4 settimane, o sopra il 3% | Responsabile dell’agente AI |
| Violazioni di policy | Conversazioni in cui l’agente ha promesso o concesso qualcosa fuori dalla policy scritta | Criterio di policy della scheda di valutazione | Qualsiasi singolo caso su un argomento della lista rossa, in giornata; altrimenti sopra lo 0,5% settimanale | Support operations con la compliance |
| Tasso di escalation mancate | Conversazioni che le sue regole assegnano a una persona e che l’agente ha tenuto | Criterio di escalation della scheda di valutazione | Sopra l’1% settimanale, o qualsiasi caso su un trigger della lista rossa | Responsabile dell’agente AI |
| Tasso di passaggi falliti | Escalation senza contesto trasmesso, con il cliente che ripete, o senza presa in carico entro l’obiettivo | Eventi di passaggio dell’helpdesk più scheda di valutazione | Sopra il 10% dei passaggi, o presa in carico oltre il livello di servizio per 2 giorni | Responsabile support operations |
| Dichiarate ma non eseguite | L’agente dichiara un’azione (rimborso, disdetta, modifica) senza un record corrispondente nel backend | Dichiarazioni nelle trascrizioni riconciliate con i log di ordini, fatturazione o account | Qualsiasi caso sui pagamenti; altrimenti sopra lo 0,2% delle conversazioni con azioni | AI engineering con support operations |
| Tasso di loop | Stessa domanda o risposta ripetuta 3 o più volte, o un rimbalzo tra canali | Tracce e storico dei canali nell’helpdesk | Numero di turni sopra il 95° percentile della baseline su più del 2% delle conversazioni | Responsabile dell’agente AI |
| Tasso di ricontatto | Stesso cliente, stesso problema, di ritorno entro 72 ore da una risoluzione dell’AI | Storico contatti dell’helpdesk | Aumento relativo del 25% su un argomento, settimana su settimana | Responsabile support operations |
| Peggioramento del sentiment | Quota delle conversazioni in cui il sentiment finisce più basso di come è iniziato | Valutazione del sentiment | Aumento di 5 punti su un argomento, settimana su settimana | Responsabile CX |
| Punteggio qualità per argomento | Risultato medio della scheda di valutazione per motivo di contatto | Valutazione QA | Qualsiasi argomento 5 punti sotto la sua baseline | Responsabile QA |
| Delta dopo una modifica | Ogni metrica nei 7 giorni dopo una modifica rispetto ai 7 giorni prima | Registro delle modifiche più le righe sopra | Qualsiasi soglia superata entro 7 giorni da una modifica fa scattare una valutazione del rollback | Responsabile della modifica |
| Copertura della valutazione | Quota delle conversazioni gestite dall’AI effettivamente valutate | Strumento QA rispetto ai volumi dell’helpdesk | Sotto il 95% per un giorno | QA operations |
| Concordanza dei valutatori | Concordanza tra punteggi automatici e revisori umani su un campione settimanale | Campione di calibrazione | Sotto il livello concordato al go-live | Responsabile QA |
| Salute tecnica e costo | Tasso di errore, timeout, latenza p95, errori degli strumenti, costo per conversazione | Tracce, APM e fatturazione | I livelli di servizio e il budget del suo team di ingegneria | AI engineering |
Tre regole la mantengono onesta. Ogni metrica di qualità rimanda alle conversazioni che la generano, così una cella rossa apre esempi reali invece di un dibattito. Ogni metrica è suddivisa per argomento, perché una media nasconde l’unico articolo sbagliato. E le prime due righe contano più dell’ultima: un agente veloce ed economico che dà risposte sbagliate non è in salute.
La maggior parte delle righe dipende da una scheda di valutazione scritta. Se non ne ha una, inizi dalla scorecard per agenti AI e dai metodi della guida alla valutazione degli agenti AI.
Come si fissano le soglie di allerta nel monitoraggio degli agenti AI?
Fissi le soglie di allerta a partire dalla sua baseline. Valuti almeno 4 settimane di conversazioni, annoti l’intervallo settimanale normale di ogni metrica, poi faccia scattare l’allerta quando la metrica esce da quell’intervallo o supera un tetto assoluto, a seconda di quale evento arriva prima. Gli eventi della lista rossa, come errori sui pagamenti o promesse con valore legale, fanno scattare l’allerta anche su un solo caso, qualunque sia il tasso.
L’indicazione della SRE di Google è che “ogni allerta deve portare a un’azione”, quindi usi tre livelli:
- In giornata: una violazione di policy della lista rossa, un pagamento dichiarato ma non eseguito, copertura sotto il 95%, un disservizio.
- Entro 2 giorni: una soglia di tasso superata su un argomento con molto traffico, o qualsiasi soglia superata entro 7 giorni da una modifica.
- Revisione settimanale: tendenze più lente, argomenti con pochi volumi, sentiment e ricontatti.
Esempio pratico: perché la copertura completa cambia ciò che si vede
Un’illustrazione con numeri tondi, calcolata per questo articolo. Un agente AI gestisce 50.000 conversazioni a settimana e ne risolve 35.000 senza una persona. La baseline delle sbagliate ma risolte è il 2,0%, circa 700 risposte sbagliate a settimana. Il lunedì viene riscritto un articolo sui resi, e la settimana successiva il tasso è il 2,8%: circa 980 risposte sbagliate, 280 più del solito.
| Valutare un campione del 2% | Valutare ogni conversazione risolta | |
|---|---|---|
| Conversazioni valutate | 700 | 35.000 |
| Risposte sbagliate alla baseline (2,0%) | 14 | 700 |
| Risposte sbagliate dopo la modifica (2,8%) | circa 20 | 980 |
| Rumore settimanale normale (circa la radice quadrata del conteggio) | circa 4 | circa 26 |
| La modifica è visibile? | No: 6 casi in più, dentro il rumore | Sì: 280 casi in più, oltre 10 volte il rumore |
Le violazioni di policy sono più rare. Allo 0,1%, sono circa 35 a settimana su 35.000 conversazioni risolte. Un campione del 2% ne contiene in media 0,7, quindi la probabilità che non ne contenga nessuna è circa il 50%. In metà delle settimane, una revisione a campione riporta zero violazioni mentre 35 clienti si sono sentiti dire qualcosa che la sua policy non consente.
Come si svolge una revisione settimanale della qualità di un agente AI?
Una revisione settimanale della qualità di un agente AI è una riunione di 45 minuti in cui il responsabile dell’agente AI, il responsabile QA, le support operations e il responsabile della knowledge base esaminano allerte, gruppi di errori e modifiche della settimana precedente, e ne escono con correzioni assegnate. La compliance partecipa quando in lista c’è una violazione di policy. Il risultato è una lista di correzioni e un registro delle modifiche aggiornato.
- Allerte dall’ultima settimana (5 minuti): che cosa è scattato, che cosa è stato fatto, che cosa resta aperto.
- I 3 principali gruppi di errori (15 minuti): 3 conversazioni reali per ciascuno, lette a schermo, non riassunte.
- Modifiche rilasciate (10 minuti): ogni modifica del registro con i numeri dei 7 giorni prima e dopo.
- Decidere le correzioni (10 minuti): un responsabile e una data per ogni correzione, che sia una modifica alla knowledge base, un guardrail, una regola di escalation o un rollback.
- Verificare le correzioni della settimana scorsa (5 minuti): la metrica a cui mirava ogni correzione si è mossa?
Faccia passare le correzioni dai controlli pre-lancio prima di rilasciarle; il test degli agenti AI spiega i set di test che impediscono a una correzione su un argomento di romperne un altro. Chi approva le modifiche della lista rossa, e chi può disattivare un argomento, va definito nel suo modello di governance degli agenti AI.
Quali tipi di strumenti di monitoraggio per agenti AI esistono?
Gli strumenti di monitoraggio per agenti AI rientrano in cinque categorie: strumenti di tracing per sviluppatori, suite di application performance monitoring, analytics della piattaforma dell’agente, strumenti di QA delle conversazioni che valutano le conversazioni risolte e strumenti di sicurezza per l’AI. Ognuno risponde a una domanda diversa, ed è per questo che la maggior parte dei team di assistenza con un agente AI in produzione finisce per usarne due o tre.
| Categoria | Domanda a cui risponde | Utente tipico | Esempi | Dove si ferma |
|---|---|---|---|---|
| Tracing per sviluppatori | Perché questa esecuzione è fallita, e quanto è costata? | Ingegneri AI | LangSmith, Langfuse, Arize Phoenix | Pensato per correggere le esecuzioni, non per giudicare le risposte rispetto alla sua policy |
| Application performance monitoring | Il servizio è attivo e veloce? | Team di piattaforma | Datadog, IBM Instana, Splunk | Poco sulla correttezza delle risposte |
| Analytics della piattaforma dell’agente | Come va questo agente secondo le sue stesse misure? | Responsabile dell’agente AI | Integrati in Fin, Decagon, Agentforce, agenti AI di Zendesk | Una sola piattaforma, con le sue definizioni |
| QA delle conversazioni | La risposta era giusta, consentita e con l’escalation corretta? | Responsabile QA, support operations | Strumenti QA che valutano le conversazioni con la sua scheda di valutazione | Lavora dopo la fine della conversazione; non è un debugger delle esecuzioni |
| Sicurezza per l’AI | L’agente sta facendo qualcosa di pericoloso o non autorizzato? | Team di sicurezza | Piattaforme di sicurezza per l’AI | Accessi e abusi, non la qualità del servizio |
Scelga in base alla domanda a cui oggi non sa rispondere: se gli ingegneri non riescono a capire perché un’esecuzione è fallita, inizi dal tracing; se nessuno sa dire quante conversazioni risolte erano sbagliate la settimana scorsa, inizi dal QA delle conversazioni.
Quando questo livello di monitoraggio degli agenti AI non fa per lei?
Un monitoraggio completo della qualità non vale lo sforzo finché l’agente AI gestisce qualche centinaio di conversazioni a settimana su argomenti a basso rischio. Con questi volumi basta una persona che legga le conversazioni ogni settimana, e il tempo è speso meglio sulla knowledge base.
È anche il primo passo sbagliato se l’agente non è ancora in produzione (le servono i test pre-lancio) o se non ha uno standard scritto di che cosa sia una buona risposta: uno strumento non può dare l’allerta su una regola che nessuno ha messo per iscritto.
Come iniziare il monitoraggio degli agenti AI questa settimana
Può iniziare il monitoraggio degli agenti AI questa settimana senza acquistare nulla: scriva una lista rossa, avvii un registro delle modifiche, legga le conversazioni risolte della settimana scorsa per una prima baseline e nomini un responsabile per ogni metrica. Gli strumenti possono arrivare quando saprà a quali domande non riesce a rispondere.
- Scriva la lista rossa: da 5 a 10 argomenti come rimborsi, disdette, questioni legali, sicurezza e clienti vulnerabili.
- Avvii un registro delle modifiche: data, che cosa è cambiato, chi l’ha cambiato. Lo compili anche per l’ultimo mese.
- Legga 200 conversazioni risolte dall’AI della settimana scorsa confrontandole con la sua policy, e conti le sbagliate ma risolte, le escalation mancate e le violazioni.
- Copi la specifica della dashboard, elimini le righe per cui non ha ancora una fonte e compili ogni cella del responsabile.
- Fissi la revisione settimanale nello stesso orario ogni settimana.
Se le sue conversazioni sono in Zendesk o Salesforce e vuole il livello della qualità senza leggerle a mano, è la parte di cui si occupa Kaizo. AutoPilot valuta ogni conversazione con la sua scheda di valutazione nel momento in cui si risolve e collega ogni punteggio alle prove, e lei lo verifica sulle sue valutazioni passate prima che entri in funzione. L’analisi della causa radice riconduce un calo di qualità alle conversazioni che l’hanno prodotto. Non sostituisce gli strumenti di tracing dei suoi ingegneri; veda il controllo qualità degli agenti AI per capire come si inserisce.
Lo veda sulle conversazioni del suo agente AI. Prenoti una demo.
Domande frequenti
Gli agenti AI si possono monitorare?
Sì, su due livelli. Le esecuzioni di un agente si possono tracciare per errori, velocità e costo, e le sue conversazioni si possono valutare per accuratezza, policy ed escalation. I team di assistenza hanno bisogno di entrambi, perché un’esecuzione tecnicamente sana può comunque dare a un cliente una risposta sbagliata.
Quali sono i migliori strumenti per monitorare l’AI agentica?
Non esiste un unico strumento migliore, perché ogni categoria risponde a una domanda diversa: gli strumenti di tracing correggono le esecuzioni, le suite di performance controllano la disponibilità, gli analytics di piattaforma riferiscono su un solo agente e gli strumenti di QA delle conversazioni verificano se le risposte erano giuste e consentite. Inizi dalla domanda a cui oggi non sa rispondere.
Che cos’è una traccia di un agente AI?
Una traccia è il registro completo di un’esecuzione di un agente AI, dal messaggio del cliente alla risposta. Ogni passaggio al suo interno, come una richiesta al modello o la consultazione di un ordine, è uno span con tempi, input, output ed errori propri. Una traccia mostra come l’agente è arrivato a una risposta, non se la risposta era corretta.
Chi deve essere responsabile del monitoraggio degli agenti AI in un team di assistenza?
Divida la responsabilità per livello. L’AI engineering è responsabile della salute tecnica e del costo. Un responsabile dell’agente AI indicato per nome, di solito nelle support operations, risponde della qualità delle risposte, delle escalation e dei loop. Il responsabile QA gestisce la scheda di valutazione e la concordanza dei valutatori. Ogni metrica della dashboard deve avere esattamente un nome.
Il tasso di contenimento basta per monitorare un agente AI?
No. Il contenimento conta come successo ogni conversazione che non è arrivata a una persona, comprese quelle in cui l’agente sbagliava e il cliente ha rinunciato. Lo legga accanto al tasso di sbagliate ma risolte, ai ricontatti entro 72 ore e al peggioramento del sentiment. Veda il QA delle conversazioni gestite dall’AI (in inglese) per sapere che cosa controllare per primo.






