Il problema più critico degli agenti AI enterprise non è sempre l’errore visibile, il crash applicativo o la risposta palesemente incoerente. Nei sistemi autonomi distribuiti, il rischio più difficile da intercettare nasce spesso da un comportamento formalmente corretto, eseguito entro i permessi assegnati, con metriche tecniche apparentemente normali, ma completamente fuori dall’intento operativo per cui l’agente era stato progettato. È questa la logica alla base dell’“intent-based chaos testing”, un approccio pensato per verificare non soltanto se un agente funzioni, ma se continui ad agire secondo lo scopo previsto quando il contesto reale diventa incompleto, ambiguo, degradato o contraddittorio. VentureBeat descrive questo metodo partendo da uno scenario emblematico: un agente di osservabilità rileva un anomaly score di 0,87 su una soglia di 0,75, interpreta il segnale come un guasto, attiva in autonomia un servizio di rollback e provoca quattro ore di interruzione, anche se l’anomalia era in realtà un batch job pianificato che il sistema non aveva mai incontrato prima.
Il punto tecnico dello scenario non è che il modello abbia “allucinato” in senso classico. L’agente ha letto un valore, lo ha confrontato con una soglia, ha verificato di avere il permesso di usare uno strumento e ha completato l’azione prevista dalla propria catena decisionale. Il fallimento nasce a un livello più profondo: il sistema non era stato testato per capire cosa avrebbe fatto davanti a una condizione nuova, non prevista nei dati di riferimento, ma abbastanza plausibile da presentarsi in produzione. I test tradizionali avevano probabilmente verificato il percorso felice, la tenuta al carico, l’integrazione con i servizi downstream e i confini di sicurezza, ma non avevano misurato la distanza tra l’azione compiuta e l’intento reale dell’agente, cioè distinguere un’anomalia infrastrutturale pericolosa da un’attività legittima ma statisticamente insolita.
Questo passaggio è importante perché mostra il limite di molte strategie attuali di governance degli agenti AI. Nel 2026 il dibattito enterprise si concentra molto sull’identità degli agenti, sui permessi, sull’osservabilità e sulla tracciabilità delle azioni, ma questi elementi, da soli, non garantiscono che il comportamento resti corretto quando l’ambiente smette di essere ordinato. Un agente può avere un’identità definita, operare con credenziali legittime, produrre log completi e rispettare le policy di accesso, ma prendere comunque una decisione sbagliata perché interpreta male il contesto. In questo senso, la sicurezza non coincide più soltanto con il controllo di chi può fare cosa, ma con la verifica continua del perché un agente sta facendo quella cosa in quel momento.
L’intent-based chaos testing nasce proprio per colmare questa lacuna. Il chaos engineering tradizionale, reso popolare da esperienze come Chaos Monkey di Netflix, introduce guasti controllati nei sistemi distribuiti per verificare resilienza, tempi di recupero, disponibilità e tolleranza agli errori. Applicato agli agenti AI, però, questo approccio deve essere ampliato. Non basta degradare una dipendenza, aumentare la latenza o simulare la perdita di un servizio: bisogna osservare se, sotto stress, l’agente resta dentro i confini comportamentali attesi. Un microservizio che fallisce produce errori, timeout o metriche di disponibilità degradate. Un agente AI può invece mantenere latenza normale, completare tutte le chiamate agli strumenti e restituire uno stato di successo, mentre sta prendendo una decisione operativamente disastrosa.
La differenza fondamentale sta quindi nell’oggetto della misurazione. Nei sistemi software classici si misura la deviazione rispetto al successo tecnico: il servizio risponde o non risponde, l’errore aumenta o diminuisce, il throughput regge o crolla. Negli agenti autonomi bisogna misurare la deviazione rispetto all’intento. Un agente di osservabilità non deve soltanto “reagire a un’anomalia”, ma deve reagire in modo proporzionato, con il contesto sufficiente, rispettando le procedure di escalation e senza trasformare un falso positivo in un incidente reale. Se il sistema non dispone di questa metrica comportamentale, può scambiare l’esecuzione corretta di una procedura per un comportamento affidabile, anche quando quella procedura viene applicata al caso sbagliato.
Il framework descritto introduce per questo un “intent deviation score”, cioè un punteggio che misura quanto il comportamento osservato si discosti dalla baseline desiderata. Per un agente di osservabilità, le dimensioni considerate includono la deviazione nelle chiamate agli strumenti, l’ambito di accesso ai dati, l’accuratezza del segnale di completamento, la fedeltà dell’escalation verso operatori umani e la latenza decisionale. Nel modello proposto, queste dimensioni non hanno tutte lo stesso peso: la deviazione nelle chiamate agli strumenti vale il 30%, l’accesso ai dati il 25%, l’accuratezza del completamento il 20%, l’escalation il 15% e la latenza il 10%, ma la distribuzione può cambiare in base al profilo di rischio dell’agente.
Questa ponderazione è uno degli aspetti più tecnici e utili dell’approccio, perché riconosce che non tutti gli agenti hanno la stessa pericolosità operativa. Un agente analitico in sola lettura può tollerare una ponderazione inferiore sul rischio di azione irreversibile, mentre un agente con accesso in scrittura a sistemi di produzione deve essere valutato con soglie molto più severe su completamento, escalation e uso degli strumenti. In pratica, l’intent deviation score non è una metrica universale da copiare in ogni deployment, ma una misura calibrata sul ruolo dell’agente, sui sistemi che può modificare, sulla reversibilità delle sue azioni e sulla sensibilità dei dati che può consultare.
La formula concettuale è semplice ma potente: si confronta ogni dimensione osservata con la relativa baseline, si normalizza la deviazione e la si moltiplica per il peso assegnato. Il risultato viene compresso in un intervallo da 0 a 1, dove 0 indica assenza di deviazione e 1 una violazione completa dell’intento. La parte più importante, però, è che questo punteggio non misura la performance. Un agente può avere tempi di risposta eccellenti, error rate pari a zero e completamento tecnico positivo, ma produrre comunque un intent deviation score elevato. È proprio questa separazione tra performance e correttezza comportamentale a rendere il metodo adatto agli agenti AI, perché consente di intercettare i fallimenti silenziosi che non emergono dalle metriche tradizionali.
Nel caso dell’agente di rollback, il framework avrebbe prodotto un punteggio intorno a 0,78, classificato come catastrofico. Non perché l’agente non fosse riuscito a usare lo strumento, ma perché aveva preso una decisione irreversibile con contesto insufficiente, senza escalation umana e con un segnale di completamento non allineato all’esito reale del sistema. L’elemento decisivo sarebbe stato il “context completeness”, indicato nello schema di log come 0,62: l’agente aveva quindi solo il 62% del contesto previsto, ma ha comunque agito con alta confidenza. Un’infrastruttura di test basata sull’intento avrebbe trasformato quell’incidente in un’anomalia di pre-produzione, impedendo il passaggio alla fase live.
Il metodo propone una progressione in quattro fasi, costruita per aumentare gradualmente il raggio d’impatto del test. La prima fase introduce la degradazione di un singolo strumento downstream, per osservare se l’agente gestisce l’errore in modo ragionevole, se riprova con logica controllata, se modifica la sequenza delle chiamate senza uscire dai confini previsti o se attiva un’escalation quando non può più procedere con sufficiente affidabilità. Questa fase serve a distinguere un agente robusto da un agente che interpreta ogni fallimento di dipendenza come un invito a improvvisare nuove azioni.
La seconda fase riguarda il cosiddetto “context poisoning”, cioè l’inserimento di contesto corrotto, incompleto, obsoleto o contraddittorio. È probabilmente la fase più realistica per molte aziende, perché i sistemi enterprise non forniscono quasi mai dati perfettamente puliti. Telemetrie mancanti, baseline vecchie, campi incompleti, segnali discordanti tra strumenti di monitoraggio e anomalie causate da attività pianificate sono condizioni comuni. L’obiettivo del test è capire se l’agente riconosce l’insufficienza informativa oppure procede comunque, trasformando dati fragili in decisioni operative forti.
La terza fase introduce l’interferenza multi-agente. Qui il rischio non nasce più soltanto dall’agente singolo, ma dall’interazione tra più agenti che operano su dati sovrapposti, strumenti condivisi o risorse comuni. Due agenti possono essere corretti se valutati separatamente e diventare pericolosi quando agiscono nello stesso ambiente, perché le azioni dell’uno modificano il contesto operativo dell’altro. La ricerca “Agents of Chaos”, pubblicata su Hugging Face come paper arXiv 2602.20021, documenta vulnerabilità di sicurezza e governance in agenti autonomi dotati di memoria persistente, account email, accesso a Discord, filesystem ed esecuzione shell, includendo casi di azioni non autorizzate, disclosure di informazioni, consumo incontrollato di risorse e propagazione cross-agent di pratiche non sicure.
La quarta fase combina degradazioni multiple: latenza degli strumenti, contesto incompleto, agenti concorrenti, baseline obsolete e segnali discordanti. È la simulazione più vicina all’entropia reale della produzione, dove i problemi raramente arrivano isolati e ordinati. In questa fase non si pretende che l’agente sia perfetto, ma si vuole misurare il suo raggio d’impatto sotto condizioni complesse. Un agente che, davanti a incertezza cumulativa, riduce l’autonomia, blocca l’azione irreversibile e chiede revisione umana sta mostrando una forma di resilienza comportamentale. Un agente che mantiene la stessa aggressività operativa di quando il contesto è pulito sta invece rivelando un difetto strutturale di governance.
L’altro elemento rilevante è che il superamento delle fasi non dovrebbe essere simbolico. Se il punteggio di deviazione supera la soglia prevista per quella fase, l’agente non dovrebbe passare alla fase successiva né essere promosso in produzione. Questo rende l’intent-based chaos testing un vero gate di deployment, non un esercizio dimostrativo. La sua collocazione naturale è dopo unit test, integration test, load test e security red team, ma prima della produzione. In altre parole, i controlli classici verificano che il sistema funzioni, regga il traffico e non violi policy evidenti; il chaos testing basato sull’intento verifica se l’agente resta coerente con il proprio mandato quando il mondo reale introduce ambiguità.
Questa distinzione è essenziale anche per l’osservabilità. I log tradizionali, basati su errore, latenza, endpoint chiamati e stato finale, non sono sufficienti per diagnosticare un fallimento agentico. Servono log che includano la catena decisionale, le osservazioni ricevute, gli strumenti chiamati, il livello di completezza del contesto, l’attivazione o meno dell’escalation, il punteggio di deviazione dall’intento e il livello di chaos rilevato. Senza questi campi, un outage causato da un agente appare come una sequenza legittima di azioni tecniche; con questi campi, diventa invece possibile capire che il sistema ha agito con confidenza eccessiva rispetto alla qualità del contesto disponibile.
Il tema si collega direttamente alla sicurezza degli agenti AI nelle aziende. Il report “State of AI Agent Security 2026” di Gravitee, basato su oltre 900 executive e professionisti tecnici, indica che l’80,9% dei team tecnici ha già superato la fase di pianificazione ed è entrato in test attivi o produzione, mentre solo il 14,4% dichiara che tutti gli agenti vadano live con piena approvazione security e IT. Lo stesso report segnala che l’88% delle organizzazioni ha confermato o sospettato incidenti di sicurezza legati ad agenti AI nell’ultimo anno e che solo il 21,9% dei team tratta gli agenti come entità con identità indipendente.
Questi numeri aiutano a capire perché il chaos testing basato sull’intento non sia un raffinamento accademico, ma una necessità infrastrutturale. Molte aziende stanno portando agenti autonomi dentro workflow reali prima di avere una disciplina matura di identità, autorizzazione, auditing e validazione comportamentale. Se un agente usa credenziali condivise, opera con permessi troppo ampi, non viene monitorato in modo completo e non è stato sottoposto a test di deviazione dall’intento, il problema non è soltanto la possibilità di un errore del modello. Il problema è che l’intera catena operativa può rendere quell’errore difficilmente attribuibile, difficilmente contenibile e difficilmente diagnosticabile.
La governance degli agenti deve quindi passare da una logica statica a una logica dinamica. Non basta approvare un agente al momento del rilascio, perché gli agenti cambiano. Ricevono nuovi tool, nuovi prompt, nuove autorizzazioni, nuove integrazioni, nuovi flussi dati e nuovi obiettivi. Un agente che a gennaio supera tutti i test può avere ad aprile un profilo di rischio completamente diverso, anche se il suo nome e la sua funzione apparente restano invariati. Per questo il framework insiste sul retraining loop e sulla necessità di trasformare i risultati degli esperimenti in artefatti di governance, non in report occasionali. Ogni modifica significativa a configurazione, strumenti o ambito operativo dovrebbe attivare una nuova verifica mirata sulle dimensioni più esposte al cambiamento.
La stessa previsione di Gartner secondo cui oltre il 40% dei progetti di agentic AI sarà cancellato entro la fine del 2027, a causa di costi crescenti, valore di business poco chiaro o controlli di rischio inadeguati, conferma che il problema non è soltanto tecnologico. La promessa degli agenti autonomi è forte, ma il passaggio dalla demo al sistema produttivo introduce costi di controllo, integrazione e responsabilità che molte organizzazioni sottovalutano. Gartner osserva anche che, entro il 2028, almeno il 15% delle decisioni lavorative quotidiane potrebbe essere preso autonomamente tramite agentic AI, mentre il 33% delle applicazioni software enterprise potrebbe includere capacità agentiche.
In questo scenario, l’intent-based chaos testing diventa una forma di assicurazione ingegneristica contro l’autonomia mal calibrata. Non elimina ogni incidente e non sostituisce sicurezza, osservabilità, red teaming, test di integrazione o controllo dei permessi. Aggiunge però un livello che oggi manca spesso: la verifica pre-produzione della coerenza comportamentale. La domanda non è più soltanto se l’agente sappia completare un task, ma se sappia riconoscere quando non dovrebbe completarlo, quando deve fermarsi, quando deve chiedere conferma e quando il contesto non consente un’azione autonoma affidabile.
Il vero cambiamento culturale è questo: nei sistemi agentici, il successo non coincide con l’esecuzione. Un agente che esegue sempre, rapidamente e senza errori tecnici può essere meno sicuro di un agente che sa interrompersi davanti all’ambiguità. Per anni l’automazione enterprise ha misurato efficienza, velocità e riduzione dell’intervento umano; con gli agenti AI, queste metriche devono essere affiancate da misure di prudenza operativa, aderenza all’intento e qualità dell’escalation. La capacità di non agire diventa una proprietà di sicurezza tanto importante quanto la capacità di agire.
Per questo il chaos testing basato sull’intento è una proposta particolarmente concreta. Non si limita a dire che gli agenti AI sono rischiosi, ma offre un modo per trasformare il rischio in misure, soglie, fasi di test, log e decisioni di deployment. Invece di affidarsi alla speranza che un agente allineato si comporti bene anche in produzione, il metodo chiede di dimostrarlo sotto stress, prima che l’agente abbia accesso a sistemi reali, dati sensibili o azioni irreversibili. La differenza tra un incidente scoperto in pre-produzione e un outage di quattro ore non sta nella qualità astratta del modello, ma nella disciplina con cui il sistema è stato costretto a mostrare il proprio comportamento quando le condizioni smettono di essere ideali.