Agente IA per il triage degli errori CI e la risposta agli incidenti

Un deployment che fallisce nel cuore della notte non dovrebbe più svegliare nessuno. Eppure, in molti team, è ancora un ingegnere di reperibilità ad aprire i log a freddo, cercare il commit colpevole e scrivere il messaggio Slack che avvisa gli altri. Un agente IA autonomo può occuparsi di questo primo passo, senza mai sostituire il giudizio umano sulla causa radice o sulla correzione.

Il problema

I numeri sull'affidabilità delle pipeline CI/CD non sono buoni. Secondo il rapporto 2026 State of Software Delivery di CircleCI, il tasso di successo delle build sul branch principale è sceso al 70,8%, il livello più basso osservato in cinque anni e ben sotto la soglia del 90% raccomandata dallo stesso fornitore (CircleCI, 2026). In concreto, circa tre tentativi di merge su dieci falliscono ancora prima di arrivare in produzione.

Sul fronte incidenti, il rapporto State of Incident Management di Runframe, pubblicato a inizio 2026, rileva che la quota di tempo di ingegneria assorbita dal lavoro operativo di routine (rispondere alle allerte, classificare gli errori, far risalire l'informazione) è tornata al 30%, in aumento per la prima volta in cinque anni nonostante gli investimenti in IA (Runframe, 2026). Lo stesso rapporto stima che circa due terzi delle allerte generate ogni giorno vengano ignorate per mancanza di tempo per classificarle correttamente. È un ordine di grandezza da prendere con cautela: il rapporto aggrega più studi esterni e interviste qualitative, non è una misurazione diretta e unica.

Il rapporto DORA 2025 sullo sviluppo software assistito dall'IA va nella stessa direzione su un punto di fondo: l'IA amplifica ciò che già esiste in un'organizzazione, non corregge un processo di triage traballante, lo rende semplicemente più visibile, più in fretta (DORA, 2025). Una pipeline mal sorvegliata resta tale, con o senza IA, finché nessuno osserva gli errori in continuo.

Quest'ultimo punto conta particolarmente per i team che lavorano con una reperibilità ridotta, dove una sola persona mobilitata sorveglia più servizi contemporaneamente. Un errore di build che arriva alle 3 del mattino di solito non aspetta che qualcuno si svegli per essere classificato: o resta ignorato fino al mattino, oppure sveglia qualcuno per un problema che, una volta classificato, si rivela minore. Entrambi gli esiti costano caro, uno in tempo di risoluzione, l'altro in affaticamento da reperibilità accumulato nel tempo.

Cosa fa l'agente, passo dopo passo

Su Atako, questo agente non si attiva una volta per poi fermarsi: gira in continuo nel proprio ambiente isolato. Due meccanismi di ingresso lo alimentano, un webhook in entrata che il team configura per ricevere gli eventi CI/CD, e un'attività cron che l'agente programma da sé per verificare periodicamente lo stato dei workflow nel caso in cui il webhook perda un evento.

Quando arriva un errore, l'agente legge i log e la stack trace del job per classificare il tipo di problema (compilazione, test, dipendenza, deployment), poi correla l'errore con i commit e le pull request recenti per identificare l'autore probabile e la modifica sospetta. Pubblica quindi un riepilogo strutturato su Slack nel canale di reperibilità, con i link diretti al job e al commit incriminato, e apre in parallelo un ticket Jira collegato alla build. Se la gravità supera una soglia definita dal team (deployment bloccato, più servizi coinvolti), parte un'escalation supplementare verso le persone giuste. Infine, redige una prima versione del rapporto d'incidente: cronologia, servizi interessati, log pertinenti, causa sospetta, lasciata volontariamente aperta alla revisione umana invece di essere presentata come una conclusione definitiva.

Le integrazioni utilizzate

Ogni integrazione viene concessa tramite un grant preciso, che limita esattamente ciò che l'agente può fare, mai un accesso generico all'intero strumento.

GitHub e GitLab forniscono la lettura delle pipeline, dei job e dei commit, con una scrittura opzionale per creare o commentare una issue se il grant copre questo scope. Su GitHub, le azioni concrete in gioco sono list_workflow_runs e get_job_logs_download_url lato lettura, create_issue e add_issue_comment lato scrittura.

Slack riceve i riepiloghi di triage tramite post_message, nel canale scelto dal team, con la possibilità di programmare un promemoria tramite schedule_message se un incidente resta aperto troppo a lungo.

Jira porta il ticket d'incidente vero e proprio: create_issue all'apertura, update_issue e transition_issue nel corso della risoluzione, fino alla chiusura.

Datadog, quando il team lo ha collegato, permette all'agente di incrociare le metriche di performance e le tracce applicative con l'errore CI per affinare la propria ipotesi di causa radice. PagerDuty non ha una pagina di integrazione dedicata su Atako per il momento, ma resta utilizzabile come destinazione di allerta tramite un webhook in uscita configurato lato Jira o Slack.

Ciò che resta all'essere umano

L'agente non decide mai da solo di unire una correzione, e non è un dettaglio di progettazione, è il modo in cui Atako struttura l'autonomia. Ogni azione che l'agente può eseguire su GitHub, GitLab, Jira o Slack dipende da un grant esplicito: quali azioni precise sono autorizzate, con quale ambito (sola lettura, o lettura e scrittura). Questo ambito fa fede anche se un'azione di scrittura finisse per errore in un elenco di azioni autorizzate in lettura, e nulla viene mai concesso per impostazione predefinita al semplice collegamento di uno strumento.

Questo lascia tre cose chiaramente dal lato umano. Prima di tutto, l'indagine sulla causa radice e la decisione tecnica della correzione: l'agente fornisce un punto di partenza (log, commit sospetto, storico), non una diagnosi definitiva. Poi, la scrittura e l'unione del codice, un'azione umana per natura, fuori dal perimetro di ciò che l'agente può fare. Infine, il post-mortem: regolare le soglie di criticità, rivedere il runbook, migliorare le regole di triage, un lavoro di squadra che l'agente non sostituisce.

Questa ripartizione riflette il principio dello human-in-the-loop: l'agente assorbe la parte ripetitiva e dispendiosa in termini di tempo del triage, l'essere umano mantiene il controllo sulle decisioni che contano davvero. Per verificare cosa ha effettivamente fatto l'agente, ogni chiamata di integrazione viene registrata, con l'agente coinvolto, l'azione, lo stato (autorizzata ed eseguita, rifiutata da un controllo di grant, o fallita lato fornitore) e la latenza. Questa traccia è visibile nella timeline di attività dell'agente e, per un amministratore, nel registro delle integrazioni di tutta l'azienda, esportabile in CSV.

Risultato misurabile

Il beneficio più diretto è il tempo che intercorre tra il fallimento della build e il momento in cui la persona giusta ha l'informazione completa per agire. Non serve più aspettare che una persona noti l'allerta, apra i log e li confronti manualmente con i commit recenti: l'agente lo fa in continuo, anche alle 3 del mattino, senza mai dormire né cambiare umore in base al carico della settimana. Questo non sostituisce le metriche DORA classiche come la frequenza di deployment o il tempo di ripristino dopo un errore, ma riduce la parte di queste metriche che dipende unicamente dalla disponibilità umana in un dato momento.

Il costo segue il piano Standard di Atako: 20 euro al mese per slot agente, con 1.000 crediti inclusi ogni mese per coprire le chiamate al modello usate dal ragionamento, dalla classificazione e dalla redazione. Per calcolare il ritorno prima di partire, il dettaglio è sulla pagina prezzi.