Human-in-the-loop security: l’equilibrio strategico tra automazione e giudizio umano nella cybersecurity
L’intelligenza artificiale sta ridefinendo i confini della cybersecurity, promettendo di individuare minacce in millisecondi, automatizzare risposte e alleggerire i team di sicurezza da compiti ripetitivi. Eppure, proprio mentre celebriamo questi progressi tecnologici, emerge una consapevolezza critica: i sistemi completamente autonomi eccellono nell’identificazione di pattern, ma falliscono quando serve interpretare il contesto, valutare sfumature o assumere decisioni che impattano persone e organizzazioni in modi complessi.
Da questa tensione nasce l’approccio Human-in-the-Loop (HITL), che non rappresenta un regresso rispetto all’automazione, ma la sua evoluzione più matura. Come evidenziato da ricerche specializzate sulla sicurezza cognitiva, non si tratta di mantenere l’elemento umano “nel circuito” per nostalgia o diffidenza verso le macchine, ma perché determinate decisioni di sicurezza richiedono capacità che restano prerogativa della cognizione umana: intuizione strategica, esperienza contestuale, giudizio etico e la capacità di valutare rischi in scenari inediti.
La problematica dell’automazione totale nella security
Negli ultimi anni, l’industria della cybersecurity ha inseguito con determinazione la promessa dell’automazione integrale. Le piattaforme Security Orchestration, Automation and Response (SOAR) hanno proliferato rapidamente – secondo analisi di mercato specializzate, il concetto è stato coniato da Gartner nel 2015 –, i sistemi Extended Detection and Response (XDR) promettono correlazione automatica tra domini multipli, e gli algoritmi di machine learning vengono presentati come soluzione definitiva al problema del sovraccarico di alert che affligge i Security Operations Center.
Questo paradigma ignora una realtà fondamentale: la sicurezza informatica non è esclusivamente un problema tecnico, ma anche profondamente umano e organizzativo. Un alert di potenziale data exfiltration può indicare un attacco sofisticato o semplicemente un dipendente che trasferisce file legittimamente per lavorare in remoto. Un comportamento anomalo su un endpoint può segnalare malware o un utente che ha modificato le proprie abitudini lavorative. La differenza non risiede nei bit, ma nel contesto.
L’alert fatigue e i suoi costi reali
Secondo uno studio pubblicato su ACM Computing Surveys, i team dei SOC affrontano quotidianamente volumi, velocità e varietà di alert che generano un carico cognitivo insostenibile. Una ricerca di Trend Micro condotta nel 2021 ha rivelato che il 70% dei professionisti dei SOC si sente emotivamente sopraffatto dal volume di alert di sicurezza, con conseguenze che si estendono anche alla vita personale.
I numeri sono impressionanti e documentati: i team gestiscono in media 3.832 alert al giorno, con il 62% di questi che vengono ignorati. Uno studio condotto da IDC ha rivelato che le aziende con 500-1.499 dipendenti ignorano o non investigano il 27% di tutti gli alert, percentuale che sale al 30% per organizzazioni con 1.500-4.999 dipendenti. Ancora più preoccupante: il 55% dei team di sicurezza ammette di perdere alert critici, con il 41% che dichiara che questo accade settimanalmente e il 22% quotidianamente.
Le conseguenze degli errori nei sistemi automatizzati possono essere gravi. Un sistema che blocca automaticamente un account per attività sospette può fermare un dirigente durante una negoziazione critica. Una risposta automatica a un presunto ransomware può eliminare file legittimi crittografati per ragioni di compliance. Il caso emblematico del data breach di Target nel 2013 illustra perfettamente questo problema: FireEye aveva sollevato l’allarme almeno cinque volte dopo aver rilevato malware sulla rete di Target, ma il team di sicurezza della società aveva ignorato gli alert.
Il paradosso dell’automazione: più strumenti, più complessità
Uno studio ESG ha rivelato che il 44% degli alert non vengono investigati a causa di una combinazione di scarsità di talenti e molteplicità di soluzioni di sicurezza che generano volumi enormi di alert. Il Ponemon Institute ha documentato che il SOC medio utilizza dozzine di strumenti per proteggere dati e sistemi, e questi strumenti generano un numero stordente di alert.
La ricerca di Computer Weekly su 427 leader IT ha scoperto che il 70% ha visto il volume di alert di sicurezza più che raddoppiare dal 2015, mentre il 99% ha affermato che gli alti volumi di alert causano problemi ai team di sicurezza e l’83% ha dichiarato che il proprio personale soffre di alert fatigue.
Il valore strategico del giudizio umano nell’approccio human-in-the-loop
Il punto di forza dell’approccio Human-in-the-Loop non sta nel rallentare i processi, ma nel posizionare l’intelligenza umana dove questa apporta massimo valore. Come evidenziato da analisi approfondite sui sistemi HITL, l’expertise umana viene integrata nei processi automatizzati per migliorare l’accuratezza del rilevamento delle minacce, la precisione della risposta e il decision-making strategico.
Un analista esperto apporta elementi che nessun algoritmo può replicare: la conoscenza approfondita del business, la memoria di incidenti passati simili ma non identici, la capacità di percepire quando qualcosa non quadra anche in assenza di indicatori tecnici evidenti. Michael Noory, Lead Threat Hunter di CYDEF, ha sottolineato: “Per quanto comoda possa sembrare la sicurezza al 100% guidata dall’AI a un team IT, questi sistemi non sono ancora al punto in cui possono rilevare in modo affidabile tutte le minacce”.
Human-in-the-loop vs human-on-the-loop: differenze critiche
È fondamentale distinguere l’approccio Human-in-the-Loop da modelli alternativi. Nel modello Human-on-the-Loop (HOTL), gli esseri umani progettano, configurano e distribuiscono sistemi automatizzati ma non sono direttamente coinvolti nelle decisioni quotidiane o nella supervisione. Il sistema opera indipendentemente fino a quando non è necessaria una revisione importante o un aggiornamento.
Nel Human-over-the-Loop, la supervisione umana si concentra sulla governance complessiva e sulla supervisione umana di un intero sistema AI, garantendo che non causi danni o “impazzisca”. Come spiegato da Marsh nella loro analisi sui rischi AI, il primo è definito dalla governance e dalla supervisione umana su un sistema AI complessivo, mentre il secondo si concentra sulla fase operativa dove esiste un forte desiderio di mitigare i rischi di autonomia o di decisioni automatiche del sistema AI.
L’Human-in-the-Loop, invece, mantiene le persone strettamente coinvolte nel decision-making attivo. Nella cybersecurity, dove il contesto può cambiare rapidamente e il costo di una decisione errata può essere elevato, HITL offre un approccio più bilanciato.
Human-in-the-loop e advanced persistent threats
Consideriamo il caso delle Advanced Persistent Threats (APT). Gli indicatori tecnici possono risultare ambigui, le tecniche possono simulare comportamenti legittimi, e la vera natura dell’attacco emerge solo correlando elementi apparentemente scollegati nel corso di giorni o settimane. Come documentato da IBM nella loro analisi XDR, le minacce avanzate possono nascondersi per mesi prima di essere rilevate, preparando attacchi su larga scala o breach.
È in questo contesto che l’intuizione dell’analista, alimentata da anni di esperienza, diventa insostituibile. L’automazione può presentare i frammenti del puzzle, ma serve una mente umana per visualizzare l’immagine complessiva. Gli analisti umani eccellono nel decision-making strategico, nella valutazione dell’impatto potenziale delle minacce e nella prioritizzazione delle azioni basate sulla criticità del business. L’intuizione umana e la capacità di collegare punti apparentemente non correlati sono inestimabili per scoprire attacchi sofisticati e multi-stadio che potrebbero eludere il rilevamento automatico.
Dimensione etica e legale delle decisioni di security
Ancora più critico è il ruolo umano nelle decisioni con implicazioni etiche o legali. Quando un sistema rileva che un dipendente sta potenzialmente sottraendo proprietà intellettuale, la decisione su come procedere non può essere delegata a un algoritmo. Entrano in gioco considerazioni su privacy, diritti del lavoratore, normative come il GDPR o l’HIPAA, potenziali danni reputazionali.
Come evidenziato nell’analisi di Medium sullo sfruttamento dell’expertise umana, gli esseri umani possono interpretare le intuizioni generate dall’AI, considerando fattori che le macchine potrebbero non comprendere pienamente, come sfumature organizzative, dinamiche geopolitiche e attori di minacce emergenti. Gli incidenti di sicurezza tipicamente coinvolgono informazioni personali, e i SOC devono affrontare framework legali complessi. I fattori legali sono essenziali durante un incidente, e per questo gli analisti umani possono analizzare questi aspetti e garantire che le azioni intraprese durante un incidente siano conformi alle normative.
Progettare sistemi human-in-the-loop efficaci
La sfida non è decidere se includere l’elemento umano nel processo, ma determinare dove, come e quando. Un approccio Human-in-the-Loop ben progettato non significa semplicemente aggiungere un pulsante di approvazione manuale a ogni processo automatizzato. Significa ripensare il workflow della sicurezza per massimizzare i punti di forza sia dell’automazione che dell’intelligenza umana.
Stratificazione intelligente delle decisioni
In pratica, questo si traduce in una stratificazione intelligente delle decisioni che rispetta la natura e il rischio di ogni tipo di intervento:
Automazione completa per azioni a basso rischio: Bloccare indirizzi IP riconosciuti come malevoli, applicare patch critiche, isolare endpoint compromessi basandosi su Indicators of Compromise (IoC) ben definiti. In questi casi l’automazione eccelle e l’intervento umano costituirebbe solo un collo di bottiglia. Come documentato nelle linee guida Microsoft per la riduzione dell’alert fatigue, i team con alti livelli di automazione risolvono la maggior parte degli alert di sicurezza lo stesso giorno (66%), rispetto al 34% dei team con bassi livelli di automazione.
Approccio semi-automatico per decisioni di medio livello: L’automazione esegue analisi preliminari e prepara raccomandazioni, ma l’analista mantiene la decisione finale. Il sistema effettua il lavoro oneroso di correlazione e analisi, presenta le opzioni con relativi pro e contro, ma l’ultima parola spetta all’umano. Questo modello funziona efficacemente per situazioni dove il contesto è rilevante ma il tempo di risposta resta un fattore critico.
Centralità umana per decisioni ad alto impatto: Per le decisioni ad alto impatto o elevata incertezza, il ruolo umano diventa centrale fin dall’inizio. L’automazione supporta fornendo dati, visualizzazioni e analisi, ma strategia, valutazione del rischio e decisione finale restano saldamente nelle mani di professionisti esperti. È qui che si gioca la partita più importante: quando un CISO deve decidere se dichiarare pubblicamente un breach, quando serve valutare se un incidente è parte di un attacco coordinato più ampio, quando bisogna bilanciare sicurezza e continuità operativa.
Architetture operative dei sistemi HITL
Dal punto di vista architetturale, i sistemi Human-in-the-Loop per l’automazione dei SOC integrano la velocità dell’automazione con la conoscenza dell’analista. Utilizzando HITL, i SOC possono analizzare ed elaborare numerosi alert, identificare minacce nuove ed esotiche, e scegliere la migliore linea d’azione quando si affronta un incidente.
Un’architettura efficace prevede:
Livello di raccolta dati: Integrazione con SIEM, EDR, NDR, fonti di threat intelligence e altri strumenti di sicurezza per aggregare telemetria completa.
Livello di analisi automatizzata: Algoritmi di machine learning che eseguono correlazione iniziale, identificazione di anomalie, arricchimento contestuale degli alert e classificazione preliminare della gravità.
Livello di decisione umana: Interfaccia che presenta agli analisti solo gli alert che richiedono giudizio umano, con contesto completo, opzioni di risposta preconfigurate e raccomandazioni basate su playbook.
Livello di risposta orchestrata: Esecuzione automatica delle azioni approvate dall’analista attraverso integrazioni con strumenti di sicurezza, con capacità di rollback e audit completo.
Metriche e KPI per sistemi HITL efficaci
Per valutare l’efficacia di un sistema Human-in-the-Loop, le organizzazioni dovrebbero monitorare metriche specifiche:
Tasso di override umano: Percentuale di volte in cui gli analisti sovrascrivono le raccomandazioni dell’AI. Un tasso troppo alto indica che il sistema non è ben calibrato; troppo basso può indicare automation bias.
Tempo medio di decisione: Quanto tempo impiegano gli analisti per prendere decisioni sui casi escalati. Questo dovrebbe diminuire nel tempo man mano che il sistema impara.
Precisione delle raccomandazioni AI: Percentuale di raccomandazioni AI che gli analisti confermano come corrette.
Riduzione dei falsi positivi: Confronto tra il tasso di falsi positivi prima e dopo l’implementazione HITL. Secondo ricerche documentate, tra il 20% e il 40% degli alert sono falsi positivi.
Carico cognitivo degli analisti: Misurato attraverso sondaggi sulla soddisfazione lavorativa e sul burnout.
Mean Time to Detect (MTTD) e Mean Time to Respond (MTTR): Le piattaforme SOAR ben implementate possono ridurre significativamente questi tempi grazie all’integrazione intelligente tra automazione e supervisione umana.
Le sfide dell’implementazione human-in-the-loop
Implementare efficacemente un approccio Human-in-the-Loop presenta complessità significative che richiedono attenzione strategica e pianificazione accurata.
Il rischio di alert fatigue 2.0
La prima insidia è quella che potremmo definire “alert fatigue 2.0″: se ogni azione automatizzata richiede approvazione umana, il risultato è un diluvio di richieste che desensibilizza gli analisti, portandoli ad approvare meccanicamente senza reale valutazione. È il paradosso del loop mal progettato: invece di sfruttare il giudizio umano, lo erode.
Come documentato da Splunk nella loro guida sui sistemi HITL, incorporare gli esseri umani nel ciclo dell’AI offre vantaggi significativi ma presenta anche sfide: miglioramento dell’accuratezza attraverso la supervisione umana che può correggere errori e affinare le prestazioni del modello, ma anche il rischio che la qualità dei giudizi umani degradi sotto pressione cognitiva.
La soluzione sta nel progettare soglie intelligenti: solo gli alert che superano determinate soglie di incertezza o criticità dovrebbero essere escalati agli umani. Il sistema deve essere abbastanza intelligente da riconoscere quando è “confuso” e ha bisogno di aiuto, piuttosto che chiedere costantemente conferma.
Competenze e formazione nei sistemi HITL
La seconda sfida riguarda formazione e competenze. Gli analisti devono essere in grado non solo di comprendere cosa sta eseguendo l’automazione, ma anche di valutare quando fidarsi delle sue raccomandazioni e quando sovrascriverle. Serve una nuova generazione di professionisti fluenti sia nel linguaggio della security che in quello del machine learning, capaci di interpretare le decisioni degli algoritmi e riconoscerne i limiti.
Come evidenziato nell’analisi pubblicata su Medium riguardo l’expertise umana nella cybersecurity, garantire che i team di sicurezza posseggano le competenze necessarie per comprendere e lavorare efficacemente con i sistemi AI è fondamentale. Esiste un divario di competenze significativo nella cybersecurity, e integrare l’AI richiede ulteriori competenze specializzate.
Le organizzazioni dovrebbero investire in:
Programmi di formazione continua: Su AI/ML nella cybersecurity, interpretazione degli output algoritmici, riconoscimento dei bias nei modelli.
Certificazioni specializzate: Che combinano competenze tradizionali di security con conoscenza dei sistemi AI.
Simulazioni e tabletop exercises: Che testano come gli analisti interagiscono con i sistemi HITL in scenari di crisi.
Accountability e responsabilità nei sistemi ibridi
Esiste poi il problema della responsabilità. Quando un sistema automatizzato suggerisce un’azione e un umano la approva, chi è responsabile se le cose vanno male? Se la risposta è sempre “l’umano”, allora il loop diventa una foglia di fico per scaricare la responsabilità. Se è “il sistema”, allora l’umano diventa un timbro di gomma.
Come discusso nell’analisi di Marsh sulla gestione del rischio AI, richiedere la supervisione umana per i sistemi AI non è di per sé una panacea per mitigare i rischi dell’AI e può, nel migliore dei casi, portare a un falso senso di sicurezza e, nel peggiore dei casi, aggravare i rischi. Risolvere i rischi dell’AI con HITL richiede: definire chiaramente il loop applicabile, specificare chiaramente i principi sottostanti per guidare la supervisione in modo che l’essere umano appropriato possa essere assegnato al ruolo, e dove possibile, avere metriche appropriate per valutare i risultati abilitati dall’AI per tenere conto dei bias intrinseci e della fallibilità del giudizio umano e delle limitazioni tecnologiche.
Serve chiarezza sui ruoli e sulle responsabilità, con framework decisionali che specifichino:
Livelli di autorità: Chi può approvare quali tipi di decisioni e in quali circostanze.
Protocolli di escalation: Quando una decisione deve essere elevata a un livello superiore di autorità.
Audit trail completi: Registrazione di ogni decisione, chi l’ha presa, su quale base e con quale risultato.
Revisione post-incidente: Analisi sistematica delle decisioni HITL per identificare pattern di errore o miglioramento.
Bias cognitivi e automazione
Un rischio sottile ma significativo è quello dell’automation bias: la tendenza umana a favorire i suggerimenti provenienti da sistemi automatizzati, anche quando contraddicono informazioni corrette da fonti non automatizzate. Come documentato in letteratura sulla fatica da alert, se gli esseri umani che sono nel loop hanno bias propri, il Reinforcement Learning from Human Feedback (RLHF) potrebbe peggiorare le cose anziché migliorarle.
Per mitigare questo rischio:
Presentazione di informazioni contrarie: Il sistema dovrebbe attivamente presentare prove che contraddicono la propria raccomandazione.
Rotazione degli analisti: Evitare che gli stessi analisti approvino sempre lo stesso tipo di decisioni.
Revisione periodica randomizzata: Un campione di decisioni approvate dovrebbe essere rivisto da un secondo analista.
Metriche di diversità decisionale: Monitorare se gli analisti stanno effettivamente usando il loro giudizio o semplicemente approvando automaticamente.
Casi d’uso e applicazioni pratiche dell’human-in-the-loop
Risposta automatizzata al phishing con supervisione umana
Un’applicazione classica dell’HITL è la gestione del phishing. Quando gli utenti segnalano email sospette, un sistema automatizzato può estrarre indicatori (URL, indirizzi IP, domini), interrogare feed di threat intelligence per determinare reputazione o malevolenza nota, e quarantenare automaticamente l’email dalle caselle di posta degli utenti.
Tuttavia, gli agenti AI nella cybersecurity possono generare falsi positivi, specialmente con email legittime da partner nuovi o messaggi che utilizzano servizi di abbreviazione URL. L’HITL interviene quando:
Email ambigue: L’AI non è sicura della classificazione (punteggio di confidenza medio).
Email da mittenti VIP: Messaggi da dirigenti o clienti importanti richiedono revisione umana prima della quarantena.
Campagne nuove: Quando viene rilevato un nuovo pattern di phishing mai visto prima.
L’analista umano può esaminare il contesto completo – cronologia del mittente, contenuto del messaggio, tempistica – e decidere se confermare la quarantena o rilasciare l’email come falso positivo. Nel frattempo, il sistema apprende da questa decisione per migliorare le classificazioni future.
Gestione delle vulnerabilità e patch management
Nel vulnerability management, l’automazione può identificare vulnerabilità attraverso scansioni continue, valutare la gravità tecnica (CVSS scores), e persino applicare patch automaticamente in ambienti non critici.
L’intervento umano diventa cruciale per:
Valutazione del rischio contestuale: Una vulnerabilità critica su un sistema esposto a Internet richiede azione immediata, ma la stessa vulnerabilità su un sistema isolato in una rete di sviluppo può aspettare. L’analista considera l’architettura di rete, i controlli compensativi esistenti, la criticità del business.
Decisioni di patch in produzione: Applicare una patch può causare interruzioni o incompatibilità. L’analista deve bilanciare il rischio della vulnerabilità contro il rischio dell’interruzione del servizio.
Eccezioni temporanee: In alcuni casi, un sistema non può essere patchato immediatamente a causa di dipendenze applicative. L’analista approva eccezioni temporanee con controlli compensativi.
Threat hunting guidato dall’AI
Il threat hunting proattivo beneficia enormemente dall’approccio HITL. Gli algoritmi di machine learning possono analizzare enormi volumi di dati di rete, log di sistema e telemetria endpoint per identificare anomalie comportamentali che potrebbero indicare minacce latenti.
Il sistema AI potrebbe notare:
- Connessioni di rete insolite a orari anomali
- Pattern di accesso ai dati che deviano dalle baseline
- Sequenze di eventi che, pur essendo individualmente innocue, insieme potrebbero indicare lateral movement
L’hunter umano utilizza questi lead generati dall’AI come punto di partenza, ma poi applica intuizione e creatività:
Formulazione di ipotesi: “Se questo fosse un attacco APT, quali altri indicatori dovrei cercare?”
Investigazione contestuale: Correlazione con eventi di business (fusioni, licenziamenti, progetti sensibili).
Identificazione di TTPs: Collegamento dei comportamenti osservati a Tactics, Techniques, and Procedures note di gruppi APT specifici.
Il risultato è un processo di hunting che combina la scala e velocità dell’AI con l’intuizione investigativa umana.
Gestione degli incidenti di sicurezza complessi
Durante un incidente di sicurezza significativo, le piattaforme SOAR possono automatizzare molte azioni di risposta iniziali: isolamento degli endpoint compromessi, raccolta di forensics, notifiche alle parti interessate. Tuttavia, come analizzato nelle best practice di automazione della security, l’expertise umana rimane indispensabile.
Gli Incident Responder umani devono:
Valutare la portata completa: L’automazione può identificare sistemi direttamente compromessi, ma gli umani devono ipotizzare quali altri sistemi potrebbero essere stati toccati.
Prendere decisioni di contenimento: Isolare completamente una rete potrebbe fermare l’attacco ma anche paralizzare il business. Serve giudizio per bilanciare sicurezza e operatività.
Comunicazione strategica: Decidere quando e come comunicare l’incidente agli stakeholder interni, ai clienti, alle autorità regolatorie e potenzialmente ai media.
Analisi delle cause radice: Identificare non solo come l’attacco è avvenuto, ma perché i controlli esistenti hanno fallito.
Il futuro: loop adattivi e contestuali
Guardando al futuro, l’evoluzione dell’Human-in-the-Loop Security sarà probabilmente verso loop sempre più adattivi e contestuali. I sistemi futuri non avranno un punto fisso dove interviene l’umano, ma sapranno dinamicamente decidere quando richiedere input umano basandosi sulla fiducia nelle proprie analisi, sulla criticità della situazione e sulla disponibilità di esperti.
AI generativa e human-in-the-loop
Come evidenziato in recenti analisi sull’intelligenza artificiale e cybersecurity nel 2025, l’AI generativa potrebbe giocare un ruolo trasformativo in questo contesto, non per prendere decisioni, ma per amplificare le capacità analitiche umane.
Le applicazioni emergenti includono:
Generazione di scenari what-if: L’AI generativa può creare simulazioni di come un attacco potrebbe evolvere sotto diverse strategie di risposta, permettendo agli analisti di valutare le opzioni prima di agire.
Sintesi automatica di intelligence: Trasformazione di centinaia di pagine di threat intelligence in riassunti concisi e actionable.
Supporto alla documentazione: Generazione automatica di report di incidente basati sulle azioni intraprese, riducendo il carico amministrativo sugli analisti.
Assistenza nella threat modeling: Aiuto agli analisti nell’identificazione di potenziali vettori di attacco che potrebbero non aver considerato.
Tuttavia, come sottolineato dal World Economic Forum nel Global Cybersecurity Outlook 2025, gli attacchi informatici sono in forte crescita. Negli ultimi quattro anni, il loro numero medio settimanale è più che raddoppiato: da 818 per organizzazione nel secondo trimestre del 2021 a 1.984 nell’ultimo trimestre del 2024. Questo rende ancora più critico l’equilibrio tra capacità AI e supervisione umana.
Sistemi HITL adattivi basati su reinforcement learning
Immaginiamo sistemi che, dopo aver osservato migliaia di decisioni di un team di security, imparano non solo a replicare quelle decisioni, ma anche a riconoscere quando la situazione esce dai pattern noti e serve l’intervento di un esperto specifico.
Questi sistemi potrebbero:
Apprendimento delle preferenze del team: Ogni team di security ha una propria “firma” di risk tolerance e priorità. Il sistema apprende questi pattern e si adatta.
Riconoscimento dell’incertezza: Invece di forzare una classificazione, il sistema riconosce quando i dati sono insufficienti o ambigui e chiede aiuto.
Escalation intelligente: Non solo “passare all’umano”, ma identificare quale specifico esperto nel team è più qualificato per quel particolare tipo di decisione.
Apprendimento continuo: Ogni decisione umana diventa un nuovo punto dati per affinare i modelli, in un ciclo virtuoso di miglioramento.
Integrazione con architetture zero trust
L’evoluzione verso architetture Zero Trust richiede decisioni continue di autorizzazione basate su molteplici fattori contestuali. L’HITL in questo contesto significa:
Validazione di accessi anomali: Un utente che accede da una nuova località geografica potrebbe essere legittimo (viaggio d’affari) o indicare compromissione delle credenziali. L’AI può bloccare temporaneamente e richiedere autenticazione aggiuntiva, ma un analista può valutare il contesto più ampio.
Definizione dinamica di policy: Gli analisti umani definiscono le policy di Zero Trust a livello strategico, ma l’AI le applica e adatta tatticamente basandosi sui pattern di comportamento osservati.
Gestione delle eccezioni: In situazioni di emergenza business, potrebbe essere necessario concedere eccezioni temporanee ai principi Zero Trust. Questa è una decisione che richiede giudizio umano senior.
Best practices per l’implementazione human-in-the-loop
Iniziare con un approccio incrementale
Non tentare di implementare HITL su tutti i processi di sicurezza contemporaneamente. Iniziare con un caso d’uso ben definito, dimostrarne il valore, e poi espandere gradualmente.
Fase 1 – Pilota su singolo caso d’uso: Scegliere un processo con alto volume ma bassa complessità (es. phishing response).
Fase 2 – Misurazione e ottimizzazione: Raccogliere metriche per 3-6 mesi, ottimizzare le soglie di escalation.
Fase 3 – Espansione controllata: Estendere a 2-3 casi d’uso aggiuntivi, mantenendo il focus sulla qualità.
Fase 4 – Integrazione enterprise: Solo dopo aver dimostrato ROI chiaro, espandere all’intero stack di sicurezza.
Investire nell’interfaccia analista
Il successo dell’HITL dipende criticamente dalla qualità dell’interfaccia attraverso cui gli analisti interagiscono con il sistema. Come evidenziato nell’analisi su Medium riguardo la collaborazione umano-AI, progettare interfacce intuitive, visualizzazioni chiare e workflow semplificati che facilitino l’interazione e la condivisione di informazioni tra analisti umani e sistemi AI è cruciale.
Un’interfaccia efficace dovrebbe:
Minimizzare il carico cognitivo: Presentare solo le informazioni essenziali per la decisione, non sovraccaricare con dati non rilevanti.
Fornire contesto ricco: Cronologia dell’entità, comportamento baseline, decisioni precedenti su casi simili.
Offrire opzioni chiare: Non “approva/rifiuta” generico, ma opzioni di risposta specifiche con conseguenze previste.
Supportare il feedback rapido: L’analista può fornire feedback sulla qualità della raccomandazione con un clic, alimentando il miglioramento continuo.
Visualizzazione dell’incertezza: Mostrare chiaramente il livello di confidenza dell’AI e quali fattori contribuiscono all’incertezza.
Costruire una cultura di fiducia calibrata
Un rischio è che gli analisti sviluppino o troppa fiducia (approvando ciecamente) o troppo poca fiducia (ignorando raccomandazioni valide) nel sistema AI. Serve una “fiducia calibrata”.
Trasparenza algoritmica: Gli analisti devono capire, almeno a livello concettuale, come il sistema arriva alle sue raccomandazioni.
Validazione continua: Pubblicare regolarmente metriche sull’accuratezza del sistema, confrontate con le decisioni umane.
Cultura dell’errore produttivo: Quando il sistema sbaglia, trattarlo come opportunità di apprendimento, non di colpa.
Empowerment degli analisti: Gli analisti devono sentirsi autorizzati a sovrascrivere il sistema quando il loro giudizio lo richiede, senza timore di ritorsioni.
Pianificazione per la governance e compliance
Le normative emergenti come l’AI Act europeo richiedono accountability nei sistemi AI utilizzati per decisioni ad alto impatto. L’implementazione HITL può supportare la compliance:
Audit trail completi: Registrazione di ogni decisione AI, revisione umana e outcome.
Explainability delle decisioni: Capacità di spiegare perché il sistema ha fatto una particolare raccomandazione.
Meccanismi di ricorso: Processo per contestare decisioni automatizzate e ottenere revisione umana.
Valutazioni di impatto: Documentazione di come il sistema HITL impatta i diritti degli individui e la sicurezza dell’organizzazione.
Oltre la tecnologia: una questione di governance
In ultima analisi, l’Human-in-the-Loop Security ci ricorda che la sicurezza informatica non è solo questione di tecnologia, ma di persone, processi e giudizio. In un’era dove l’automazione è spesso presentata come soluzione a ogni problema, questo approccio riconosce con onestà intellettuale che esistono dimensioni della sicurezza dove l’intelligenza umana resta insostituibile.
Non è un rifiuto del progresso tecnologico, ma un’affermazione che il progresso autentico sta nel creare sistemi che amplificano le capacità umane piuttosto che tentare inutilmente di rimpiazzarle. È il riconoscimento che le decisioni migliori nascono quando macchine e umani lavorano insieme, ciascuno portando i propri punti di forza complementari.
Come sottolineato dal Dr. Victoria Baines, ricercatrice di cybersecurity: “Siamo abituati a descrivere la cybersecurity in termini di persone, processi e tecnologia. Troppo spesso, però, le persone sono ritratte come una vulnerabilità piuttosto che come una risorsa, e le difese tecniche sono prioritizzate rispetto alla resilienza umana. È giunto il momento di rinnovare il nostro investimento nelle nostre risorse di sicurezza umane”.
Per i CISO e i team di security, questo significa ripensare non solo quali strumenti adottare, ma come progettare i workflow, quali competenze sviluppare nei team e come costruire una cultura che valorizzi tanto l’efficienza dell’automazione quanto la saggezza dell’esperienza umana. È una sfida complessa, ma forse è proprio questa complessità il segno che stiamo finalmente ponendo le domande giuste sul futuro della cybersecurity.
L’Human-in-the-Loop non è una soluzione temporanea fino a quando l’AI diventerà “abbastanza buona” da operare autonomamente. È piuttosto un principio fondamentale per lo sviluppo di sistemi di sicurezza robusti, affidabili e responsabili, capaci di navigare la complessità del mondo reale e garantire che le decisioni critiche riflettano valori umani, considerazioni etiche e comprensione contestuale che nessuna macchina, per quanto avanzata, può pienamente replicare.
Fonti:
Rapid7, “Human-in-the-Loop in Cybersecurity”
ACM Computing Surveys, “Alert Fatigue in Security Operations Centres”
Trend Micro, “70% Of SOC Teams Emotionally Overwhelmed”
Microsoft Security Blog, “6 strategies to reduce alert fatigue”
CYDEF, “What is Human-in-the-Loop Cybersecurity?”
Splunk, “Human in the Loop in Practice”
Medium, “Leveraging Human Expertise in Cybersecurity”
Marsh, “Human in the Loop in AI Risk Management”
Expel, “Alert fatigue, burnout, turnover”
XenonStack, “Human-in-the-loop in SOC Automation”
