Agente IA per le operazioni IT: ticket interni, accessi, monitoraggio e documentazione

Il problema

Le operazioni IT interne non si fermano mai, ma il team che le gestisce sì. Un'analisi Jitbit su circa 1.000 aziende, regolarmente citata nel settore del supporto, collocava nel 2017 il volume medio gestito da un tecnico a 21 ticket al giorno, con un tempo di risoluzione medio di 82 ore. Sono dati datati, presentati dagli stessi autori come una base storica più che un obiettivo attuale, da trattare come un ordine di grandezza e non come un dato aggiornato.

Sul tempo dedicato per ticket, Endsight, un fornitore di supporto gestito, indica 63 minuti in media sui propri 10.923 utenti monitorati per 12 mesi. È un dato interno a una sola azienda, non verificato da terzi: da considerare come un indizio, non come uno standard di settore.

Il punto documentato più solido riguarda gli accessi. Una ricerca di Wing Security ripresa da The Hacker News nel 2024 stima che il 63% delle aziende conta ex dipendenti che mantengono un accesso a dati dell'organizzazione, e il 43% a repository di codice su GitHub o GitLab. Ogni richiesta di accesso o di revoca che si trascina in una coda di ticket interni è un candidato diretto a questo tipo di statistica.

Questo ritardo di gestione ha una seconda conseguenza, meno visibile del rischio di sicurezza: la coda di ticket stessa diventa illeggibile. Quando le richieste urgenti (un accesso bloccato che impedisce di lavorare) si mescolano con le richieste di routine (una domanda già risposta dieci volte nella base di conoscenza), il team IT passa tanto tempo a smistare quanto a risolvere. Buona parte di questa coda non dovrebbe mai raggiungere un umano: è esattamente il tipo di smistamento che un agente che legge la documentazione esistente può assorbire prima che il ticket attenda il proprio turno.

Cosa fa l'agente, passo dopo passo

Un agente IA autonomo dedicato alle operazioni IT gira in continuo, nel proprio ambiente isolato, e sorveglia la coda di ticket senza mai dormire.

Inizia categorizzando ogni ticket in ingresso in Jira: domanda già nota, richiesta di accesso, incidente tecnico. Per le richieste già documentate, risponde direttamente citando la procedura trovata nella base Notion del team. Per una richiesta di accesso a uno strumento o un repository, apre un ticket strutturato con tutte le informazioni necessarie alla decisione, invece di eseguirla da solo.

Sul fronte monitoraggio, l'agente sorveglia le allerte segnalate da Datadog e le correla con i commit o i deployment recenti visibili in GitHub: un aumento di latenza che segue da vicino un deployment non viene trattato come un incidente isolato. Quando la correlazione è netta, apre un'issue GitHub documentata, con il contesto utile per il team tecnico. Ogni ticket rimasto bloccato, ogni allerta critica o ogni richiesta di accesso in attesa attiva una notifica Slack verso il team IT. Ogni azione, ticket creato, allerta correlata, messaggio inviato, viene registrata nella timeline dell'agente, con il suo stato esatto.

Un esempio concreto illustra bene la meccanica: un dipendente apre un ticket un venerdì sera per richiedere l'accesso a un repository GitHub preciso, nell'ambito di un progetto trasversale. L'agente categorizza la richiesta, verifica che sia completa (repository interessato, giustificazione, durata desiderata), poi prepara un ticket strutturato pronto per essere validato da un responsabile IT già lunedì mattina, invece di lasciare che la richiesta dorma in una coda generica fino a quando qualcuno non la noti per caso.

Le integrazioni utilizzate

Jira resta la coda di riferimento dei ticket interni. L'agente vi cerca le richieste (search_issues), consulta il dettaglio (get_issue) e può creare una nuova issue strutturata, secondo le azioni coperte dal proprio grant.

GitHub serve a correlare un'allerta tecnica con una modifica di codice: elenco dei commit recenti (list_commits), dettaglio di una pull request (get_pull_request), e creazione di un'issue documentata (create_issue) quando la correlazione è stabilita.

Datadog fornisce il segnale grezzo di supervisione, che l'agente consulta senza mai sostituire lo strumento di monitoraggio stesso. Notion ospita le procedure e i runbook che l'agente consulta prima di rispondere a una richiesta, e Slack porta le notifiche al team IT in tempo reale.

Ciò che resta all'essere umano

L'agente prepara e avvisa, non esegue mai un cambiamento di accesso o di infrastruttura di propria iniziativa. Concedere o revocare effettivamente un accesso resta un'azione umana: l'agente apre la richiesta documentata in Jira, una persona dell'IT la esegue e la richiude.

La criticità reale di un'allerta ambigua, quella che non corrisponde a nessun deployment recente identificabile, viene decisa da un umano prima di ogni escalation oltre una notifica Slack. Decidere e applicare un correttivo di codice o di infrastruttura resta, senza sorpresa, un lavoro da ingegnere. E come per ogni agente Atako, un admin deve concedere e adeguare i grant su Jira, GitHub e Datadog, azione per azione, con un ambito in lettura o in lettura e scrittura definito esplicitamente.

Questo limite vale anche per l'agente stesso: se si imbatte in una situazione che esce da ciò che il suo contesto aziendale copre, un rinnovo di licenza insolito, una richiesta di accesso a un sistema non documentato, non forza una risposta approssimativa. Notifica il team IT e lascia il ticket aperto per una gestione umana, invece di indovinare una procedura che non esiste nella sua base di conoscenza.

Risultato misurabile

Il beneficio più diretto è la riduzione del tempo morto tra l'arrivo di un ticket o di un'allerta e la sua prima presa in carico. Un agente che gira 24 ore su 24 può categorizzare un ticket aperto una domenica sera e preparare la richiesta di accesso corrispondente prima dell'arrivo del team il lunedì, invece di lasciare la richiesta in attesa nella coda.

Il secondo beneficio riguarda direttamente il problema documentato da Wing Security: sistematizzando l'apertura di un ticket di revoca non appena viene segnalata un'uscita, l'agente riduce il ritardo tra l'evento scatenante e l'azione dell'IT, il che limita la finestra durante la quale un accesso resta attivo inutilmente, una finestra che, senza sorveglianza continua, può estendersi su settimane o addirittura mesi secondo le constatazioni citate sopra.

Ogni ticket aperto, ogni allerta correlata, ogni messaggio inviato resta consultabile nell'audit trail di Atako, esportabile in CSV per il team IT fino a 50.000 righe. Questa tracciabilità completa facilita anche gli audit di sicurezza interni: ritrovare chi ha richiesto un accesso, quando, e su quale base la richiesta è stata formalizzata non richiede più di ricostruire una cronologia a partire da più strumenti diversi.

Un agente IT rientra nel piano Standard, 20 euro al mese per slot, con 1.000 crediti inclusi ogni mese per coprire le chiamate al modello. Il numero di ticket trattati o di collaboratori che interagiscono con l'agente non ha alcun impatto su questo prezzo, conta solo il numero di agenti attivi in simultanea. Un team IT ridotto può quindi far girare un solo agente sull'insieme dei propri ticket interni, delle proprie allerte di monitoraggio e delle proprie richieste di accesso, senza dover moltiplicare gli slot per coprire ogni flusso separatamente, il che mantiene il costo prevedibile anche quando il perimetro dell'agente si allarga progressivamente a nuovi strumenti o nuovi team interni nel corso dei mesi.