Agenti AI e caos engineering: il rischio che nessuno traccia

C’è una categoria di incidenti in produzione che i team engineering non stanno registrando. Non perché non esistano, ma perché non corrispondono a nessun template di postmortem esistente. La sequenza è sempre la stessa: un agente avvia un’azione, l’azione è tecnicamente corretta dato il suo contesto, ma quel contesto è incompleto. L’infrastruttura reagisce a catena. E quando arriva il momento della revisione dell’incidente, tre team discutono se sia stato un errore dell’agente o dell’infrastruttura — perché i framework per pensare a queste due cose non sono mai stati collegati.

La portata del problema non è più teorica. Il 79% delle organizzazioni ha almeno un agente AI in produzione, e il 96% prevede di espandersi. Gartner stima che il 33% del software enterprise includerà agenti AI entro il 2028, ma avverte separatamente che il 40% di quei progetti verrà cancellato per scarsi controlli sul rischio. Quello che nessuna delle due statistiche cattura è la modalità di guasto che accade tra quei due numeri: agenti che sono in esecuzione, che non vengono cancellati, e che stanno silenziosamente generando eventi infrastrutturali che nessuno ha classificato come rischio.

Il giudizio che gli agenti saltano

Per capire perché questo è importante, bisogna guardare cosa c’è di rotto nei programmi di caos engineering aziendali prima ancora di aggiungere gli agenti al quadro. Nelle organizzazioni mature, i programmi di caos engineering includono controlli del raggio d’esplosione, esperimenti vincolati dagli SLO e prove generali. Quando un essere umano avvia un esperimento di caos, c’è una proprietà critica: qualcuno valuta se il sistema ha capacità di assorbire la perturbazione in quel momento. Controlla le dashboard, guarda il tasso di consumo del budget degli errori, verifica se le dipendenze sono stabili. È imperfetto e spesso intuitivo, ma almeno c’è una persona nel loop che fa la domanda giusta prima che qualcosa parta.

Quando introduci un agente di remediation autonomo — uno che può riavviare servizi, reindirizzare traffico, scalare risorse o modificare configurazioni in risposta ad anomalie — quella domanda scompare. L’agente vede un’anomalia, agisce, e quell’azione è di fatto un evento di caos. Nessun controllo sul tasso di consumo del budget errori. Nessun calcolo del raggio d’esplosione. Nessuna valutazione umana su se quel momento sia quello giusto per introdurre ulteriore stress in un sistema già sotto pressione da altre tre direzioni.

La modalità di guasto specifica è questa. Un agente di remediation rileva latenza elevata su un microservizio e risponde riavviando il cluster del servizio — un’azione ragionevole dati i suoi dati di training e la sua visione ristretta dell’incidente. Quello che l’agente non sa: tre altri servizi stanno gestendo traffico di picco, il pool di connessioni condiviso è già all’87% di utilizzo, e un database dipendente sta eseguendo una ricostruzione dell’indice in background. Il riavvio innesca un effetto “thundering herd” contro il servizio in ripresa. Quello che era iniziato come un picco di latenza che l’agente doveva risolvere diventa una cascata che l’agente non era progettato per modellare. Il raggio d’esplosione dell’azione dell’agente non era il riavvio del servizio. Era tutto ciò che stava a valle del riavvio, in uno stato di sistema di cui l’agente non aveva una visione completa. Nessun programma di caos engineering aveva testato quella specifica combinazione. Nessun calcolo del raggio d’esplosione includeva l’agente come attore. Perché non pensiamo agli agenti come iniettori di caos. Dovremmo.

Secondo l'AI Incidents Database, gli incidenti legati all’AI segnalati sono aumentati del 21% dal 2024 al 2025. Quel conteggio quasi certamente sottostima l’esposizione reale, perché la maggior parte delle organizzazioni non ha una classificazione di incidente che catturi l’azione di un agente autonomo come causa scatenante di una cascata. L’incidente viene registrato come riavvio di servizio, saturazione del pool di connessioni o evento di latenza. L’agente è invisibile nel postmortem.

La capacità di assorbimento come risorsa

Il problema di fondo è che i sistemi enterprise non hanno un linguaggio condiviso per la capacità di assorbimento — la stima in tempo reale di quanto stress aggiuntivo un sistema può tollerare prima di violare i suoi impegni SLO. I programmi di caos engineering la gestiscono implicitamente, attraverso il giudizio umano e soglie statiche che scattano dopo che un limite è già stato superato. Gli agenti non la gestiscono affatto.

Attraverso una ricerca primaria strutturata con professionisti di SRE e platform engineering di organizzazioni come Intuit e GPTZero, è stato sviluppato un modello di budget della resilienza. L’idea centrale è trattare la capacità di assorbimento come una risorsa consumabile, ricalcolata continuamente, invece che come una soglia statica da non superare. Un budget di resilienza si basa su quattro classi di segnali in tempo reale. Il tasso di consumo del budget errori (SLO burn rate) è l’input primario, perché codifica direttamente la distanza tra il comportamento attuale del sistema e l’impegno che conta davvero. Se un sistema consuma il suo budget errori mensile a cinque volte il tasso atteso, il budget di resilienza è vicino a zero, indipendentemente dall’utilizzo della CPU. La tendenza della latenza al P99 è più importante del valore assoluto, perché un servizio che sale gradualmente in quaranta minuti racconta una storia diversa da uno stabile allo stesso valore. Lo stato di saturazione delle dipendenze è il segnale più comunemente trascurato: un esperimento di caos o un’azione di un agente che assume un pool di connessioni condiviso come liberamente disponibile quando è all’87% produrrà modalità di guasto che nessuno ha progettato. I segnali comportamentali dell’applicazione — tassi di completamento delle sessioni, cambiamenti nei pattern delle chiamate API, degradazione delle conversioni — mostrano lo stress del sistema prima delle metriche infrastrutturali, perché gli utenti avvertono il degrado prima che Prometheus lo segnali.

La natura di budget, non di soglia, sta nel fatto che è consumabile. Ogni esperimento di caos attinge dalla capacità disponibile. Ogni azione di un agente attinge dalla stessa riserva. Nelle organizzazioni multi-team dove più esperimenti e più agenti possono agire simultaneamente, il budget è condiviso. Senza un registro condiviso del consumo, due team che eseguono esperimenti su dipendenze sovrapposte producono un raggio d’esplosione combinato che nessuno dei due aveva pianificato. Aggiungi agenti autonomi che agiscono completamente al di fuori del registro, e la contabilità crolla.

Dove i modelli linguistici aiutano, e dove falliscono

Alcune organizzazioni stanno sperimentando l’uso di modelli linguistici di grandi dimensioni (LLMs) per generare ipotesi di caos a partire da grafi di dipendenza e archivi di postmortem. I risultati sono indicativamente utili. I modelli linguistici propongono modalità di guasto plausibili che SRE esperti riconoscono come meritevoli di test, e generano ipotesi più velocemente dei processi manuali, specialmente quando lavorano su una ricca cronologia di postmortem. Il limite è la obsolescenza del grafo delle dipendenze, ed è un limite duro. Un’ipotesi generata da un grafo che non riflette l’estrazione di un servizio del mese scorso, o una nuova dipendenza da una libreria condivisa aggiunta due sprint fa, proporrà un esperimento con ipotesi di raggio d’esplosione errate. Il problema non è che il modello commette un errore: è che non sa di commetterlo. Sarà sicuro di sé in modo errato su un confine di sistema che non esiste più.