AI nella cybersecurity, la sfida è sapere quando fidarsi

L’intelligenza artificiale sta entrando nella cybersecurity con una promessa difficile da ignorare: individuare prima le anomalie, accelerare la gestione delle vulnerabilità, ridurre il tempo necessario per reagire a un attacco. Il Piano pubblicato dalla Commissione europea il 7 luglio 2026 rafforza questa direzione, puntando sulla valutazione dei modelli e sulla creazione di ambienti di test sicuri. La notizia, però, è già meno importante del problema che lascia sul tavolo. Quando un sistema AI suggerisce una patch, correla eventi o interviene nella risposta a un incidente, entra nella catena decisionale della sicurezza. E lì non basta che sia potente. Deve essere affidabile, misurabile e governabile.

Il vero tema non è usare più AI, ma sapere quando fidarsi

La narrazione dominante presenta l’AI come risposta naturale alla complessità cyber. Gli attacchi aumentano, le superfici digitali si espandono, le competenze scarseggiano: automatizzare detection e remediation sembra inevitabile. È una lettura comprensibile, ma incompleta. L’AI non elimina l’incertezza; spesso la sposta. Può ridurre i tempi di analisi e, nello stesso momento, moltiplicare falsi positivi o suggerimenti incompatibili con il contesto operativo.

È qui che il Piano europeo assume valore. Non introduce da solo nuovi obblighi immediatamente applicabili, ma anticipa il livello di diligenza che regolatori, autorità e mercato tenderanno a considerare normale. Testare i modelli, predisporre ambienti controllati, documentare limiti e condizioni d’uso significa spostare la compliance dalla dichiarazione alla prova.

L’AI Act contiene già questa logica. L’art. 55 impone ai provider di modelli per finalità generali con rischio sistemico valutazioni, adversarial testing, gestione dei rischi e misure di cybersecurity. Ma sarebbe un errore trasformare quel requisito in un alibi: “il modello è conforme, quindi possiamo usarlo”. La conformità del modello non coincide con l’idoneità del caso d’uso. Un sistema può essere robusto in astratto e inadeguato quando viene collegato ai log aziendali, ai processi di patching o agli strumenti del SOC. La domanda corretta non è se l’AI funzioni, ma se funzioni abbastanza bene in quello specifico perimetro, con quei dati, quei privilegi e quelle conseguenze.

Dalla sperimentazione alla responsabilità operativa

Molti progetti partono da una demo convincente. Il sistema riconosce pattern anomali, produce una spiegazione ordinata e propone una remediation in pochi secondi. Poi incontra l’organizzazione reale: dati incompleti, asset non censiti, applicazioni legacy e processi autorizzativi che non dialogano tra loro.

È in questo passaggio che l’AI smette di essere una soluzione tecnologica e diventa un problema di governance. Prima del deployment occorre classificare il caso d’uso per impatto e grado di autonomia, definire quali dati può utilizzare, quali strumenti può interrogare e quali azioni può eseguire. Vanno stabilite soglie di accuratezza, criteri di escalation, condizioni di arresto e meccanismi di rollback. Le decisioni ad alto impatto devono restare soggette a un controllo umano effettivo.

OWASP richiama vulnerabilità come prompt injection, data poisoning, insecure output handling ed excessive agency. MITRE ATLAS descrive tattiche e tecniche avversarie rivolte ai sistemi AI. In termini aziendali, il sistema chiamato a difendere l’organizzazione può diventare esso stesso una superficie di attacco. Se dispone di privilegi elevati o può modificare configurazioni, una manipolazione dell’input può produrre effetti ben più seri di una risposta sbagliata in una chat.

Il controllo, quindi, deve essere progettato prima dell’automazione. Non dopo l’incidente.

Quando la velocità supera l’organizzazione

ENISA evidenzia come l’AI possa comprimere il ciclo tra scoperta, sfruttamento e diffusione di una vulnerabilità. Il rischio non è soltanto un attaccante più sofisticato, ma un attaccante più veloce e scalabile. Da qui nasce la tentazione di automatizzare non solo la detection, ma anche la risposta.

