Il turno dell'analista con gli agenti AI: cosa cambia nel SOC

Con gli agenti di intelligenza artificiale (AI) il lavoro dell'analista SOC cambia nel tipo di fatica, non nella responsabilità. Si alleggerisce lo smistamento meccanico degli allarmi e la raccolta del contesto; cresce invece il peso del giudizio: leggere proposte motivate, decidere se approvarle e poterne spiegare le ragioni. Il rischio nuovo è la ratifica di routine, l'approvazione data senza aver capito: si previene con accorgimenti organizzativi, non con altro software.

SOC è l'acronimo di Security Operations Center, il centro operativo di sicurezza: persone, processi e tecnologie che osservano i sistemi aziendali, valutano ciò che non torna e coordinano la risposta. Questo articolo racconta come cambia un turno tipo quando al fianco dell'analista lavorano agenti AI, quali competenze diventano più importanti e come ridisegnare il ruolo senza trasformare le persone in timbri di approvazione.

Il prima: un turno fatto di code

Nel modello tradizionale la giornata dell'analista è scandita dalla coda degli allarmi. Il SIEM (Security Information and Event Management, la piattaforma che raccoglie e correla i registri dei sistemi) produce segnalazioni; l'analista le apre una alla volta, ricostruisce il contesto a mano — chi è l'account, da quale dispositivo, a che ora, cosa è successo prima e dopo — e decide se archiviare, approfondire o escalare, cioè passare il caso a un livello superiore secondo criteri di priorità ed escalation definiti.

Gran parte del tempo se ne va in attività meccaniche: copiare identificativi da una console all'altra, confrontare orari, escludere i falsi allarmi già visti. Il giudizio arriva alla fine di questo percorso, spesso su un numero ridotto di casi, perché il resto del turno è stato consumato dallo smistamento. La qualità del triage, cioè della prima valutazione e smistamento degli allarmi, dipende così dalla resistenza della persona a un lavoro ripetitivo, non solo dalla sua competenza.

Il dopo: proposte motivate da valutare

Con gli agenti AI il flusso si rovescia. Gli agenti osservano le fonti collegate, correlano i segnali e presentano all'analista casi già composti: cosa è stato osservato, perché è rilevante, quali informazioni mancano e quale intervento viene proposto, con le conseguenze attese. L'analista non parte più da una coda di righe ma da un numero minore di proposte motivate, e il suo lavoro diventa valutarle: confermare, chiedere un approfondimento, rifiutare con una motivazione.

