Le 12 domande da fare in demo a chi vende un SOC AI

In demo, il modo più rapido per valutare un SOC AI — un centro operativo per la sicurezza (Security Operations Center) che impiega agenti di intelligenza artificiale — è far lavorare il venditore su tre punti: gli allarmi devono spiegare il proprio ragionamento con fonti visibili, le autorizzazioni devono avere limiti scritti e la decisione deve restare a una persona, e integrazioni ed evidenze devono essere mostrate sul campo, non promesse. Questa checklist di 12 domande si applica a qualsiasi fornitore, OverZeus compreso: porta le stesse richieste a ogni demo e confronta le risposte.

Perché la demo è il momento decisivo

Una scheda prodotto può promettere qualsiasi cosa; una demo no. Quando chiedi di vedere un caso concreto — un allarme, una proposta di intervento, una ricostruzione — scopri se il sistema sa davvero spiegare ciò che fa o se l'automazione è di facciata. Anche i grandi produttori trattano con cautela questi strumenti: Microsoft documenta che i propri agenti di sicurezza, distribuiti in anteprima pubblica, operano con identità e permessi configurati dall'amministratore del cliente, che le decisioni vanno riviste prima di agire e che le azioni compiute dagli agenti sono reversibili (FAQ sugli agenti di Security Copilot). Se questo è il livello di trasparenza atteso da un grande fornitore, è ragionevole chiederlo a chiunque.

C'è anche un motivo organizzativo: la pubblicazione SP 800-61 revisione 3 del NIST (National Institute of Standards and Technology), uscita in versione finale ad aprile 2025, inquadra la risposta agli incidenti come parte della gestione del rischio, con ruoli e responsabilità definiti. Tradotto in demo: devi capire chi decide, chi autorizza e chi risponde del risultato — non solo cosa rileva il software. Per il quadro completo dei criteri di scelta, vedi la guida su come scegliere il migliore SOC AI per la tua azienda; qui trovi le domande operative da porre di persona.

Domande su allarmi e spiegazioni

La prima cosa da verificare è se l'allarme spiega il proprio ragionamento: un segnale senza motivazione sposta il lavoro di analisi su di te, invece di togliertelo.

1. Mostratemi un allarme completo, dall'inizio alla fine. Cosa è stato osservato, da quali fonti, in quale momento? Se in demo vedete solo riepiloghi pronti, chiedete il caso grezzo.
2. Posso vedere perché il sistema ha segnalato proprio questo? Devono essere visibili le fonti, il contesto raccolto e i passaggi che hanno portato alla segnalazione, non un punteggio opaco.
3. Come mi mostrate ciò che avete scartato? Chiedete dove finiscono gli eventi valutati e non segnalati, e con quale motivazione. Il cestino dei falsi positivi dice molto sulla qualità del triage: se ne parla nella guida su come valutare la qualità del triage di un SOC.
4. Chi distingue un'anomalia da una compromissione confermata? Il sistema deve presentare il segnale come ipotesi da verificare, non come verità; la conferma spetta a una persona con evidenze sufficienti.

Domande su autorizzazioni e limiti operativi

Qui si capisce chi mantiene davvero il controllo delle azioni. Le risposte devono essere scritte e dimostrate, non raccontate.

5. Quali azioni può compiere il sistema senza un'approvazione esplicita? Fatevi dare l'elenco per iscritto. «Nessuna» e «queste, entro questi limiti» sono entrambe risposte accettabili; «dipende» non lo è.
6. Con quale identità e quali permessi opera l'agente? Chiedete di vedere come vengono assegnati i privilegi, chi può modificarli e se i controlli sui limiti sono indipendenti dal modello AI o affidati al modello stesso.
7. Cosa succede se nessuno risponde alla richiesta di autorizzazione? Il silenzio non deve essere interpretato come consenso: in assenza di approvazione, l'intervento attivo non deve partire. Fatevelo mostrare.
8. Come si interrompe o si annulla un'azione già avviata? Ogni operazione deve indicare obiettivo, impatto e via di uscita. Un'azione che non si può fermare è un rischio, non un'automazione.

