Agent AI nella gestione incidenti, i fallimenti che si propagano silenziosi

Un agente AI sceglie lo strumento sbagliato, nessun allarme suona, l’errore scivola tra servizi fino a diventare un guasto serio. Questi fallimenti non hanno un “big bang”. Si accumulano, si intrecciano, restano invisibili finché è tardi¹.

Le organizzazioni già affidano a sistemi AI rilevamento, triage e rimedio degli incidenti. In alcuni casi gli agenti agiscono al posto dei team, verso operazioni digitali autonome. L’AI può velocizzare le attività, migliorare il coordinamento, prevenire incidenti ripetuti. Il rischio cambia: allucinazioni, problemi di groundedness, drift del modello, violazioni dei guardrail, scelte di tool sbagliate. Queste modalità di fallimento sono meno prevedibili e più difficili da rilevare per ITOps e DevOps¹.

Quasi il 70% degli incidenti nasce da cambiamenti. Quando l’AI introduce cambi a velocità macchina, serve rispondere allo stesso ritmo¹.

Primo punto, i guardrail. Più autonomia concede un’azienda, più lontano può correre una decisione sbagliata. Servono controlli che impongano a un agente di fermarsi, autosegnalare o passare la mano a un umano quando devia dal comportamento atteso. Questi limiti devono contenere il rischio senza creare attrito inutile per i team di ingegneria. L’obiettivo è intervenire prima che un’anomalia diventi incidente¹.

Secondo, monitorare gli agenti con altri agenti. Quando i sistemi aumentano di numero e complessità, l’osservabilità solo umana non regge. Un livello di supervisione automatica legge i segnali, riconosce comportamenti anomali, decide quando scalare verso un responder. In architetture agentiche, il responder può essere un altro agente dedicato alla mitigazione, non per forza una persona¹.

Terzo, scegliere metriche che contano. Ogni agente richiede misure pertinenti al lavoro che svolge. Il set comune include: successo del task, groundedness, latenza, selezione degli strumenti, tassi di timeout, errori e retry, efficienza dei passaggi, costo, violazioni di sicurezza ed etica, tasso di escalation umana. Un approccio prevede un golden set di comportamenti attesi, per verificare che l’agente risponda correttamente a casi noti.

Quarto, valutare in modo continuo. Le prestazioni non restano fisse. Cambiano se si aggiorna il modello. Possono degradare anche con infrastruttura sana. Ogni calo va trattato come un problema operativo, con alert verso il team giusto. La valutazione avviene su due tempi: quasi in tempo reale per catturare i segnali, e con review post-incident per analizzare cosa è successo e come hanno agito gli agenti. Le review chiedono: l’escalation è stata corretta? Gli strumenti scelti erano quelli giusti? Serviva l’intervento umano?¹

Un esempio: un agente di Site Reliability Engineering indaga appena rileva un’anomalia. Quando arriva la notifica all’on-call, l’agente può già aver eseguito triage e diagnosi. Collegare l’agente a codice, telemetria, infrastruttura e strumenti di collaborazione rende più accurate le indagini. Se l’incidente si ripete, l’agente può attivare workflow di mitigazione pre-approvati¹.

Si parte in piccolo. I casi a basso rischio, come triage e diagnosi, costruiscono fiducia. Poi si estende l’automazione lungo il ciclo dell’incidente. La supervisione umana resta essenziale per gli incidenti complessi. La direzione indicata è di collaborazione tra ingegneri e agenti¹.