Molte organizzazioni, però, governano decisioni “a velocità macchina” con processi costruiti per un mondo più lento. Un sistema può individuare in pochi minuti una configurazione vulnerabile; la correzione può richiedere giorni tra ticket, verifiche, autorizzazioni e finestre di manutenzione. Il collo di bottiglia non è più la capacità di vedere il rischio, ma quella di intervenire senza generarne un altro.

È come installare un radar capace di rilevare ogni movimento e lasciare invariata la torre di controllo. L’informazione aumenta, ma aumenta anche la congestione decisionale. Se l’AI produce centinaia di alert o proposte di remediation, la sua utilità non si misura dal volume dell’output, bensì dalla capacità di ridurre rischio residuo e tempi di risposta senza compromettere continuità e integrità dei sistemi.

Il NIST AI Risk Management Framework è utile perché non tratta il rischio come un adempimento una tantum. Govern, Map, Measure e Manage descrivono un ciclo continuo di responsabilità, comprensione del contesto, misurazione e riesame. ISO/IEC 42001 può dare forma al sistema di gestione; ISO/IEC 27001 integra i presidi di sicurezza; OWASP e MITRE supportano threat modeling e test avversari.

Nessuno di questi strumenti, però, decide quale margine di errore l’organizzazione sia disposta ad accettare. Quella resta una responsabilità manageriale.

NIS2, DORA e CRA: la prova diventa compliance

L’intersezione con il quadro regolatorio europeo è diretta. NIS2 impone agli organi di gestione di approvare e supervisionare misure tecniche, operative e organizzative adeguate. Se l’AI entra nel vulnerability management, nel monitoraggio o nell’incident response, entra anche nel perimetro di quelle responsabilità.

DORA rende ancora più evidente il passaggio dalla policy al testing, con programmi strutturati, vulnerability assessment, test di scenario e verifiche end-to-end. Il Cyber Resilience Act aggiunge il ciclo di vita del prodotto, la security by design e la gestione continuativa delle vulnerabilità. L’AI Act disciplina invece caratteristiche, rischi e obblighi relativi ai sistemi e ai modelli.

Normative diverse, una stessa esigenza: dimostrare che la tecnologia è stata valutata prima dell’uso e continua a esserlo dopo il deployment.

La risposta operativa non dovrebbe essere l’ennesima procedura separata, ma un fascicolo di AI cyber assurance: un dossier vivo che raccolga finalità del sistema, versione del modello, dati e strumenti accessibili, livelli di privilegio, threat model, risultati dei test, limiti noti, metriche, controlli umani, log, incidenti, aggiornamenti e riesami.

Non burocrazia difensiva, ma memoria tecnica e organizzativa delle decisioni assunte.

Serve anche una governance trasversale. CISO, CIO, compliance, legal, DPO, procurement e business owner devono condividere criteri e responsabilità. Il fornitore non può restare l’unico soggetto capace di spiegare come il sistema funzioni o cosa accada in caso di errore. La dipendenza informativa è già un rischio di terza parte; nella difesa cyber diventa un rischio strategico.

Il cambio di prospettiva

L’errore sarebbe leggere il Piano europeo come un semplice incentivo a introdurre più AI nei processi di sicurezza. La direzione è più esigente: usare l’AI dove genera valore, ma costruire attorno a essa condizioni di verificabilità, reversibilità e responsabilità.

Per imprese e pubbliche amministrazioni, la priorità non è acquistare il modello più avanzato. È sapere quali decisioni gli si possono affidare, con quali dati, entro quali soglie e sotto quale controllo. Significa testare prima del deployment, simulare il fallimento, limitare i privilegi, documentare gli scostamenti, riesaminare il sistema quando cambiano modello, contesto o minaccia.

La maturità non si misurerà dal numero di strumenti AI presenti nel SOC, ma dalla capacità dell’organizzazione di contestarne l’output, sospenderne l’azione e ricostruire perché una decisione sia stata presa.

Perché nella cyberdefense l’AI non diventa affidabile quando agisce più velocemente dell’uomo, ma quando l’organizzazione sa con precisione dove può agire, quanto può sbagliare e chi ha il potere di fermarla.