L’AI indaga autonomamente sugli incidenti IT, con ticket sempre più automatizzati

L’ai indaga autonomamente. Microsoft ha sviluppato un agente AI per la rete di produzione di Azure in grado di indagare autonomamente sugli incidenti. In caso di allarme, ad esempio un link instabile alle due di notte, l’agente recupera lo stato dei dispositivi, analizza i dati telemetrici, correla le modifiche recenti e classifica il guasto.

L’agente scrive quindi un riepilogo dell’incidente prima che l’ingegnere di turno abbia completato l’accesso. Arun Malik, ingegnere di Azure Networking, descrive nel blog tecnico dell’azienda anche la capacità dell’agente di individuare la correzione necessaria.

L’ai indaga autonomamente: perché è importante

Questa ricostruzione rappresenta un lavoro manuale per l’ingegnere di turno: richiede l’apertura di cinque schede, una per ciascun sistema, e la ricomposizione dell’incidente da frammenti. Se questo compito viene svolto dall’agente, la coda del service desk si smaltisce più rapidamente e si riduce il tempo di lavoro umano necessario per ogni incidente, con conseguente diminuzione dei costi.

Tuttavia, è fondamentale che l’agente non possa modificare autonomamente la produzione. Per questo motivo, Malik definisce quattro confini: identità, strumenti, modifiche e tempo.

Nel caso del confine temporale, durante il primo rilevamento di un incidente, l’agente procede con ragionamenti ex novo, comportando costi elevati e risultati variabili. Quando lo stesso processo ha successo ripetutamente, si trasforma in un playbook che non richiede ulteriori chiamate al modello. Secondo Malik, ridurre il ragionamento in tempo reale significa diminuire i costi, aumentare la riproducibilità e limitare le possibilità di allucinazioni o attacchi.

Nel flusso d’esempio presentato nel post, un modello legge l’output del comando ‘show interface status’, un testo non strutturato. Il risultato viene convertito in dati secondo uno schema predefinito, quindi un codice deterministico convalida e seleziona l’azione appropriata. L’esecuzione del passo ‘recover-interface’ si arresta in attesa dell’intervento umano.

In questo modo, la figura di turno passa dall’eseguire all’approvare: per ogni ticket di quel tipo, viene richiesto il via libera, non più l’indagine. Questi quattro confini sono progettati per prevenire danni derivanti dall’automazione.

Il primo confine riguarda l’identità: l’agente opera con i permessi reali della persona che lo ha invocato e, se necessario, utilizza un’identità di servizio, scegliendo quella più restrittiva tra le due. Le policy di accesso appartengono ai team proprietari degli strumenti e vengono modificate tramite pull request, in cui il team è revisore obbligatorio. Nel modello proposto da Malik, l’approvazione della merge concede l’accesso, mentre il revert lo revoca.

Il secondo confine limita la libertà d’azione: ogni funzionalità è accessibile attraverso un’interfaccia tipizzata univoca, ogni strumento viene autorizzato individualmente e ogni chiamata viene registrata. L’esecuzione di comandi da riga di comando è consentita solo se esposti come strumenti specifici e dichiarati.

Per le chiamate che superano il confine di fiducia, Malik suggerisce l’utilizzo di MCP (Minimum Credential Privilege), con isolamento delle credenziali, un tema già affrontato da Tom’s Hardware in relazione alla necessità di governare un agente prima di attivarlo.

Il terzo confine separa la lettura dalla scrittura: le diagnosi vengono eseguite autonomamente, mentre qualsiasi modifica alla produzione viene sospesa e richiede l’approvazione umana. Il controllo è implementato nel motore di esecuzione tramite codice, e la credenziale utilizzata per apportare la modifica rimane al di fuori della portata del modello.

La fiducia necessaria per saltare l’approvazione si ottiene attraverso procedure specifiche e in base al tipo di azione, non in base all’intelligenza del modello. Questo è dimostrato da un esempio nel post: a un agente che viene richiesta una configurazione BGP per un nuovo dispositivo, il risultato appare corretto ma, con una frequenza significativa, contiene un ASN inventato, richiama una route policy inesistente o ignora le convenzioni del datacenter.

Questi confini hanno un costo da valutare rispetto al tempo risparmiato sull’indagine. Ogni scrittura richiede l’intervento umano, anche alle due di notte, e ogni playbook deve essere scritto e mantenuto aggiornato da qualcuno. L’agente elimina il lavoro ripetitivo dell’indagine per ogni ticket, consentendo alla persona di turno di dedicare il proprio tempo esclusivamente all’approvazione, mentre la creazione di un playbook riduce ulteriormente i costi associati agli incidenti già affrontati.

Cosa cambia e quali sono gli effetti

Senza questi blocchi nel codice, l’impatto economico cambia. George Spafford, vice president analyst, sottolinea che “le policy aziendali scritte non possono impedire fisicamente a un agente di commettere errori distruttivi”. La stessa analisi prevede che entro il 2029 almeno il 70% delle organizzazioni con agenti AI in produzione nelle operazioni IT subirà incidenti rilevanti, in parte dovuti a controlli di runtime insufficienti.

Tom’s Hardware aveva già evidenziato l’importanza di un controllo deterministico prima dell’azione. Il progetto OWASP GenAI indica, per un eccesso di autonomia (LLM06:2025), estensioni minime e granulari, evitando quelle aperte come l’esecuzione di comandi shell, e richiede l’approvazione umana per azioni ad alto impatto.

Inoltre, si raccomanda di implementare l’autorizzazione nei sistemi a valle, anziché affidarsi al modello per decidere se un’azione è permessa. Qualsiasi scrittura sulla produzione deve essere sospesa e attendere l’intervento umano.

Nella documentazione di Azure SRE Agent, il prodotto Microsoft per la gestione degli incidenti cloud, ogni piano di risposta ha un livello di autonomia predefinito, “Autonomous”. La pagina consiglia di iniziare con “Review” per i piani nuovi, dove le azioni proposte attendono l’approvazione, e di passare all’autonomia completa solo dopo aver validato l’indagine dell’agente.

Anche senza il motore di esecuzione e le pull request descritte nel post, un team IT piccolo può ottenere alcuni dei vantaggi del sistema applicando lo stesso principio: l’agente agisce con i permessi della persona che lo avvia, senza condividere credenziali con altri utenti, e riceve accesso a pochi strumenti specifici anziché a una shell aperta. Un registro degli agenti tiene traccia di quali esistono e con quali accessi.

Andrew Burt, in un’analisi su Harvard Business Review riportata da Tom’s Hardware, paragona gli agenti al malware e propone il principio del privilegio minimo, l’utilizzo di sandbox e un registro delle azioni esterno all’agente. A decidere cosa può toccare l’agente sono i team proprietari degli strumenti, che nel modello Microsoft approvano gli accessi tramite pull request, stabilendo per ogni procedura quando una scrittura può saltare l’approvazione.

Se un agente deve essere messo in produzione in queste ore e manca un motore di esecuzione dedicato, la soluzione più pratica è utilizzare un agente che indaghi in sola lettura, lasciando le scritture a una persona: l’indagine di ogni ticket resta all’agente, mentre la scrittura sulla produzione viene eseguita dalla persona di turno.

Fonte e approfondimento su l’ai indaga autonomamente: articolo originale.

* Contenuto realizzato con l'ausilio di sistemi di intelligenza artificiale.