Domande su integrazione, evidenze e prova sul campo

Infine, la parte che decide se il sistema funzionerà nella vostra azienda: si collega davvero ai vostri strumenti e lascia tracce consultabili.

9. Con quali nostri strumenti esistenti vi integrate, e come? Fate elencare per ogni sistema (gestionale, firewall, posta, SIEM — Security Information and Event Management, la raccolta centralizzata dei registri di sicurezza) che cosa viene letto, quali azioni sono possibili e cosa è disponibile oggi rispetto a cosa va concordato nel progetto.
10. Fra sei mesi posso ricostruire chi ha deciso cosa, e perché? Chiedete di vedere in demo una ricostruzione: segnale, timeline, proposte, autorizzazioni ed esiti devono restare consultabili, incluse le decisioni di non intervenire.
11. Dove vengono trattati e conservati i dati? Locale nel vostro centro elaborazione dati, cloud, oppure architettura ibrida? Fate descrivere le dipendenze di ciascuna opzione, compreso cosa continua a funzionare senza connessione Internet.
12. Possiamo fare una prova in sola osservazione prima di firmare? Un periodo di prova su scenari concordati, senza modifiche alla produzione e con criteri di successo scritti, vale più di qualsiasi presentazione.

Esempio illustrativo: la demo messa alla prova

Esempio illustrativo. Lo scenario seguente mostra come usare la checklist; non racconta un incidente avvenuto presso un cliente.

Il responsabile IT di un'azienda logistica assiste a una demo e chiede un caso sui propri scenari: un accesso amministrativo al gestionale ordini in orario notturno. Il sistema mostra il segnale con le fonti — registro degli accessi, orario, account coinvolto — e spiega perché lo ritiene anomalo: quell'account non ha mai lavorato in quella fascia. Propone tre opzioni con conseguenze: attendere e verificare con il titolare dell'account al mattino, richiedere subito una conferma al titolare tramite app, oppure sospendere l'account dopo approvazione, avvisando che la sospensione bloccherebbe anche eventuali attività legittime.

Il responsabile verifica i punti della checklist: la richiesta di autorizzazione arriva sull'app e resta in attesa (domanda 7); il sistema dichiara che senza risposta non interviene; le proposte e la decisione finale restano nella ricostruzione del caso (domanda 10). Quando chiede l'integrazione con il gestionale specifico (domanda 9), il venditore ammette che quel connettore va concordato nel progetto: una risposta onesta, che entra per iscritto nell'offerta. La demo è servita: non a stupire, ma a misurare.

Come OverZeus risponde a queste domande

Portare la stessa checklist anche alla demo di OverZeus è il modo giusto di usarla. Tre agenti rispondono direttamente ai tre gruppi di domande:

• Ares si occupa di SOC e risposta: organizza priorità, indagini, escalation e proposte di contenimento, ed esegue solo le misure elencate e approvate (domande 1-4).
• Themis applica privilegi, approvazioni e limiti operativi tramite controlli esterni al modello AI, e blocca le operazioni con autorizzazione scaduta (domande 5-8).
• Oracle consente una modalità di sola osservazione: una prova su scenari concordati in cui il sistema prepara proposte senza modificare la produzione (domanda 12). Ne parla la sezione dedicata della homepage.

Intorno a loro, Hermes porta richieste e approvazioni sull'app — con la regola che il silenzio non autorizza — e Mnemosyne conserva fonti, timeline, autorizzazioni ed esiti per la ricostruzione. Le integrazioni disponibili dipendono dal progetto: vanno elencate e confermate nell'offerta, esattamente come chiede la domanda 9. Se state ancora decidendo il modello organizzativo complessivo, può aiutare il confronto tra SOC interno, servizio gestito e agenti AI.

Dopo la demo: mettere le risposte per iscritto

Segna ogni risposta con tre stati — dimostrato, da concordare, non incluso — e riporta nell'offerta ciò che hai verificato: integrazioni, limiti operativi, condizioni della prova, trattamento dei dati. Un fornitore che accetta questo metodo sta già rispondendo alla domanda più importante.

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

Tutti gli articoli OverZeus