"Gli attaccanti possono dedicare tempo illimitato ad espugnare un singolo punto debole, i difensori devono coprire sempre tutto" Sergio Ajani, Services & Solutions Design Director di Innovaway, sintetizza così l'asimmetria che da sempre governa il rapporto tra chi attacca e chi difende, con la novità che l'AI ha alzato di molto la pressione nei Security Operation Center, che adesso sono costretti all’ennesima evoluzione.

Il momento non è facile perché innovare richiede competenze e fondi, e spesso scarseggiano entrambi, o comunque vengono erogati con il contagocce. Il problema dei SOC è endemico, come spiega Ajani: il SOC per primo livello non è mai stato una scelta di business, "nasce da un'esigenza che è legata alla presenza nel mondo dei buoni e dei cattivi". Per questo motivo è sempre stato inquadrato come un costo necessario e non come un vantaggio competitivo.

Partecipa agli ItalianSecurityAwards 2026 ed esprimi il tuo voto premiando le soluzioni di cybersecurity che reputi più innovative

Un’evoluzione necessaria

In che cosa consiste l’evoluzione: il SOC tradizionale, spiega il manager, nasceva in un contesto in cui il numero di attacchi (e per conseguenza dell’attività difensiva) era gestibile da un team di persone fisiche ragionevolmente dimensionate. Quel mondo, "purtroppo non esiste più", perché gli attacchi sono automatizzati e le infrastrutture cloud permettono di raggiungere livelli di impatto enormi senza competenze particolari. Il numero di alert giornalieri, spiega Ajani, "supera qualunque capacità umana sostenibile, anche perché i team non possono crescere all'infinito".

Sergio Ajani, Services & Solutions Design Director di Innovaway

È questo il punto in cui l'automazione basata su AI "non è più una scelta opzionale: è in qualche modo una risposta obbligata a un problema di scala" perché consente di condurre analisi automatizzate e lasciare agli operatori solo la gestione delle eccezioni. "La domanda non è più se l'automazione intelligente sia plausibile o meno, è piuttosto come usarla in modo che amplifichi le capacità umane senza creare nuovi punti ciechi".

Del resto, c’è un dato incontrovertibile che bisogna accettare, e che è quello a cui si faceva riferimento all’inizio: "le risorse, il tempo e l'attenzione che gli attaccanti dedicano in questa epica lotta tra il bene e il male sono più ampie di quelle che i difensori da soli possono mai affrontare. Un attaccante può colpire dieci clienti, e ciascun cliente si trova più o meno da solo".  Con l'avvento dell’AI questo squilibrio non è cambiato nella sostanza, ma è cresciuto nei numeri e soprattutto nei tempi: "grazie agli strumenti AI l'attaccante è in grado di analizzare le falle di ogni software appena viene pubblicato, ancora prima che nasca l’esigenza di difenderlo. In più, una volta i threat actor dovevano orchestrare campagne di attacco complesse, adesso il cloud permette attacchi su larga scala senza installare un trojan su ciascuna macchia".

Non è tutto oro quello che luccica

Alla domanda su quanto sia effettivamente matura oggi l'automazione AI del SOC di primo livello, Ajani risponde con luci e ombre. Tra le luci elenca il triage automatico degli alert, la prioritizzazione e soprattutto la riduzione del rumore di fondo: "un'azienda enterprise riceve milioni di alert; l'AI aiuta a separare il segnale dal rumore". A questo si aggiungono correlazioni di eventi che prima si facevano su regole statiche e che oggi, con algoritmi più flessibili, permettono di lavorare su volumi di log che nessun essere umano potrebbe gestire, e neanche le tecnologie tradizionali. Anche la risposta a incidenti noti e ripetitivi, aggiunge Ajani, può essere corretta tramite playbook automatizzati.

Le ombre, invece, riguardano due aspetti distinti. Il primo è culturale: "fidarsi troppo dell'AI", con riferimento a bias e allucinazioni. La questione è semplice: "è difficile che un'AI possa controllare se stessa in maniera efficace, quindi c’è il rischio che con le allucinazioni l'AI inventi degli elementi di cui gli operatori si fidano". Un esempio pratico è la situazione in cui “si smette di interrogarsi e di mettere in discussione le risposte o le decisioni dell'AI, e si finisce per non accorgersi che l'AI ha classificato come falso positivo quello che invece è un vero positivo".

Il secondo è legato a scenari nuovi, attacchi mai visti e contesti ambigui che l'AI non è in grado di gestire, e che quindi richiedono una capacità di giudizio umana. In questa seconda circostanza lo strumento "può aiutare, ma non potrà mai sostituire, almeno prevedibilmente nei prossimi anni, un agente AI completamente autonomo". Una visione che ha poco o nulla a che vedere con la dimensione aziendale, perché l'approccio a questo cambio di prospettiva nasce dal modo in cui l'azienda affronta il cambiamento, prima in termini di knowledge management e change management che di struttura organizzativa.

