Un agente AI che passa il collaudo non è un agente AI che funziona. La differenza si vede dopo, quando il traffico è reale, i casi limite arrivano tutti insieme e nessuno sa dire se l’agente sta ancora facendo il suo lavoro o se ha smesso settimane fa. È qui che entra in gioco l’osservabilità agenti AI produzione: non un dashboard in più, ma l’unico modo per sapere se il sistema che avete messo online sta ancora producendo il valore per cui l’avete pagato.
Il problema, per una PMI italiana, non è teorico. È che dopo il go-live la telemetria esiste ma nessuno la guarda, e nel giro di due mesi la visibilità sull’agente si azzera. Questo articolo mette in fila cosa misurare, a quali soglie, e come definire SLO che abbiano senso per un sistema non deterministico.
In questo articolo scoprirai:
- Osservabilità degli agenti AI in produzione: perché non è APM con un altro nome
- Le metriche operative minime: latenza per step, tool call, costi
- Deriva del prompt e della qualità: il segnale che i dashboard verdi nascondono
- Escalation umane: la metrica più onesta che avete
- Come definire SLO realistici per un agente AI
- Come strumentare l’osservabilità senza un team SRE
- Perché la visibilità si perde dopo 60 giorni
Osservabilità degli agenti AI in produzione: perché non è APM con un altro nome
Il monitoraggio tradizionale presuppone determinismo: stesso input, stesso output, e un errore che si manifesta come codice HTTP diverso da 200. Con un agente questo presupposto salta. Come nota OneUptime nella sua analisi sul monitoraggio degli agenti in produzione, lo stesso input può produrre output radicalmente diversi, e una risposta perfettamente formattata ma completamente inventata restituisce comunque un 200: nessun alert, nessun errore, dashboard verdi mentre l’agente allucina.
Il monitoraggio classico di CPU, memoria e latenza è inefficace nel rilevare anomalie semantiche come loop decisionali infiniti, tool poisoning o contesti recuperati sbagliati: sono segnali che vivono su un asse diverso rispetto alla telemetria infrastrutturale.
C’è anche un problema di volume. Un agente genera da 10 a 50 volte più telemetria di un’applicazione tradizionale: ogni step di ragionamento, ogni chiamata a tool, ogni retrieval produce uno span. Senza una strategia di campionamento e aggregazione, la mole di dati diventa essa stessa un costo. Chi sta valutando il passaggio da pilot a produzione di un agente AI in azienda dovrebbe mettere questo capitolo nel budget, non trattarlo come un dettaglio infrastrutturale.
Le metriche operative minime: latenza per step, tool call, costi
Prima di parlare di qualità, servono le metriche che si misurano senza modelli giudice. Sono quattro e coprono il 70% degli incidenti reali.
Latenza per step, non latenza totale
La latenza end-to-end di una conversazione dice poco: un agente che impiega 12 secondi può essere sano (tre tool call legittime) o malato (sette iterazioni di ragionamento inutile). La misura utile è la latenza per singolo step, tracciata come span distinti. La documentazione Microsoft sul passaggio degli agenti in produzione è esplicita: senza tracing l’agente resta una “black box”, e il tracing lo trasforma in una “glass box” solo se distingue trace (l’esecuzione completa) e span (i singoli passaggi).
Tasso di tool call falliti e qualità della selezione
Qui vanno separate due cose che spesso si confondono. Il tool error rate misura le chiamate che falliscono tecnicamente (timeout, 500, parametri malformati). La tool selection quality, come la definisce Galileo, misura se l’agente ha scelto lo strumento giusto: si calcola come selezioni corrette diviso il totale delle chiamate. Un agente può avere zero errori tecnici e una selezione dei tool sbagliata nel 30% dei casi, e il vostro APM non ve lo dirà mai.
Costo per conversazione
Il costo per conversazione è la somma dei token in input e output di tutte le chiamate al modello dentro una singola sessione, più il costo delle API esterne invocate. Va tracciato per agente, per task e per utente, con budget alert. La soglia pratica suggerita da OneUptime è semplice e funziona: allertare quando la spesa supera 3 volte la media mobile. Nel caso documentato, un loop non rilevato ha portato il costo per iterazione da 0,01 a 80 dollari, con 2.847 dollari bruciati in quattro ore prima che qualcuno se ne accorgesse.
Deriva del prompt e della qualità: il segnale che i dashboard verdi nascondono
La deriva è il motivo per cui un agente che funzionava a marzo smette di funzionare a luglio senza che nulla sia “rotto”. Le cause sono banali: il modello sottostante viene aggiornato dal provider, i documenti nella knowledge base cambiano, gli utenti imparano a formulare richieste diverse da quelle previste, qualcuno tocca il prompt di sistema per risolvere un caso specifico e ne rompe altri tre.
L’unico modo per intercettarla è la valutazione continua sul traffico live. Microsoft Foundry lo struttura in tre movimenti: valutazione continua su una frequenza campionata del traffico di produzione, valutazione pianificata su dataset di test per rilevare la deriva, e alert quando gli output non superano le soglie di qualità. Le metriche specifiche per agente che indica sono accuratezza delle chiamate agli strumenti e completamento attività.
La tecnica operativa più economica sono le canary query: un set fisso di 20-50 domande con risposta attesa nota, eseguite ogni ora contro l’agente live. Se il pass rate scende sotto il 90%, scatta l’alert. Non serve un team di data scientist per implementarlo, serve che qualcuno mantenga il set nel tempo, ed è esattamente la parte che si smette di fare dopo il secondo mese.
Vale per qualsiasi dominio verticale: un agente di supporto tecnico che risponde su una knowledge base documentale, o un agente di back-office che lavora su procedure interne, degrada silenziosamente appena il corpus si aggiorna e nessuno rivaluta le risposte. Il codice non cambia, cambia il terreno sotto.
Escalation umane: la metrica più onesta che avete
Fra tutte le metriche, il tasso di escalation verso un operatore umano è quella che mente di meno. Non richiede un LLM-as-a-judge, non richiede annotazione manuale: è un evento binario e osservabile, e correla direttamente con la soddisfazione dell’utente.
Va però scomposto, altrimenti è inutile. Servono almeno tre categorie: escalation per policy (l’agente doveva passare la mano, è un successo, non un fallimento), escalation per incapacità (l’agente non ha saputo rispondere), escalation per insistenza dell’utente (l’utente ha chiesto un umano nonostante una risposta corretta). Solo la seconda categoria è un difetto da correggere; se le mettete nello stesso contatore, ottimizzerete la metrica sbagliata.
Il trend conta più del valore assoluto. Un tasso di escalation per incapacità stabile al 12% è un sistema sano con un perimetro noto. Lo stesso 12% che sale al 18% in tre settimane è deriva in corso. È lo stesso ragionamento che applichiamo agli 8 KPI per misurare il ROI di un agente AI in azienda: la derivata conta più del livello.
Come definire SLO realistici per un agente AI
L’impalcatura SRE e le due famiglie di SLO
Qui la letteratura si ferma, e infatti è il punto dove quasi nessun articolo si sbilancia. La disciplina SRE però offre già l’impalcatura giusta. Nel workbook di Google sull’implementazione degli SLO, l’error budget è definito come “100% meno l’SLO”, e il capitolo spiega perché puntare al 100% è un errore: significa non poter più aggiornare il servizio e avere tempo solo per reagire.
Per un agente servono due famiglie di SLO separate, non una. La prima è di disponibilità e si comporta come qualsiasi servizio: percentuale di richieste servite entro N secondi, uptime dell’endpoint. La seconda è di qualità e non ha equivalenti nell’APM: percentuale di conversazioni con task success, pass rate delle canary query, tasso di tool selection corretta.
Baseline di partenza: soglie operative da cui iniziare
I numeri che seguono sono un punto di partenza interno Mimír, ricavato dai nostri deployment: non provengono dalle fonti citate in questo articolo e non sono una raccomandazione di Google né di Microsoft. Per un agente interno di back-office partiamo da 99% di disponibilità mensile, p95 di latenza sotto gli 8 secondi, task success ≥ 85%, canary pass rate ≥ 90%, escalation per incapacità ≤ 15%. Vanno trattati come baseline da rivedere, non come target da adottare: il workbook di Google raccomanda di partire dai dati attuali del proprio servizio e iterare, non di scegliere soglie a tavolino. Il punto è che senza un SLO di qualità l’error budget non significa nulla: un agente può essere disponibile al 99,99% e sbagliato nella metà dei casi. La formalizzazione di queste soglie è anche ciò che distingue un contratto serio, come discutiamo negli SLA per agenti AI enterprise.
Strumentare l’osservabilità agenti AI in produzione senza un team SRE
La buona notizia è che lo stack è maturo e in larga parte open source. Lo standard di fatto per il tracing è OpenTelemetry, che ha ormai convenzioni semantiche dedicate a GenAI e agenti, span, attributi di token usage e metriche standard, mantenute in un repository separato dalle semantic conventions generali. Se il vostro agente espone i tool tramite protocolli standard, vale la pena strumentare anche quello strato: ne parliamo nella guida completa a MCP e Model Context Protocol.
Lo stack di osservabilità agenti AI: OpenTelemetry e le piattaforme
Sopra OpenTelemetry si innestano le piattaforme. Langfuse è open source e self-hostabile, cattura “ogni operazione, chiamate LLM, step di retrieval, esecuzioni di tool e logica custom” con timing, input, output e metadata, e include cost tracking e valutazione LLM-as-a-judge. Sul fronte commerciale, Microsoft Foundry integra tracing e monitoraggio in Application Insights con supporto nativo per LangChain, LangGraph, OpenAI Agents SDK e Microsoft Agent Framework.
Il processo di osservabilità che nessuna piattaforma vi vende
La parte che non si compra è il processo. Le cinque best practice di Azure mettono la valutazione dentro la pipeline CI/CD, ogni commit testato per qualità e sicurezza prima del rilascio, e prevedono red teaming pianificato. Tradotto per una PMI: qualcuno deve possedere il set di valutazione, farlo girare, e leggere i risultati. Se questa persona non esiste in organico, va prevista fuori. È il tema che affrontiamo in dettaglio parlando di manutenzione degli agenti AI post-deployment.
Perché la visibilità si perde dopo 60 giorni
Il pattern che vediamo ripetersi è sempre lo stesso. Settimana 1 dopo il go-live: tutti guardano i dashboard. Settimana 4: li guarda solo chi ha costruito l’agente. Settimana 8: il progetto è chiuso, la persona è su altro, e l’unico segnale rimasto è la lamentela di un utente. A quel punto la deriva ha già lavorato indisturbata per un mese, e ricostruire cosa è successo senza trace conservate è archeologia.
L’osservabilità agenti AI è un lavoro ricorrente senza proprietario
Non è una questione di pigrizia, è di struttura: l’osservabilità post-deploy è un lavoro ricorrente senza un proprietario naturale in aziende che non hanno un team di piattaforma. Le previsioni citate da Galileo danno il contesto: il 40% delle applicazioni enterprise avrà agenti dedicati entro fine 2026 (da meno del 5% nel 2025), ma il 40% dei progetti agentic sarà cancellato entro il 2027. E il debugging manuale diventa insostenibile già intorno agli 11-20 agenti attivi.
Le tre domande da mettere per iscritto prima del go-live
In termini di osservabilità, la continuità si riduce a tre decisioni che vanno scritte da qualche parte prima del lancio, non dopo. Chi possiede il set di canary query: chi lo aggiorna quando la knowledge base cambia, chi guarda il pass rate settimanale, chi decide che una domanda va sostituita perché non è più rappresentativa. Chi rilegge gli SLO e con che cadenza: soglie fissate al go-live su un traffico ipotizzato vanno ritarate sui dati reali dopo il primo trimestre, altrimenti l’error budget misura un servizio che non esiste più. Quali trace si conservano e per quanto: dato il volume, conservare tutto è insostenibile, ma una retention di 30 giorni sul campione completo e di 12 mesi sugli span aggregati (latenza per step, esito delle tool call, costo per conversazione) è ciò che separa una diagnosi da un’archeologia. Senza queste tre risposte, la telemetria continua a essere prodotta e nessuno la legge.
La differenza fra i due gruppi non è il modello scelto. È se qualcuno, tre mesi dopo il lancio, sta ancora guardando il tasso di tool call falliti, ed è la ragione per cui, negli agenti enterprise, il servizio conta più del modello. Su chi debba farsene carico nel tempo, e a quali condizioni, rimandiamo al pezzo dedicato alla manutenzione degli agenti AI post-deployment. Se state portando un agente in produzione o ne avete già uno live di cui avete perso il polso, parlatene con noi: una prima analisi serve a capire quali metriche vi mancano davvero, prima di comprare l’ennesima piattaforma.
Fonti:
- OneUptime — Monitoring AI agents in production
- Microsoft — AI Agents for Beginners: agents in production
- Galileo — AI agent observability
- Microsoft Learn — Observability in Azure AI Foundry
- Google SRE Workbook — Implementing SLOs
- OpenTelemetry — Semantic conventions for GenAI
- Langfuse — Observability documentation
- Azure Blog — Top 5 agent observability best practices
Domande frequenti
Perché il monitoraggio APM tradizionale non basta per un agente AI?
L'APM presuppone che lo stesso input produca lo stesso output e che un errore si manifesti come codice HTTP diverso da 200. Un agente AI viola entrambi i presupposti: può restituire una risposta ben formattata ma completamente inventata con uno status 200, senza generare alcun alert. Serve un livello di osservabilità semantica che valuti la qualità dell'output, non solo la salute dell'infrastruttura.
Quali metriche minime bisogna tracciare per un agente AI in produzione?
Quattro coprono la maggior parte degli incidenti reali: latenza per singolo step tracciata come span distinti, tasso di tool call falliti tecnicamente, qualità della selezione dei tool (selezioni corrette sul totale delle chiamate) e costo per conversazione con budget alert. A queste va aggiunto il tasso di escalation verso operatore umano, scomposto per causa.
Che cosa sono le canary query e come si usano?
Sono un set fisso di 20-50 domande con risposta attesa nota, eseguite periodicamente contro l'agente in produzione per verificare che continui a rispondere correttamente. Se il pass rate scende sotto una soglia definita, tipicamente il 90%, scatta un alert. È la tecnica più economica per intercettare la deriva della qualità senza un team di data scientist, ma richiede che qualcuno mantenga aggiornato il set nel tempo.
Come si definiscono SLO realistici per un agente AI?
Servono due famiglie separate di SLO: quelli di disponibilità (uptime, percentuale di richieste servite entro N secondi) e quelli di qualità (task success rate, canary pass rate, tasso di selezione corretta dei tool). Senza la seconda famiglia l'error budget non significa nulla, perché un agente può essere disponibile al 99,99% e sbagliato nella metà dei casi. Google raccomanda di partire dai dati reali del servizio e iterare, non di fissare target a tavolino.
Perché il tasso di escalation umane va scomposto in categorie?
Perché non tutte le escalation sono fallimenti. Vanno distinte quelle per policy (l'agente doveva passare la mano: è un successo), quelle per incapacità (non ha saputo rispondere: è il vero difetto) e quelle per insistenza dell'utente nonostante una risposta corretta. Se finiscono nello stesso contatore si finisce per ottimizzare la metrica sbagliata.