Ciò che non cambia è il punto decisivo: la responsabilità di chiudere, approfondire o escalare resta di una persona. La pubblicazione SP 800-61 revisione 3 del NIST (National Institute of Standards and Technology, l'istituto statunitense per gli standard tecnologici) descrive la risposta agli incidenti come parte della gestione del rischio, con ruoli e responsabilità definiti lungo tutte le attività: automatizzare il triage non sposta questa responsabilità, la rende solo più visibile.

Le competenze che diventano più importanti, non meno

Se il carico meccanico si riduce, le competenze che contano si spostano verso il giudizio:

• Leggere criticamente una proposta. Capire da quali fonti nasce una segnalazione, cosa è osservato e cosa è ipotizzato, quali informazioni mancano. Una proposta ben scritta non è una proposta giusta.
• Conoscere il contesto aziendale. Un accesso amministrativo fuori orario può essere una manutenzione concordata o un problema: lo distingue chi conosce persone, turni e sistemi, non il modello.
• Valutare le conseguenze. Ogni intervento ha un impatto operativo: sospendere un account può fermare un'attività. La decisione richiede di pesare rischio e continuità del lavoro.
• Motivare le proprie scelte. Approvare o rifiutare con una motivazione registrata è ciò che rende il caso ricostruibile dopo mesi, davanti a un audit o a una verifica interna.

Questa direzione non è una particolarità di un singolo prodotto: anche la documentazione Microsoft sugli agenti di Security Copilot, in anteprima pubblica alla data di consultazione, indica che le organizzazioni devono rivedere le decisioni dell'agente prima di agire sui suoi output. Il mercato intero conferma lo stesso confine: gli agenti preparano, le persone decidono.

Il rischio della ratifica superficiale

C'è un effetto collaterale noto a chi ha introdotto automazioni: quando le proposte sono quasi sempre ragionevoli, l'analista tende ad approvarle senza leggerle. La ratifica diventa un gesto di routine e il controllo umano — il presidio che giustifica l'intero impianto — si svuota dall'interno. Il caso in cui la proposta è sbagliata arriva proprio quando l'attenzione è più bassa.

I rimedi sono organizzativi e vanno decisi quando si ridisegna il ruolo, non dopo il primo incidente:

• Motivazione obbligatoria. Approvare o rifiutare richiede una ragione scritta, anche breve. Chi deve scrivere perché, legge.
• Verifiche a campione. Una parte dei casi approvati viene riesaminata da un collega o dal responsabile, con cadenza concordata, per misurare la qualità delle decisioni e non solo quella delle proposte.
• Doppia approvazione per gli interventi più delicati. Le azioni con impatto forte — per esempio la sospensione di account o modifiche alle protezioni dei dati — richiedono due responsabili, come già avviene in molti processi autorizzativi.
• Rotazione e formazione sui casi. I casi rifiutati e quelli anomali diventano materiale di discussione periodica del team, così il giudizio si allena sulle decisioni reali.
• Attenzione ai momenti scoperti. Di notte e nei fine settimana la tentazione della ratifica rapida cresce: il presidio fuori orario va progettato con regole chiare su cosa attende e cosa no.

Esempio illustrativo: il martedì di un'azienda logistica

Esempio illustrativo. Lo scenario seguente è inventato e non racconta un incidente avvenuto presso un cliente.

Prima dell'introduzione degli agenti. Martedì mattina, sede di un'azienda logistica con due persone dedicate alla sicurezza. Durante la notte la piattaforma ha accumulato una quarantina di segnalazioni: tentativi di accesso falliti da paesi diversi, un servizio riavviato, un account amministrativo attivo fuori orario, una condivisione di rete modificata. L'analista apre i casi in ordine. A metà mattina ha archiviato come rumore la maggior parte dei tentativi di accesso e non ha ancora collegato l'accesso amministrativo alla modifica della condivisione: due allarmi lontani nella coda. Il collegamento arriva nel pomeriggio, quando un collega solleva un dubbio su un file.

Dopo l'introduzione degli agenti. La stessa notte produce tre casi composti invece di una coda. Il primo caso mette insieme l'accesso amministrativo fuori orario e la modifica alla condivisione: una timeline unica, le informazioni mancanti segnalate, la proposta di isolare l'account e di verificare i trasferimenti di dati da quella condivisione. L'analista legge la motivazione, nota che l'accesso coincide con una manutenzione che risulta pianificata solo a metà, chiede un approfondimento e nel frattempo approva la misura più contenuta e reversibile tra quelle proposte. Un secondo caso, con un'autorizzazione scaduta, è già fermo al controllo dei limiti e richiede una nuova decisione sul piano aggiornato. Il turno si chiude con le motivazioni registrate e il caso principale ancora aperto, ma presidiato.

La differenza non è «più veloce»: è che il giudizio dell'analista si è concentrato sul caso che lo meritava, invece di essere consumato dallo smistamento.

Il confine proposta-decisione in OverZeus

OverZeus è costruito su questo confine. Tre agenti mostrano bene come il lavoro si divide:

• Odysseus coordina: collega gli indizi provenienti dai moduli in una timeline unica e li riunisce in un piano comprensibile, senza dare per certa una compromissione.
• Ares organizza priorità, indagini ed escalation e propone piani di contenimento: esegue soltanto le misure elencate e approvate.
• Themis applica privilegi, approvazioni e limiti operativi con controlli esterni al modello AI: un'operazione con autorizzazione scaduta viene bloccata e rimandata a una nuova decisione.

Intorno a loro, Hermes porta la proposta al responsabile sull'app e raccoglie la decisione — l'assenza di risposta non viene interpretata come autorizzazione — e Mnemosyne conserva fonti, proposte, autorizzazioni ed esiti, segnalando le lacune senza inventare ricostruzioni. Per chi sta valutando l'introduzione di agenti nel proprio SOC, la guida ai criteri di scelta di un SOC AI aiuta a verificare che questo confine sia dichiarato e dimostrabile, e i limiti del monitoraggio automatico e il ruolo della verifica umana completano il quadro.

Ridisegnare il ruolo, non solo gli strumenti

Introducendo agenti AI nel SOC non si elimina l'analista: si cambia ciò che gli si chiede. Meno smistamento meccanico, più valutazione delle proposte, responsabilità invariata e più esplicita. Per il responsabile del SOC o per chi gestisce le risorse umane tecniche il lavoro vero è ridisegnare mansioni, criteri di approvazione e verifiche a campione insieme all'adozione degli strumenti: è lì che si decide se il controllo umano resta sostanza o diventa un timbro.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus