La diffusione dell’intelligenza artificiale nelle imprese italiane sta rendendo urgente un problema rimasto finora in secondo piano. Non basta più verificare che un modello risponda e che un’applicazione resti disponibile. Occorre ricostruire che cosa abbia fatto un agente, quali strumenti abbia utilizzato, quanto sia costata ogni esecuzione e perché un determinato workflow abbia prodotto un risultato inatteso.
Nel 2025 il 16,4% delle imprese italiane con almeno dieci addetti utilizzava almeno una tecnologia di intelligenza artificiale, il doppio rispetto all’8,2% rilevato nel 2024. Il dato Istat non misura specificamente l’adozione di agenti o piattaforme AgentOps, ma descrive un contesto nel quale un numero crescente di sistemi AI entra nei processi operativi. Quando questi sistemi acquisiscono la capacità di consultare database, invocare API, generare codice o avviare transazioni, l’osservabilità diventa un elemento di controllo aziendale e non soltanto uno strumento per sviluppatori.
Indice degli argomenti:
Dalla manutenzione del software tradizionale al controllo dei modelli non deterministici
Il software convenzionale viene monitorato attraverso log, metriche e trace distribuite. Gli agenti introducono un ulteriore livello di complessità perché il loro comportamento dipende dal modello, dal prompt, dal contesto recuperato, dallo stato della conversazione e dalle risposte dei servizi esterni. Due esecuzioni apparentemente identiche possono seguire percorsi differenti, scegliere strumenti diversi o produrre conclusioni non equivalenti.
Una trace agentica deve quindi ricostruire l’intera catena operativa. Deve mostrare le chiamate al modello, i passaggi di retrieval, le decisioni di routing, le funzioni invocate, le interazioni tra agenti e gli eventuali tentativi successivi a un errore. L’obiettivo non è registrare il ragionamento interno riservato del modello, ma documentare gli eventi osservabili necessari per capire come il sistema abbia raggiunto un risultato.
Il termine AgentOps indica questa disciplina operativa, mentre AgentOps.ai è il nome di uno specifico prodotto commerciale e open-source.
Il fattore economico: gestire la tokenomics e i costi di calcolo
Un agente può consumare molte più risorse di un chatbot tradizionale. Una sola richiesta dell’utente può generare fasi di pianificazione, interrogazioni a un archivio vettoriale, chiamate a più modelli, verifiche automatiche, uso di strumenti e nuovi tentativi. Il costo significativo non è quindi quello della singola chiamata API, ma quello necessario per completare con successo un compito.
Le piattaforme di osservabilità attribuiscono token e spesa a modelli, sessioni, utenti, applicazioni o singoli passaggi. Questi valori, tuttavia, non sempre coincidono con la fattura del provider. Datadog, per esempio, specifica che il costo viene stimato utilizzando i conteggi dei token e i listini pubblici. Cambiamenti tariffari, sconti contrattuali, caching e servizi accessori possono produrre differenze.
Un sistema AgentOps maturo deve quindi confrontare la telemetria applicativa con i dati amministrativi del fornitore e misurare anche il costo per attività completata, non soltanto la spesa per milione di token.
Mitigare i rischi operativi: allucinazioni, regressioni e data leakage
Le anomalie più rilevanti non provocano sempre un errore tecnico. Un agente può terminare correttamente una sessione e, nello stesso tempo, citare una fonte inesistente, scegliere lo strumento sbagliato o trasmettere informazioni che non avrebbe dovuto elaborare. Per questo l’osservabilità deve essere affiancata da valutazioni automatiche, test di regressione, controlli deterministici e revisioni umane.
Esiste inoltre un rischio generato dal monitoraggio stesso. Prompt, risposte, documenti recuperati e parametri delle funzioni possono contenere dati personali, segreti industriali o credenziali.
Il rapporto dell’European Data Protection Board sui rischi privacy degli LLM richiama l’esigenza di minimizzazione, controllo degli accessi e mitigazione lungo l’intero ciclo di vita. Redigere i dati dopo averli già inviati a un servizio esterno non equivale a impedirne la raccolta. Nei contesti più sensibili, il filtraggio dovrebbe quindi avvenire prima dell’ingestione della telemetria.
Privacy, GDPR e sovranità del dato: le soluzioni open-source e self-hosted
Il self-hosting consente di mantenere trace e dataset nell’infrastruttura scelta dall’organizzazione, ma non costituisce una certificazione automatica di conformità. L’impresa resta responsabile della base giuridica del trattamento, delle finalità, della conservazione, delle autorizzazioni e delle misure di sicurezza. Occorre inoltre verificare quali componenti rimangano realmente locali e quali comunichino con servizi di controllo, telemetria o autenticazione gestiti dal fornitore.
1. Langfuse (GDPR Compliant & Open-Source)
Langfuse riunisce tracing, gestione dei prompt, dataset, annotazioni, esperimenti e valutazioni. Gran parte del codice è distribuita con licenza permissiva e la piattaforma può essere installata on-premises o in un cloud controllato dall’impresa. Alcune funzioni enterprise, tra cui specifici strumenti per audit, SCIM e retention, richiedono però una licenza commerciale.
La formula “GDPR compliant” deve essere interpretata con precisione. Langfuse dichiara la conformità del proprio servizio cloud e offre una regione europea, accordi sul trattamento dei dati, masking e cancellazione. Un’installazione self-hosted può facilitare una strategia conforme, ma il risultato dipende dall’architettura, dai processi del titolare e dalla configurazione adottata. Per le organizzazioni europee rappresenta una delle opzioni più complete, purché la valutazione non si fermi all’etichetta open-source.
2. Arize Phoenix (Open-Source Evaluation Engine)
Arize Phoenix è una piattaforma open-source orientata a tracing, sperimentazione e valutazione di applicazioni LLM. Riceve trace tramite OpenTelemetry e utilizza OpenInference per descrivere chiamate al modello, retrieval, tool e logica applicativa. Supporta valutatori programmabili, LLM-as-a-judge, dataset ed esperimenti comparativi.
Il suo punto di forza è la capacità di trasformare le esecuzioni di produzione in materiale per il debugging e la valutazione. È adatto ai gruppi che vogliono mantenere controllo sul backend e costruire metriche specifiche per il proprio dominio. OpenTelemetry riduce il rischio di dipendenza da un unico fornitore, anche se le convenzioni semantiche dedicate alla GenAI sono ancora in sviluppo e non garantiscono una portabilità perfetta tra tutti i prodotti.
3. Laminar (Open-Source Deep-Tracing)
Laminar concentra l’attenzione sulla navigazione delle esecuzioni agentiche. La piattaforma mostra input, chiamate LLM, tool, sotto-agenti e tempi di esecuzione in una timeline leggibile. Le trace di produzione possono essere convertite in dataset, riprodotte e utilizzate per valutazioni locali o integrate nelle pipeline CI.
Il progetto è distribuito con licenza Apache 2.0 e prevede installazioni mediante Docker o Helm. La sua utilità emerge quando è necessario isolare il punto esatto nel quale un workflow complesso ha cambiato direzione. Come per gli altri prodotti self-hosted, l’organizzazione deve però assumersi la gestione di database, aggiornamenti, backup e sicurezza operativa.
Gli specialisti dell’ingegneria agentica
Questa categoria comprende strumenti nati direttamente intorno agli LLM e agli agenti. Offrono in genere una rappresentazione più dettagliata di prompt, tool e sessioni rispetto alle piattaforme APM tradizionali, ma possono richiedere un’integrazione separata con i sistemi di incident management, sicurezza e controllo infrastrutturale.
4. AgentOps.ai (Multi-Agent Specialist)
AgentOps.ai traccia sessioni, agenti, tool, errori, token, costi e tempi di risposta. Dispone di integrazioni con framework quali CrewAI, AutoGen, LangGraph, Agno e OpenAI Agents SDK. La visualizzazione delle interazioni tra componenti lo rende particolarmente utile nei workflow multi-agent, dove l’errore può derivare dal coordinamento e non dalla singola risposta del modello.
Il prodotto non è limitato ai sistemi multi-agent e può essere utilizzato anche con applicazioni LLM più semplici. Il codice dell’applicazione è disponibile con licenza MIT e la documentazione descrive una modalità self-hosted basata, tra gli altri componenti, su PostgreSQL, ClickHouse e OpenTelemetry Collector. Questa architettura offre controllo, ma introduce un carico operativo superiore rispetto al servizio gestito.
5. Latitude (Latitude.so) (Autonomous Feedback Loop)
Latitude collega trace, annotazioni, segnali di errore, dataset, valutazioni e test di regressione. Le funzioni più recenti possono attivare un coding agent quando viene individuato un problema, fornendogli trace e contesto per investigare e proporre una modifica. L’agente opera però nell’ambiente dell’utente, mentre Latitude agisce come sistema di attivazione e fonte del contesto.
L’espressione “Autonomous Feedback Loop” descrive quindi un processo parzialmente automatizzato, non un ciclo completamente indipendente. La stessa documentazione di Latitude mantiene due passaggi umani espliciti. Le annotazioni servono a definire il riferimento corretto e ogni pull request viene revisionata prima del merge.
È una distinzione importante per evitare che l’automazione dell’analisi venga confusa con l’autorizzazione autonoma a modificare un sistema di produzione.
6. Helicone (Proxy-Based Integration)
Helicone permette di instradare le richieste verso i provider LLM attraverso un proxy, modificando in molti casi soltanto il base URL dell’applicazione. Raccoglie richieste, risposte, latenza, token, costi e proprietà personalizzate. Le Sessions raggruppano le chiamate appartenenti allo stesso flusso, consentendo di ricostruire conversazioni e workflow multi-step. È disponibile anche una modalità asincrona che evita di collocare il proxy sul percorso critico.
La valutazione strategica del prodotto è però cambiata. Il 3 marzo 2026 Mintlify ha annunciato l’acquisizione di Helicone e il passaggio della piattaforma alla modalità di manutenzione. Continueranno gli aggiornamenti di sicurezza, le correzioni e il supporto ai nuovi modelli, ma non è previsto un normale sviluppo di nuove funzionalità. Helicone rimane utilizzabile per installazioni esistenti, mentre per nuovi progetti pluriennali il rischio di stagnazione e la futura migrazione devono entrare nella decisione.
7. Galileo (security & risk management)
Galileo integra osservabilità, valutazioni e protezione runtime. I controlli possono esaminare gli input e gli output di una chiamata AI e bloccare contenuti dannosi o non conformi prima che raggiungano l’utente. La piattaforma offre metriche specifiche per sistemi agentici, comprese valutazioni sulla scelta degli strumenti e sull’andamento delle sessioni multi-agent.
Dal maggio 2026 Galileo non rappresenta più un fornitore indipendente. Cisco ne ha completato l’acquisizione con l’obiettivo di rafforzare Splunk Observability e le capacità di monitoraggio degli agenti. Le tecnologie Galileo restano riconoscibili, ma devono essere valutate all’interno della strategia Cisco-Splunk. In una selezione commerciale, Galileo e Splunk non possono quindi essere contati come due alternative completamente separate.
8. Braintrust (CI/CD for AI)
Braintrust applica alle applicazioni AI un modello vicino al testing software. Dataset, scorer ed esperimenti consentono di confrontare versioni di prompt, modelli e pipeline. I risultati possono essere usati in CI/CD per individuare casi peggiorati e impedire il rilascio di modifiche che non rispettano le soglie stabilite.
La piattaforma è particolarmente adatta quando l’organizzazione dispone già di esempi rappresentativi e criteri misurabili. Senza un dataset affidabile, anche la migliore pipeline di valutazione rischia di ottimizzare il sistema rispetto a casi poco significativi. Braintrust offre inoltre opzioni di deployment nelle quali il data plane viene collocato nel cloud del cliente, ma la responsabilità operativa rimane condivisa e deve essere esaminata nella due diligence.
Monitoraggio full-stack e integrazione con le infrastrutture IT esistenti
Le piattaforme enterprise partono da un vantaggio diverso. Possono correlare un comportamento anomalo dell’agente con errori API, problemi di rete, database lenti, saturazione delle GPU, deployment recenti o incidenti di sicurezza. La loro profondità nelle valutazioni semantiche può essere inferiore a quella di alcuni specialisti, ma l’integrazione con l’operatività IT riduce la frammentazione.
9. Dynatrace (Enterprise Observability)
Dynatrace estende la propria piattaforma a modelli generativi, agenti, framework e servizi di inferenza. La telemetria AI viene correlata con applicazioni, infrastruttura e dipendenze, permettendo di distinguere un problema del modello da un rallentamento introdotto da un servizio esterno o da una risorsa sottostante.
La documentazione aggiornata indica supporto per numerose tecnologie, tra cui OpenAI, Anthropic, Amazon Bedrock, Gemini, CrewAI e OpenAI Agents SDK. Dynatrace accetta inoltre dati OpenTelemetry e attributi GenAI. È una scelta coerente per imprese che utilizzano già la piattaforma e vogliono integrare l’osservabilità AI nel modello operativo degli SRE.
10. Datadog (Full-Stack APM)
Datadog Agent Observability registra trace, errori, latenza, token, costi stimati ed esiti delle valutazioni. Questi segnali possono essere analizzati insieme all’APM, alle metriche infrastrutturali e ai dati cloud già presenti nella piattaforma. La correlazione è utile per capire, per esempio, se l’aumento del costo dipenda da prompt più lunghi, retry applicativi o degrado di un servizio.
Il costo calcolato da Datadog rimane una stima basata sui listini pubblici e sui token annotati nelle span. Anche la retention deve essere considerata, perché conservare grandi volumi di trace contenenti payload completi può incidere sia sulla spesa sia sul rischio privacy. Datadog è quindi forte nell’integrazione full-stack, ma richiede una progettazione attenta di campionamento, tagging e tempi di conservazione.
11. Splunk (Secure Logging & Auditing)
Splunk AI Agent Monitoring misura prestazioni, qualità, token, costi stimati e rischi degli agenti, utilizzando strumentazione compatibile con OpenTelemetry. L’integrazione con APM, logging e strumenti di sicurezza rende la piattaforma adatta alle organizzazioni nelle quali le trace AI devono essere correlate con eventi applicativi, accessi e attività anomale.
L’acquisizione di Galileo ha ampliato il prodotto con valutazioni e guardrail runtime. Esiste però un compromesso sul trattamento dei dati. Per utilizzare alcune valutazioni eseguite lato piattaforma è necessario memorizzare in Splunk Observability Cloud i dati delle conversazioni. Le imprese devono quindi stabilire in anticipo quali contenuti possano essere acquisiti, se applicare redazione preventiva e quali utenti debbano poter consultare le trace.
12. Grafana Labs (Visualization & Telemetry)
Grafana Agent Observability raccoglie le generazioni, le organizza in conversazioni, associa le esecuzioni alle versioni degli agenti e permette di applicare valutazioni continue. L’integrazione con l’ecosistema Grafana è interessante per i team che utilizzano già dashboard, metriche, log e trace della piattaforma.
Al momento della verifica, il prodotto è ancora in public preview su Grafana Cloud. Grafana Labs dichiara supporto limitato e avverte che potrebbero verificarsi modifiche incompatibili prima della disponibilità generale. La soluzione appare promettente, ma non dovrebbe essere selezionata per carichi critici senza una verifica delle funzionalità effettivamente disponibili, delle condizioni di supporto e del piano di evoluzione.
Criteri di scelta tecnologica e raccomandazioni strategiche
La selezione di una piattaforma AgentOps dovrebbe iniziare dai rischi del caso d’uso. Un assistente che riassume documenti interni richiede controlli diversi da un agente autorizzato a modificare ordini, inviare comunicazioni o interrogare dati sanitari. Più l’agente può produrre effetti esterni, maggiore deve essere la capacità di attribuire ogni azione a una sessione, a una versione e a un’identità autorizzata.
Il primo criterio riguarda il dato. Occorre verificare se la piattaforma acquisisca prompt e risposte completi, dove vengano conservati, come siano cancellati e se la redazione avvenga prima o dopo l’invio.
Self-hosted non significa automaticamente isolato. Devono essere controllati anche servizi di autenticazione, telemetria del prodotto, aggiornamenti e control plane esterni.
Il secondo criterio è l’interoperabilità. OpenTelemetry rappresenta oggi il riferimento più importante per evitare formati proprietari, ma le convenzioni GenAI e agentiche restano in evoluzione. Un test realistico deve quindi verificare non soltanto l’ingestione OTLP, ma anche l’esportazione delle trace, la conservazione dei metadati e la possibilità di migrare dataset, annotazioni e valutazioni.
Il terzo criterio è la qualità delle valutazioni. Le metriche automatiche devono essere calibrate rispetto a esempi revisionati da persone competenti. Un LLM-as-a-judge non costituisce una verità oggettiva e può introdurre bias o risultati instabili. La piattaforma dovrebbe consentire di combinare controlli deterministici, feedback umano, confronti con dati di riferimento e test su casi avversi.
Infine, la tokenomics deve essere misurata insieme al risultato operativo. Le metriche più utili sono il costo per attività accettata, il tasso di successo, la latenza di coda, il numero medio di tool call e la quota di esecuzioni che richiede retry o intervento umano. Vanno aggiunti i costi delle valutazioni, della conservazione delle trace e della stessa piattaforma di osservabilità.
Per team tecnici che privilegiano controllo e self-hosting, Langfuse, Phoenix e Laminar costituiscono le opzioni più lineari.
AgentOps.ai è particolarmente interessante per framework multi-agent, mentre Braintrust e Latitude risultano più adatti a processi guidati da test e regressioni. Dynatrace e Datadog offrono il maggiore vantaggio quando sono già presenti nello stack enterprise.
Splunk diventa una proposta più ampia dopo l’integrazione di Galileo, soprattutto nei contesti in cui osservabilità e sicurezza devono convergere.
Grafana merita attenzione, ma il suo stato di public preview impone cautela.
Helicone rappresenta un caso distinto. Le sue funzioni sono reali e ancora disponibili, ma la modalità di manutenzione ne riduce l’attrattiva per nuovi progetti strategici.
Allo stesso modo, Galileo deve essere considerato come tecnologia dell’offerta Cisco-Splunk e non come concorrente indipendente. La scelta finale dovrebbe avvenire attraverso una prova sui dati dell’organizzazione, utilizzando trace reali opportunamente anonimizzate, carichi rappresentativi e criteri di uscita definiti prima del test.
Bibliografia
Istat, Imprese e ICT – Anno 2025.
Dong, Lu e Zhu, AgentOps: Enabling Observability of LLM Agents.
European Data Protection Board, AI Privacy Risks & Mitigations – Large Language Models.
OpenTelemetry, Semantic Conventions e AI Agent Observability – Evolving Standards and Best Practices.
Langfuse, Security Overview, Open-Source Handbook e Self-Hosting FAQ.
Arize AI, Arize Phoenix Documentation.
Laminar, Platform Overview, Tracing ed Evaluations.
AgentOps.ai, Platform Documentation e Self-Hosting Overview.
Latitude, Self-Healing Agents e Agent Dispatch.
Helicone, Platform Overview, Sessions e Proxy versus Async.
Mintlify, Mintlify Acquires Helicone.
Galileo, What Is Galileo?, Runtime Protection e Agentic Metrics.
Splunk, Splunk Observability and Galileo e Splunk AI Agent Monitoring.
Braintrust, Evaluation Quickstart, Compare Experiments e Self-Hosting.
Dynatrace, AI Observability e AI Observability Integrations.
Datadog, Agent Observability e Cost Monitoring.
Grafana Labs, Grafana Agent Observability e Introduction to Agent Observability.
Partecipa alla community