C'è poi un livello di rischio più tecnico, che riguarda l'attacco diretto ai modelli, uno scacco matto che l'attaccante compie cercando di colpire non l'infrastruttura, ma il modello stesso. È attuabile nel momento in cui un attaccante conosce il funzionamento di un sistema AI e "abusa dei meccanismi per ridurre il rumore, con l’obiettivo di camuffare l'attacco e farlo andare avanti". A questo si somma un limite strutturale dell'AI applicata alla sicurezza, ossia il fatto che "l'AI, almeno al momento, è decontestualizzata rispetto al business, quindi può bloccare anche attività perfettamente legittime, magari critiche" argomenta Ajani. Certo, è un problema condiviso con l'essere umano, con un'aggravante: si corre il rischio che, tra le tonnellate di dati raccolti, nessuno vada mai a controllare, salvo quando poi è troppo tardi.

Posto che l’automazione è irrinunciabile, la via d’uscita che Ajani propone è strutturare l’automazione con presidio costante, ossia con il famoso "human in the loop per le decisioni ad alto impatto, o comunque con una attività continuativa di verifica", come peraltro previsto anche dall'AI Act. Resta però un nodo aperto su cui Ajani mette l’accento: "se devo controllare tutto, il controllo non mi serve più".

Da analista a supervisore: le competenze che cambiano

Sopra abbiamo parlato di competenze. È bene chiarire che non s’intende uno stravolgimento del dominio tecnico, ma di uno spostamento di ruolo, perché "cambia l'approccio: dall’analista che interpreta gli alert a un supervisore di un sistema intelligente", ossia un team leader con sotto di sé degli agenti che lavorano per lui e di cui è supervisore e coordinatore". Per il resto le competenze di dominio, insiste Ajani, restano quelle di sempre: "un attacco resta un attacco, che può essere uno zero-day, un penetration test, mille cose diverse", a cambiare è la capacità di comprendere “come ragiona il modello, dove sbaglia, com’è stato addestrato, e di conseguenza saperlo interrogare nella maniera opportuna per ottenere risultati utili".

Non ultimo, cresce il peso del pensiero critico, che diventa prezioso per mettere in discussione l'output dell'AI quando non è completo o è sospetto. In questo caso ha grande importanza il proprio know-how per individuare le eccezioni in una mole consistente di dati.

Si tratta di sfumature e di dettagli che, per quanto piccoli, faranno sempre di più la differenza fra un uso vantaggioso e svantaggioso dell’AI. Posto che tutti devono tenere a mente un pilastro importante: l’AI non può sostituire l’analista umano perché non si può governare un ambito che non si conosce. Ajani chiarisce con un esempio pratico: "io non sono uno sviluppatore, prendo Claude Code e gli chiedo di scrivermi del codice. Probabilmente quello che produce l’AI funzionerà, ma non ho alcuna capacità di analizzare ciò che ha fatto, di migliorarlo, di capirne i punti deboli o di intuire l’esposizione al rischio attuata da quel codice". La stessa AI, interrogata da uno sviluppatore, può aiutarlo a lavorare meglio, con più efficienza ed efficacia.

Lo stesso concetto si applica ai processi: "se il processo di gestione degli incident di sicurezza non era corretto, non è che l'AI lo fa funzionare. Semplicemente verrà calata in un processo che era già rotto, e che quindi continuerà a non funzionare". Da qui l'esigenza di indicatori concreti per misurare i risultati effettivi dell'automazione: la riduzione dei tempi di verifica e risposta, il numero di falsi positivi, quanti alert vengono processati senza escalation verso gli operatori umani, la qualità complessiva degli alert, e non ultimo, il modo in cui gli operatori stessi vivono il rapporto con questi sistemi.

Verso il SOC del futuro

Guardando a un orizzonte di medio termine, Ajani prevede un'AI sempre più agentica rispetto ai modelli LLM tradizionali, con agenti sempre più specializzati e percepiti come più capaci. Su attacchi o superfici considerate sicure al cento per cento, gli agenti diventeranno "pressoché autosufficienti anche nella remediation", convergendo con strumenti già esistenti come i runbook, ancora oggi lanciati manualmente dall'operatore.

Il vero elemento distintivo, secondo Ajani, sarà un livello di governance AI vero e proprio, sopra gli agenti, "ma qualcosa che si pone come guida, con una logica più formale, per rendere tutto spiegabile: se blocco un processo o faccio un’eccezione lasciandolo passare, deve essere chiaro il perché". In questo scenario l'operatore diventerà un AI SOC operator analyst, capace di dialogare con il sistema di governance senza interrogare direttamente i singoli agenti. Un modello che, per Ajani, porterà anche un effetto di democratizzazione simile a quello vissuto con la diffusione degli LLM: "aziende meno pronte da un punto di vista infrastrutturale potrebbero avere accesso a strumenti molto più evoluti di prima". Tuttavia, restano fermi i limiti di knowledge management: “se usi una cosa che non sai come funziona e non sai cosa fa, il problema c'è sempre. Però almeno lo strumento ce l'hai".