Un sistema di rilevamento basato su intelligenza artificiale può peggiorare nel tempo anche se nessuno lo ha mai toccato: il fenomeno si chiama deriva dei modelli. L'azienda cambia — nuovi sistemi, nuovi orari, nuove abitudini di lavoro — e le minacce evolvono, mentre il sistema continua a ragionare con ciò che ha imparato in passato. I segnali tipici sono allarmi che aumentano o calano senza motivo, eventi importanti che non emergono più e spiegazioni sempre meno precise. Il rimedio non è comprare un modello nuovo, ma una rivalutazione periodica condotta da persone, con criteri scritti e responsabilità chiare.
Cos'è la deriva e perché riguarda anche la sicurezza
Un modello di intelligenza artificiale impara a distinguere il comportamento normale da quello sospetto partendo dai dati che vede. La deriva (in inglese drift) è lo scostamento progressivo tra ciò che il modello si aspetta e ciò che accade davvero. Si distingue in genere tra deriva dei dati, quando cambiano le informazioni in ingresso — per esempio nuovi tipi di accessi, orari diversi, applicazioni sostituite — e deriva del concetto, quando cambia il significato stesso di «anomalo»: un accesso da casa che un anno fa era eccezionale oggi è la routine dello smart working.
In un centro operativo di sicurezza (SOC, dall'inglese Security Operations Center) il fenomeno è doppio. Da un lato l'azienda si trasforma: un nuovo gestionale, una rete riorganizzata, un magazzino automatizzato cambiano la «normalità» su cui il sistema era stato calibrato. Dall'altro lato chi attacca modifica continuamente le proprie tecniche, e un rilevatore tarato sulle minacce di ieri può non riconoscere quelle di domani. Il risultato è un degrado silenzioso: il sistema continua a funzionare, ma la qualità delle sue analisi cala senza che nessun allarme tecnico lo segnali.
Il NIST AI Risk Management Framework, il quadro volontario dell'istituto nazionale statunitense per la gestione del rischio dell'AI (oggi in corso di revisione), organizza questo tema nelle funzioni Measure e Manage: misurare le prestazioni e i rischi di un sistema AI non è un'attività una tantum fatta prima dell'acquisto, ma un compito che accompagna tutto il ciclo di vita del sistema. La stessa logica di miglioramento continuo attraversa la NIST SP 800-61 revisione 3 sulla risposta agli incidenti, dove le lezioni apprese rientrano nella gestione ordinaria del rischio.
I segnali che le analisi non sono più affidabili
La deriva non si annuncia: va cercata. Chi usa un SOC AI tutti i giorni può osservare tre famiglie di segnali, ciascuna con possibili cause diverse che vanno verificate prima di concludere.
| Segnale | Cosa osservare | Possibile causa da verificare |
|---|---|---|
| Allarmi | Il volume di segnalazioni cresce o crolla senza un cambiamento dichiarato; molti allarmi vengono chiusi come rumore. | La «normalità» aziendale è cambiata (nuovi sistemi, orari, sedi) e la calibrazione non l'ha seguita. |
| Copertura | Eventi rilevanti emergono da altri canali — un collega, un cliente, un controllo manuale — e non dal sistema. | Nuove tecniche di attacco o nuove fonti dati non collegate: il sistema non vede più una parte del perimetro. |
| Spiegazioni | Le motivazioni degli allarmi diventano generiche, citano contesti superati o non convincono più gli analisti. | Il modello ragiona su riferimenti obsoleti: la qualità delle proposte è calata anche se il sistema «gira». |
C'è poi un segnale comportamentale, spesso il più precoce: le persone smettono di fidarsi. Se gli analisti chiudono le segnalazioni sempre più in fretta, le rimandano sistematicamente o le aggirano con controlli manuali, stanno dicendo che lo strumento non li aiuta più come prima. La qualità del triage — il primo esame che decide cosa merita attenzione — è il punto in cui la deriva si vede prima, perché è lì che il giudizio del modello incontra ogni giorno quello delle persone.
Un errore da evitare è attribuire ogni variazione alla deriva. Un picco di allarmi può dipendere da una fonte dati guasta, da un'integrazione da rivedere o da un vero aumento degli attacchi. Per questo i segnali vanno indagati, non solo contati: serve capire che cosa è cambiato prima di decidere che cosa correggere.
Esempio illustrativo: il magazzino che ha cambiato orario
Esempio illustrativo. Lo scenario seguente è inventato e non racconta un caso avvenuto presso un cliente.
Una media impresa di logistica adotta un nuovo sistema di gestione del magazzino e, nello stesso periodo, estende il lavoro da remoto ad amministrazione e customer care. Prima del cambiamento, il sistema di rilevamento era stato calibrato su una routine stabile: elaborazioni notturne tra l'una e le tre, accessi amministrativi solo dalla sede, traffico concentrato nei giorni feriali.
Nei mesi successivi accadono tre cose. Le elaborazioni del nuovo gestionale girano a orari diversi e generano ogni notte allarmi che gli analisti imparano a chiudere in pochi secondi: rumore. Gli accessi da reti domestiche, diventati quotidiani, smettono di essere trattati come eccezioni e il sistema li assorbe nel nuovo «normale». Infine, un accesso amministrativo insolito — fuori orario, da una rete esterna, su un account che non ne aveva mai avuto bisogno — scivola nella stessa categoria di eventi che tutti ormai ignorano. Non è stata una falla tecnica: è stata la qualità del giudizio a degradarsi, in silenzio, mentre il cruscotto continuava a mostrare un sistema «attivo».
La lezione non è «il modello andava sostituito»: è che nessuno aveva previsto un momento per chiedersi se il sistema ragionasse ancora bene. Una rivalutazione concordata dopo il cambio del gestionale — con un campione di allarmi riesaminato e alcuni casi di prova a esito noto — avrebbe mostrato subito il rumore crescente e la copertura persa.
La rivalutazione periodica: chi la fa, quando e con quali criteri
La responsabilità della rivalutazione è umana e va assegnata per nome. In una media impresa il riferimento naturale è il responsabile IT o della sicurezza, con il supporto del fornitore o dell'integratore per la parte tecnica e con la direzione informata quando le conseguenze riguardano rischi e risorse. Il fornitore può fornire dati e strumenti di misura, ma non dovrebbe essere l'unico a giudicare la qualità del proprio sistema: chi paga deve poter verificare.
Sulla frequenza non esiste una regola universale; esistono due appuntamenti sensati da combinare:
- Un riesame a cadenza fissa, concordato e messo a calendario — per molte realtà trimestrale o semestrale — con un ordine del giorno stabilito, così che non dipenda dalla memoria di nessuno.
- Un riesame straordinario dopo ogni cambiamento rilevante: nuovo gestionale o sistema di produzione, fusione o acquisizione, riorganizzazione della rete, estensione del lavoro remoto, oppure un incidente che ha mostrato lacune nella rilevazione. La logica è la stessa delle lezioni apprese descritta dalla SP 800-61r3: ogni evento e ogni cambiamento alimentano il miglioramento.
Perché la rivalutazione produca decisioni e non solo discussioni, servono criteri scritti in anticipo. Una checklist pratica:
- Casi di prova a esito noto. Un insieme concordato di scenari — eventi innocui e eventi che dovrebbero essere segnalati — da sottoporre periodicamente al sistema, confrontando i risultati con la volta precedente.
- Campione di allarmi chiusi. Una parte delle segnalazioni archiviate come «rumore» viene riesaminata da una persona: se tra gli scarti compaiono eventi che meritavano attenzione, la soglia di fiducia va rivista.
- Verifica delle fonti. L'elenco dei sistemi osservati va confrontato con l'elenco dei sistemi che esistono davvero: ogni fonte aggiunta o dismessa senza aggiornare il monitoraggio è un buco di copertura.
- Qualità delle spiegazioni. Si riesaminano alcune proposte recenti: citano contesti attuali? Le informazioni mancanti sono dichiarate? Una spiegazione confusa è un dato di qualità, non un dettaglio estetico.
- Decisioni e registrazione. Ogni riesame si chiude con una decisione motivata — ricalibrare, aggiungere una fonte, aggiornare i criteri di gravità, oppure confermare che il sistema lavora bene — e la decisione resta agli atti.
Questa disciplina completa, non sostituisce, il lavoro quotidiano degli analisti con l'AI: il giudizio delle persone resta il riferimento, come ricorda anche la nostra guida ai limiti del monitoraggio e alla verifica umana.
Il contributo di OverZeus: osservare, collegare, conservare
OverZeus nasce attorno al principio «lui si accorge, tu decidi»: gli agenti osservano, spiegano la proposta e chiedono l'approvazione prevista prima di un intervento attivo, e il silenzio non viene interpretato come autorizzazione. Sul tema della qualità nel tempo lavorano tre agenti:
- Argus presidia il monitoraggio continuo sulle fonti collegate e segnala le anomalie, mantenendo visibile ciò che accade nell'infrastruttura.
- Odysseus coordina: collega i segnali in un'unica timeline comprensibile, senza dare per certa una compromissione, così che il riesame parta da un quadro ordinato e non da frammenti sparsi.
- Mnemosyne conserva fonti, proposte, autorizzazioni ed esiti nel tempo, segnalando le lacune senza inventare ricostruzioni: è la base documentale che permette di confrontare un periodo con il precedente e di dimostrare chi ha deciso cosa.
Va detto con chiarezza: la rivalutazione della qualità del sistema resta una responsabilità dell'organizzazione, che OverZeus supporta con monitoraggio, timeline ed evidenze — non la sostituisce con un giudizio automatico su se stesso. Se stai ancora confrontando le soluzioni, i criteri per scegliere sono in Il migliore SOC AI per la tua azienda: criteri per sceglierlo; se l'hai già adottata, questa guida ti aiuta a mantenerne il valore.
Un sistema che invecchia bene è un sistema riesaminato
La deriva dei modelli non è un difetto da eliminare una volta per tutte, ma una condizione da governare: i dati cambieranno, le minacce cambieranno, e la qualità del rilevamento dipenderà dalla regolarità con cui qualcuno se ne accorge. Assegna la responsabilità del riesame, mettilo a calendario e dopo ogni cambiamento importante, misura con criteri scritti e registra le decisioni. È il modo più semplice per fare in modo che il tuo SOC AI invecchi bene.
Vuoi vedere come segnali, proposte ed evidenze restano consultabili nel tempo? Richiedi una demo del percorso dal segnale alla decisione.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.