Gli agenti AI generano disastri che l'ingegneria non riesce ancora a tracciare

Esiste una categoria di incidenti produttivi che le squadre di ingegneria non tengono traccia, perché non rientrano in alcun modello esistente di post-mortem. Qualcosa che inizia quando un agente inizializza un'azione; tecnicamente corretta per il contesto in cui opera, nonostante il contesto sia incompleto. L'infrastruttura collassa in sequenza e quando arriva il momento della revisione dell’incidente, tre team si contendono chi abbia causato realmente il problema, visto che non esiste un quadro comune su cui basarsi per comprendere se il sistema o l’agente ha fallito.

Sempre più aziende si stanno muovendo verso l’uso di agenti AI autonomi per automatizzare processi critici e reattivi. Settanta-nove percento delle organizzazioni oggi ha alcuni agenti AI in produzione, con il novantasei percento che intende espandere la loro utilizzazione. Secondo Gartner, entro il 2028, il trentatré percento del software aziendale includerà una componente di agentic AI ma, in parallelo, vi è una previsione che il quaranta percento di questi progetti vedrà il fallimento per mancanza di controlli di rischio.

Ciò che non emerga da queste statistiche è il tipo specifico di fallimento che si verifica tra quelle percentuali: agenti in esecuzione, non cancellati, che generano eventi infrastrutturali che nessuno definisce esplicitamente come rischio. Dopo sei anni di lavoro nel campo dell'automazione infrastrutturale con aziende del calibro di Cisco e Splunk, sono giunto alla convinzione che gli agenti e la progettazione del caos siano in realtà la stessa disciplina. Il loro disconnessione genera un rischio che, se non sistemato, comporterà incidenti su larga scala.

La ragione principale per cui è importante comprendere questa struttura di fallimento sta nel modo in cui l'ingegneria tratta oggi il caos. Le aziende sofisticate hanno programmato eventi di caos con metodi ben definiti: test simulati, limiti di raggio d'azione e esperimenti SLO-gated. Quando un ingegnere decide di iniziare un esperimento di caos, il giudizio umano è un fattore chiave. L'ingegnere valuta in tempo reale il sistema per decidere se può assorbire una perturbazione.

Con l’entrata in campo degli agenti autonomi, questo tipo di giudizio scompare. Essi rilevano un'anomalia, reagiscono con un'azione, e questa azione è automaticamente una forma di caos. Tuttavia, il giudizio umano non è coinvolto. Non c’è un controllo SLO, nessun calcolo di raggio d'azione, né un'analisi del sistema attuale. Il risultato è che un intervento autonomo, che può sembrare banale, si traduce in un'escalation non pianificata.

Un esempio reale mostra chiaramente il tipo di fallimento che ho visto accadere ripetutamente: un agente di correzione rileva una latenza elevata su un microservizio e decide di avviare il restart del cluster del servizio. La sua decisione appare logicamente fondata in base ai dati a disposizione. Tuttavia, l'agente non conosce che altri tre servizi stanno gestendo il traffico massimo, e che il pool condiviso delle connessioni è già saturo. Il database che dipende ha un’operazione di riassegnazione di indice in corso. L’azione di avvio genera un afflusso di richieste che destabilizza il sistema in recupero in modo irreversibile.

Questo processo di escalation, inizialmente volto a risolvere un problema, si conclude con un effetto a catena non previsto. Nessun piano di caos dell’azienda aveva testato questa combinazione specifica. Nessuna valutazione di raggio d'azione aveva incluso un agente autonomo come causa potenziale. Perché? Perché non lo percepiamo come una fonte di caos.

Secondo il database su incidenti collegati all’AI, il numero di incidenti segnalati collegati all’uso dell’AI è cresciuto del ventuno percento tra il 2024 e il 2025. Questo dato però sottostima il problema, perché molte aziende non hanno alcuna categoria che identifichi l’agente autonomo come la causa iniziale di un incidente. Il sistema registrà una ripresa di servizi, uno satura il pool connesso, o una latenza insolita. L’agente non appare mai come causa primaria nel post-mortem.

La risorsa mancante: La capacità di resilienza

Il problema centrale riguarda la mancanza di una metrica chiara per la capacità assorbente del sistema: la quantità di stress in eccesso che un sistema può supportare senza compromettere il SLO. Oggi, i programmi di caos gestiscono questa capacità in modo implicito, affidandosi a giudizi umani e a soglie fisse che vengono attivate solo dopo che un limite è già stato superato. Gli agenti, invece, non hanno alcuna logica in materia.

Nel corso di un'indagine strutturata effettuata con pratiche di ingegneria del controllo (DevOps) e con professionisti in diversi contesti aziendali, ho sviluppato un modello budget di resilienza. Si tratta di un approccio dinamico in cui la capacità assorbente viene ricalcolata in tempo reale e considerata uno strumento consumo, non solo un limite fisso da rispettare.

Il modello integra quattro fonti di segnali principali:

• Il ritmo di utilizzo del budget di errore SLO è l'input principale, poiché mostra la distanza tra il comportamento corrente del sistema e l'impegno che veramente conta.
• La tendenza della latenza al novantesimo percentile indica con maggiore precisione la salute del sistema rispetto a un solo valore assoluto.
• Lo stato di saturazione delle dipendenze mostra un rischio non considerato, dove un esperimento o azione basata su una risorsa condivisa già quasi al limite può causare incidenti non pianificati.
• I segnali di comportamento applicativo, come tassi di completamento delle sessioni, mutamenti nei modelli API o degradazione delle conversioni, anticipano con maggiore accuratezza problemi futuri rispetto alle metriche infrastrutturali tradizionali.

Un modello per condividere la capacità di resilienza

Il budget di resilienza è un concetto condiviso, non una soglia fissa. Ogni esperimento di caos, o azione autonoma, riduce la capacità attualmente disponibile. Nei grandi team multiformi dove agenti e sperimentazioni condividono dipendenze comuni, la capacità deve essere gestita come risorsa condivisa.

Se non esiste un registro chiaro per tracciare come si consuma questa risorsa, due team potrebbero avviare esperimenti su componenti in comune e, combinando l’impatto, generare un’esplosione di incidenti non pianificati. Quando si aggiungono gli agenti autonomi, che operano completamente al di fuori di questo registro, il sistema cade in una situazione complessa e non controllabile.

I modelli linguistici all’aiuto – e i loro limiti

Alcune organizzazioni stanno già testando la possibilità di utilizzare modelli linguistici di grandi dimensioni (LLM) per sviluppare ipotesi di