Gli errori più frequenti quando un'azienda introduce l'intelligenza artificiale nel SOC non sono tecnici, ma organizzativi: automatizzare troppo e troppo presto, non assegnare a una persona la proprietà degli allarmi, partire da dati incompleti, condurre la prova senza criteri di successo e dimenticare evidenze e responsabilità. Li descriviamo uno per uno, con il rimedio pratico per ciascuno, per chi è all'inizio del percorso e vuole evitarli prima di firmare un contratto.
SOC è l'acronimo di Security Operations Center, il centro operativo di sicurezza: l'insieme di persone, processi e tecnologie che osserva i sistemi aziendali, rileva ciò che non torna e coordina la risposta. Introdurre l'AI significa affidare a sistemi software parte del lavoro di analisi — correlare segnali, proporre priorità, preparare ipotesi di intervento — senza spostare la responsabilità delle decisioni. È proprio quando questa distinzione si perde che nascono i cinque errori.
Errore 1: automatizzare tutto, subito
Perché si ritorce contro. L'automazione prematura produce due effetti: gli allarmi vengono chiusi da regole che nessuno ha verificato a fondo, e il team perde visibilità su ciò che è stato scartato. Una regola troppo aggressiva può classificare come «rumore» un evento che meritava un'occhiata; dopo qualche settimana nessuno ricorda più perché quella classe di segnali non arriva più sulla scrivania di nessuno. L'automazione, introdotta per alleggerire il lavoro, finisce per nasconderlo.
Vale la pena notare che anche i grandi fornitori di agenti AI per la sicurezza, nella documentazione di trasparenza sui propri agenti, raccomandano di riesaminare le decisioni dell'agente prima di agire sui suoi risultati e trattano queste capacità come funzioni in evoluzione. Nessun percorso serio parte dall'autonomia totale.
Il rimedio. Partire in sola osservazione: il sistema propone, le persone decidono. Automatizzare prima i passaggi reversibili e ben compresi, e richiedere un'approvazione esplicita per ogni intervento che modifica sistemi, account o configurazioni. Le regole di automazione vanno riesaminate periodicamente, chiedendosi sempre: «che cosa non stiamo più vedendo?». Per un approfondimento sulle condizioni per automatizzare in sicurezza, vedi come automatizzare la risposta agli incidenti.
Errore 2: nessun proprietario degli allarmi
Cosa succede. Quando gli allarmi arrivano «al sistema» e non a una persona, si verificano tre situazioni tipiche: segnalazioni esaminate da nessuno perché tutti presumono che le stia guardando qualcun altro; casi chiusi senza che un responsabile abbia valutato; orari scoperti, perché nessuno ha concordato chi risponde la sera o nei festivi. L'AI smista e ordina, ma la decisione di chiudere, approfondire o escalare un allarme resta di una persona: se quella persona non è nominata, la catena si interrompe.
La pubblicazione SP 800-61 revisione 3 del NIST (National Institute of Standards and Technology, l'istituto nazionale statunitense per standard e tecnologia), pubblicata nell'aprile 2025, colloca la risposta agli incidenti nella gestione complessiva del rischio, con ruoli e responsabilità definiti tra persone, team e terze parti. La preparazione — non solo la reazione — è parte integrante del processo.
Il rimedio. Per ogni classe di allarme: un proprietario, un sostituto, un tempo concordato di presa in carico e un percorso di escalation scritto. La chiusura di un allarme è una decisione registrata, non un effetto collaterale di una regola. Su livelli di gravità e catena di escalation, vedi come definire priorità ed escalation nel SOC.
Errore 3: partire da dati incompleti o non affidabili
L'AI correla ciò che vede. Se l'inventario è carente, alcuni sistemi non inviano i loro registri o una fonte è stata collegata «più tardi», il quadro che il sistema costruisce è distorto — e le sue proposte lo riflettono. L'errore organizzativo è dare per scontata la copertura: nessuno ha verificato quali fonti alimentano davvero l'analisi e quali restano fuori.
Il rimedio. Prima di valutare qualsiasi conclusione del sistema, mettere per iscritto l'elenco delle fonti collegate, le lacune note e le integrazioni concordate per il progetto. Una segnalazione va sempre letta insieme alla sua copertura: «non abbiamo visto nulla su quel sistema» può significare che quel sistema non è osservato, non che è tranquillo.
Errore 4: la prova senza criteri di successo
Perché è tempo perso. Una prova senza scenari concordati e misure definite produce opinioni, non evidenze: «sembra utile» non si confronta con nulla. Alla fine del periodo di valutazione non si sa dire se il sistema ha riconosciuto i casi importanti, quanto rumore ha generato e che cosa avrebbe fatto in una situazione reale. La decisione d'acquisto ricade sulle impressioni della demo, che è il modo peggiore di scegliere.
Il rimedio. Definire prima di iniziare: un insieme di casi concordati con esito noto (inclusi eventi innocui e fonti mancanti), i criteri di successo scritti — segnalazioni utili, falsi allarmi, casi non rilevati — e la durata. La prova deve avvenire in sola osservazione, senza modificare la produzione, e i risultati vanno documentati. Per prepararla, aiuta l'elenco di domande da fare durante la demo di un SOC AI e i criteri per valutare la qualità del triage.
Errore 5: dimenticare evidenze e responsabilità
Quando il caso è chiuso, spesso non resta nulla: chi ha deciso cosa, con quali informazioni, su autorizzazione di chi. Sei mesi dopo, un controllo interno, un cliente o un'Autorità possono chiedere la ricostruzione di un episodio — e senza evidenze la risposta è «non lo sappiamo più». L'introduzione dell'AI aggrava il problema se il sistema propone e le persone approvano senza che proposte, decisioni ed esiti vengano conservati insieme.
Il rimedio. Conservare fonti, timeline, proposte, autorizzazioni ed esiti di ogni caso, incluse le decisioni di non intervenire e la loro motivazione. Le evidenze non servono solo a fini legali o contrattuali: sono la base delle lezioni apprese, che la SP 800-61r3 considera parte integrante della gestione degli incidenti. Le responsabilità — chi propone, chi autorizza, chi esegue — vanno scritte prima dell'incidente, non ricostruite dopo.
Esempio illustrativo: l'automazione che chiudeva gli allarmi
Esempio illustrativo. Lo scenario seguente è inventato a scopo didattico; non racconta un incidente avvenuto presso un cliente.
Un'azienda di distribuzione con un magazzino e un gestionale introduce un sistema AI per il monitoraggio di sicurezza e attiva subito la funzione che chiude automaticamente gli allarmi classificati a bassa priorità. Tre errori in una mossa sola. Un allarme su un accesso amministrativo fuori orario viene chiuso perché somiglia alle attività di manutenzione del fornitore IT: nessuno lo esamina, perché nessuno ne è proprietario, e la chiusura non lascia una motivazione consultabile. Settimane dopo, durante un controllo interno, emerge che quell'accesso non era stato autorizzato da nessuno. La prova iniziale, condotta senza criteri, non aveva mai messo alla prova quel tipo di caso.
Con un percorso diverso, lo stesso evento avrebbe seguito un'altra strada: il sistema presenta la segnalazione con il contesto disponibile, un responsabile nominato la valuta, la decisione — qualunque sia — resta registrata con la sua motivazione. La tecnologia era la stessa; a mancare era l'organizzazione intorno.
La checklist in sintesi
| Errore | Segnale che lo stai commettendo | Rimedio |
|---|---|---|
| Automazione prematura | Gli allarmi «spariti» non si possono più riesaminare. | Sola osservazione all'inizio; automazione graduale e reversibile, con approvazione per gli interventi attivi. |
| Proprietà incerta | Alla domanda «chi guarda questo allarme?» non risponde nessuno. | Proprietario, sostituto, tempi ed escalation scritti per ogni classe di allarme. |
| Dati incompleti | Nessuno sa elencare le fonti che alimentano l'analisi. | Inventario delle fonti, lacune dichiarate, integrazioni concordate per iscritto. |
| Prova senza criteri | La valutazione si chiude con «sembra utile». | Casi concordati con esito noto, criteri di successo scritti, durata definita, risultati documentati. |
| Evidenze dimenticate | Non si ricostruisce chi ha deciso cosa, e perché. | Conservare fonti, proposte, autorizzazioni ed esiti di ogni caso, comprese le decisioni di non intervenire. |
Come OverZeus affronta questi errori
OverZeus è costruito attorno al principio «lui si accorge, tu decidi»: gli agenti osservano, spiegano la proposta e chiedono l'approvazione prevista prima di un intervento attivo; il silenzio non viene interpretato come autorizzazione. Rispetto ai cinque errori, tre agenti hanno un ruolo diretto:
- Ares organizza priorità, indagini, escalation e proposte di contenimento, seguendo un piano con responsabilità e autorizzazioni chiare: gli interventi eseguiti sono solo quelli elencati e approvati.
- Themis fa rispettare privilegi, approvazioni e limiti operativi attraverso controlli esterni al modello AI, e blocca un'operazione arrivata con un'autorizzazione scaduta: i confini dell'automazione sono applicati fuori dal modello, non affidati a una sua autovalutazione.
- Oracle supporta la prova in modalità di sola osservazione (Shadow Mode): nel perimetro collegato osserva e prepara proposte senza modificare la produzione, e il report distingue ciò che è stato osservato dalle interpretazioni e dalle condizioni di attivazione — la base per una valutazione con criteri, invece di una demo a impressioni.
Intorno a questi tre, Hermes raccoglie approvazioni e rifiuti nell'app dei responsabili e Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti, segnalando le lacune senza inventare ricostruzioni. Se stai ancora confrontando soluzioni, i criteri per scegliere un SOC AI aiutano a preparare il confronto.
Vuoi evitare questi errori fin dal primo passo? Concordiamo una prova in sola osservazione con casi, criteri e responsabilità definiti per iscritto.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.