Consapevolezza del rischio in azienda – P2
Superare le resistenze interne: metodo, AI governance e roadmap
Metodo operativo, governance dell’AI, roadmap in 90 giorni e metriche per rendere la cultura del rischio visibile e misurabile.
Questa seconda puntata riparte dalle resistenze interne e propone un metodo concreto per trasformare la sicurezza da funzione percepita come ostacolo a partner strategico del business.
Trasformiamo il problema culturale in un metodo pratico: come parlare il linguaggio del business, assegnare responsabilità, governare l’AI, misurare la maturità e costruire una roadmap realistica in 90 giorni.
Come superare le resistenze: metodo e strumenti
Superare le resistenze non significa convincere tutti con un’unica presentazione. Significa modificare il sistema in cui le persone decidono. Le persone cambiano comportamento quando capiscono il perché, quando il comportamento atteso è praticabile, quando i leader lo rendono coerente con le priorità aziendali e quando l’organizzazione premia la trasparenza anziché l’occultamento dei problemi.
1. Tradurre il rischio in conseguenze concrete
La prima leva è linguistica. “Vulnerabilità critica”, “mancanza di hardening”, “assenza di segregation of duties” o “prompt injection” sono espressioni importanti per gli specialisti, ma raramente guidano una decisione manageriale. Occorre tradurle in scenari: quanti clienti potrebbero essere impattati? Quante ore di fermo sono realistiche? Quale dato potrebbe uscire? Quale obbligo di notifica scatterebbe? Quale processo si bloccherebbe? Quale fornitore non sarebbe sostituibile?
Il NIST Cybersecurity Framework 2.0 ha rafforzato questa prospettiva introducendo la funzione Govern , accanto a Identify, Protect, Detect, Respond e Recover, per dare una visione completa del ciclo di vita della gestione del rischio cyber. [8] La governance non è un livello decorativo: è il meccanismo che collega controlli tecnici, priorità di business e responsabilità.
2. Rendere visibile la proprietà del rischio
Ogni rischio rilevante dovrebbe avere un proprietario. Non necessariamente un tecnico, ma una persona con autorità sul processo o sull’asset coinvolto. La sicurezza può supportare, misurare e sfidare le assunzioni; non può però essere proprietaria di tutti i rischi dell’organizzazione. Se un processo commerciale usa dati personali, il rischio è anche del responsabile commerciale. Se un sistema AI supporta selezione del personale, il rischio è anche HR. Se un fornitore cloud è critico, il rischio è anche procurement e operations.
- Quali sono i cinque processi aziendali che non possiamo permetterci di fermare?
- Quali dati, se esposti o alterati, genererebbero un danno materiale?
- Quali fornitori sono così critici da diventare una dipendenza strategica?
- Quali sistemi AI sono già in uso, anche in modo sperimentale o informale?
- Chi ha l’autorità per accettare un rischio residuo rilevante?
- Quando abbiamo testato l’ultima volta backup, continuità operativa e risposta agli incidenti?
3. Passare dal “no” al “sì, in modo sicuro”
La sicurezza efficace non è quella che vieta tutto. È quella che rende praticabile ciò che l’azienda deve fare, riducendo il rischio entro soglie accettabili. Questo richiede un cambio di postura: quando arriva una richiesta, la risposta non dovrebbe essere solo approvazione o blocco, ma una valutazione con opzioni. Ad esempio: “possiamo usare questo strumento AI solo con dati non riservati”; “possiamo partire con un pilota su un perimetro limitato”; “possiamo accettare il fornitore se introduce logging, cifratura, exit plan e clausole di notifica”; “possiamo automatizzare il processo ma mantenendo controllo umano nelle decisioni ad alto impatto”.
4. Co-progettare i controlli con chi lavora nel processo
Un controllo progettato senza conoscere il lavoro reale genera aggiramenti. Un controllo co-progettato diventa parte del processo. Questo vale per MFA, classificazione documentale, gestione delle eccezioni, accessi privilegiati, approvazione di strumenti AI, procedure di incident reporting e gestione dei fornitori. L’obiettivo non è abbassare il livello di sicurezza, ma ridurre l’attrito inutile.
5. Sostituire la formazione generica con formazione per ruolo
Dire a tutti le stesse cose produce spesso stanchezza. Un amministratore di sistema, un commerciale, un addetto HR, un product manager, un legale e un dirigente hanno rischi diversi. La formazione deve quindi essere breve, ricorrente, collegata a casi reali e personalizzata. Per l’AI, ad esempio, il commerciale deve sapere quando non inserire dati cliente in strumenti esterni; HR deve comprendere bias, trasparenza e supervisione; IT deve presidiare integrazioni, log, accessi e vendor; il management deve sapere quali decisioni non può delegare.
6. Creare una cultura di segnalazione senza colpa
Molti incidenti diventano gravi non perché qualcuno ha sbagliato, ma perché l’errore viene nascosto o segnalato tardi. L’azienda deve comunicare chiaramente che segnalare rapidamente un possibile problema è un comportamento professionale. Questo vale per email sospette, condivisioni accidentali, anomalie nei sistemi, risposte strane di un modello AI, accessi impropri o violazioni di policy.
7. Usare simulazioni, non solo policy
Le policy descrivono ciò che dovrebbe accadere. Le simulazioni mostrano ciò che accade davvero. Una tabletop exercise su ransomware, data breach, indisponibilità di un fornitore cloud o errore di un sistema AI rivela lacune che nessun documento mostra: chi decide, chi comunica, quali contatti mancano, quali log non sono disponibili, quali tempi sono irrealistici, quali responsabilità sono sovrapposte.
Il caso specifico dell’AI: dal fascino dello strumento alla governance
L’intelligenza artificiale è oggi uno dei terreni più evidenti in cui la consapevolezza del rischio può mancare. Le ragioni sono comprensibili: gli strumenti sono facili da usare, promettono produttività immediata, spesso entrano in azienda dal basso e producono benefici visibili prima che siano chiari i rischi. Ma proprio questa facilità rende necessaria una governance esplicita.
Il NIST AI Risk Management Framework è stato sviluppato per aiutare organizzazioni e individui a gestire i rischi associati all’AI per persone, organizzazioni e società. [7] I principi OCSE sull’AI, aggiornati nel 2024, richiamano un uso innovativo e affidabile dell’AI che rispetti diritti umani e valori democratici. [15] L’AI Act europeo, a sua volta, lega l’adozione dell’AI a un approccio basato sul rischio, con obblighi crescenti in base alla criticità dei casi d’uso.
Per un’azienda, questo significa almeno sei cose. Primo: censire i sistemi AI, inclusi quelli usati informalmente. Secondo: classificare i casi d’uso per impatto su persone, diritti, sicurezza, continuità e reputazione. Terzo: definire regole sui dati inseribili nei sistemi AI. Quarto: valutare fornitori, contratti, localizzazione dei dati, log e modalità di training. Quinto: prevedere supervisione umana, test e monitoraggio. Sesto: gestire incidenti e anomalie AI con la stessa serietà con cui si gestiscono incidenti cyber o privacy.
Un team marketing usa un chatbot esterno per sintetizzare feedback dei clienti. Il risultato è utile, ma nessuno ha valutato quali dati siano stati inseriti, se il fornitore li conservi, se possano essere usati per addestramento, chi abbia accesso agli output e come correggere eventuali errori. Il rischio non è “il chatbot”: è l’assenza di perimetro.
Creare un registro AI leggero: strumento, finalità, dati trattati, owner, fornitore, livello di rischio, misure minime, autorizzazione, riesame. Per casi a basso rischio il processo deve essere rapido; per casi ad alto rischio deve prevedere valutazioni più rigorose.
| Domanda AI | Perché conta | Evidenza richiesta |
|---|---|---|
| Qual è la finalità del sistema? | Senza finalità non si può valutare proporzionalità, rischio e controllo. | Use case documentato e owner nominato. |
| Quali dati entrano nel sistema? | Dati personali, riservati o strategici cambiano completamente il profilo di rischio. | Classificazione dati e regole di utilizzo. |
| Chi verifica l’output? | L’automazione non elimina la responsabilità della decisione. | Human oversight e criteri di escalation. |
| Quale fornitore è coinvolto? | Il rischio AI è anche rischio contrattuale, supply chain e lock-in. | Vendor assessment, clausole, exit plan. |
| Come monitoriamo errori e drift? | I sistemi cambiano nel tempo: dati, contesto e performance possono degradare. | Log, test periodici, incident process. |
La Commissione europea ha pubblicato il General-Purpose AI Code of Practice, con capitoli su trasparenza, copyright e sicurezza, per aiutare i provider di modelli general-purpose a dimostrare conformità; le linee guida per i provider GPAI, aggiornate ad aprile 2026, chiariscono l’ambito degli obblighi e il calendario di enforcement. [2] [3] Anche se non tutte le aziende sono provider di modelli, molte sono deployer o utilizzatrici: devono quindi costruire consapevolezza interna, regole di uso e controlli proporzionati.
Una roadmap operativa in 90 giorni
Il contesto 2026: AI, cyber, norme e aspettative del mercato
Nel 2026 la gestione del rischio non è più un tema confinato ai reparti IT, legal o compliance. È diventata una condizione di affidabilità aziendale. Le ragioni sono almeno quattro: l’accelerazione dell’intelligenza artificiale, l’aumento dell’interdipendenza digitale, la pressione normativa europea e la crescente attenzione di clienti, assicuratori, investitori e partner di filiera.
Il dato economico aiuta a rendere concreto ciò che spesso viene percepito come astratto. Il Cost of a Data Breach Report 2025 di IBM indica un costo medio globale di una violazione dati pari a 4,4 milioni di dollari e sottolinea un “AI oversight gap”: molte organizzazioni adottano strumenti AI più rapidamente di quanto costruiscano controlli di accesso, policy e governance adeguate. [12] Il messaggio non è che l’AI sia da evitare; è che l’innovazione senza presidio produce debito di rischio.
Il Global Cybersecurity Outlook 2026 del World Economic Forum evidenzia come AI, frammentazione geopolitica e disuguaglianze di capacità cyber stiano rimodellando il panorama del rischio, aumentando la pressione sulle organizzazioni perché adattino strategia, investimenti e policy. [13] In altre parole, il rischio digitale non è solo una questione di tecnologia: è governance, resilienza, continuità operativa e capacità decisionale.
La pressione normativa europea non è un dettaglio
Per le aziende europee, o per quelle che operano sul mercato europeo, il rischio digitale è ormai intrecciato a un insieme di regole che chiedono non soltanto documenti, ma capacità dimostrabili. L’AI Act è entrato in vigore il 1° agosto 2024; alcune disposizioni, come pratiche vietate e obblighi di alfabetizzazione AI, si applicano dal 2 febbraio 2025, mentre gli obblighi per i modelli di AI general-purpose sono entrati in applicazione dal 2 agosto 2025. La pagina ufficiale della Commissione europea aggiornata al 2026 riporta anche il calendario applicativo rivisto per alcuni sistemi AI ad alto rischio, con scadenze differenziate nel 2027 e 2028. [1]
La NIS2, recepita in Italia con il Decreto legislativo 4 settembre 2024, n. 138, amplia il perimetro dei soggetti coinvolti e rafforza la centralità delle misure tecniche, organizzative e di governance per la cybersicurezza. [4] DORA, applicabile dal 17 gennaio 2025, impone al settore finanziario una disciplina organica sulla resilienza operativa digitale, includendo gestione del rischio ICT, incident reporting, test di resilienza e controllo dei fornitori ICT terzi. [5] Il Cyber Resilience Act, entrato in vigore il 10 dicembre 2024, introduce obblighi progressivi per prodotti con elementi digitali, con obblighi di reporting dal 11 settembre 2026 e applicazione principale dal 11 dicembre 2027. [6]
| Ambito | Che cosa cambia per l’azienda | Implicazione culturale |
|---|---|---|
| AI Act | Classificazione dei sistemi AI, alfabetizzazione, governance dei modelli, obblighi per GPAI e sistemi ad alto rischio. | L’AI non può essere introdotta solo perché “utile”: va censita, valutata, documentata e monitorata. |
| NIS2 / D.Lgs. 138/2024 | Maggiore perimetro di soggetti, governance cyber, misure proporzionate al rischio, gestione e notifica degli incidenti. | La cybersicurezza non è un presidio IT: è responsabilità gestionale e organizzativa. |
| DORA | Per il finanziario: resilienza digitale, test, gestione fornitori ICT, incident reporting e oversight sui provider critici. | La continuità operativa dipende anche dalla filiera tecnologica e contrattuale. |
| Cyber Resilience Act | Per produttori di software/hardware con elementi digitali: security by design, vulnerability handling, reporting. | La sicurezza entra nel ciclo di vita del prodotto, non si aggiunge alla fine. |
Queste norme non vanno lette come un elenco di obblighi separati, ma come segnali convergenti: il mercato europeo sta chiedendo alle organizzazioni di dimostrare controllo, tracciabilità, resilienza e responsabilità. Una cultura aziendale che percepisce la sicurezza come “freno” o “fastidio” rischia quindi di trovarsi fuori tempo non solo rispetto alle minacce, ma anche rispetto alle aspettative regolatorie e commerciali.
Cosa significa davvero mancata gestione del rischio
La mancata gestione del rischio non coincide semplicemente con l’assenza di antivirus, firewall, policy o procedure. Un’organizzazione può possedere molti strumenti e restare fragile, se questi strumenti non sono collegati a decisioni, responsabilità e comportamenti coerenti. Gestire il rischio significa costruire un ciclo: identificare, analizzare, valutare, trattare, monitorare e comunicare. È il linguaggio della ISO 31000, che descrive il risk management come un approccio integrato nei processi di governance, strategia, pianificazione, valori e cultura dell’organizzazione. [9]
Quando questo ciclo manca, si manifestano sintomi ricorrenti. I rischi vengono identificati tardi o solo dopo un audit. Le responsabilità sono implicite. I fornitori vengono scelti per prezzo e rapidità, ma non per resilienza. I progetti digitali partono senza valutazione preventiva. I team business considerano la sicurezza un ostacolo, mentre la sicurezza considera il business una fonte continua di deviazioni. L’AI viene adottata in modo frammentato, spesso attraverso strumenti esterni, account personali, plugin, automazioni o modelli non approvati. Il risultato è un’organizzazione che funziona, ma non sa davvero quanto sia esposta.
Confondere la presenza di controlli con la presenza di governo. Un controllo isolato riduce una vulnerabilità; un sistema di governo decide quali rischi sono accettabili, quali vanno ridotti, chi può accettarli, quando riesaminarli e come comunicarli.
Il rischio non gestito produce tre tipi di danno
Il primo è il danno operativo: sistemi indisponibili, processi bloccati, produzione rallentata, personale impegnato in attività di emergenza. Il secondo è il danno economico: costi di ripristino, consulenze, penali, perdita di ordini, aumento dei premi assicurativi, investimenti urgenti non pianificati. Il terzo è il danno fiduciario: clienti, dipendenti, partner e autorità iniziano a chiedersi se l’organizzazione sappia davvero proteggere ciò che le è stato affidato.
Nel caso dell’AI, il danno può essere ancora più sottile. Un modello può generare risposte errate ma plausibili, trattare dati non idonei, introdurre bias, automatizzare una decisione senza supervisione, esporre informazioni riservate o creare dipendenza da fornitori esterni non adeguatamente valutati. La criticità non nasce solo dall’algoritmo, ma dal contesto in cui viene usato: dati, utenti, obiettivi, controlli, log, auditabilità e capacità di intervento umano.
La matrice è volutamente semplice: serve a tradurre la conversazione dal piano tecnico al piano decisionale. Il suo valore non è “calcolare tutto”, ma far emergere chi decide, con quali informazioni e con quali soglie di accettazione.
Perché nascono le resistenze interne
Le resistenze degli operatori interni non sono sempre segno di superficialità. Spesso sono la risposta razionale a un sistema di incentivi incoerente. Se una persona viene valutata sulla velocità di consegna, tenderà a percepire un controllo di sicurezza come perdita di tempo. Se un responsabile di funzione non vede tradotto il rischio in impatti economici, penserà che la sicurezza sia un linguaggio tecnico lontano dal suo lavoro. Se un team ha vissuto la sicurezza solo come divieto, cercherà scorciatoie.
La cultura del rischio fallisce quando chiede alle persone di comportarsi in modo sicuro senza rendere quel comportamento compatibile con il lavoro reale. Le campagne di awareness, da sole, non bastano: devono essere accompagnate da processi più semplici, strumenti utilizzabili, feedback rapidi e responsabilità chiare. ENISA, nelle proprie attività di awareness e cyber hygiene, sottolinea proprio la necessità di promuovere cambiamento comportamentale e buone pratiche integrate nei diversi settori. [10]
| Resistenza | Come si manifesta | Che cosa c’è sotto | Risposta efficace |
|---|---|---|---|
| “Rallenta il business” | Controlli aggirati, eccezioni continue, approvazioni viste come burocrazia. | Il controllo è stato progettato senza capire il flusso operativo. | Co-design: sicurezza e business ridisegnano insieme il processo. |
| “È troppo tecnico” | Il management delega tutto agli specialisti. | Il rischio non è tradotto in impatti economici e decisionali. | Report con scenari, impatti, opzioni e decisioni richieste. |
| “Non succederà a noi” | Bassa priorità, budget rinviati, test mai eseguiti. | Ottimismo organizzativo e assenza di memoria degli incidenti. | Simulazioni di crisi e casi concreti riferiti al settore. |
| “Abbiamo già una policy” | Documenti presenti ma non applicati, controlli non misurati. | Compliance documentale scambiata per controllo reale. | Verifiche operative, metriche, audit su evidenze e miglioramento continuo. |
| “La sicurezza è compito loro” | Segnalazioni tardive, scarsa ownership nei team. | Responsabilità percepita come esterna. | Risk owner per processo, formazione per ruolo, escalation chiara. |
La resistenza è anche emotiva
Parlare di rischio significa spesso mettere in discussione abitudini, autonomia, priorità e competenze. Un operatore può sentirsi controllato. Un responsabile può temere che l’emersione di un rischio diventi un’accusa di cattiva gestione. Un tecnico può vedere la governance come burocrazia. Un commerciale può temere di perdere un’opportunità. Per questo la gestione del rischio deve evitare la cultura della colpa. Un’organizzazione matura non punisce chi segnala un problema; al contrario, considera la segnalazione tempestiva un comportamento da premiare.
La Cybersecurity and Infrastructure Security Agency statunitense sintetizza questo principio parlando di responsabilità condivisa: la sicurezza funziona quando ciascuno comprende la propria parte nel rendere l’esperienza digitale più sicura. [14] La stessa logica vale in azienda: la sicurezza non può essere “di tutti” in modo generico; deve essere di ciascuno in modo concreto.
Quando anche la funzione sicurezza diventa resistente
Un punto delicato, spesso evitato, è che le resistenze non arrivano solo dal business. Possono nascere anche all’interno della funzione sicurezza. Accade quando la sicurezza si percepisce come presidio assediato, quando è sovraccarica di richieste, quando non ha abbastanza sponsor, quando parla un linguaggio troppo tecnico o quando misura il proprio valore solo in termini di blocchi e non di abilitazione sicura.
Il paradosso è frequente: l’azienda ha una funzione sicurezza, ma questa non riesce a influenzare davvero le decisioni. Viene coinvolta tardi, spesso alla fine dei progetti, quando modificare architettura, fornitore o processo costa troppo. A quel punto il team sicurezza può soltanto dire “no”, oppure accettare eccezioni che non avrebbe voluto concedere. In entrambi i casi perde credibilità.
La funzione sicurezza matura non è quella che blocca di più, ma quella che aiuta l’organizzazione a prendere decisioni migliori: più rapide quando il rischio è basso, più rigorose quando il rischio è alto, più documentate quando il rischio è accettato consapevolmente.
Il National Cyber Security Centre del Regno Unito, nel proprio toolkit per i board, insiste sul ruolo degli organi di governo nel fare in modo che cyber resilienza e risk management siano incorporati in persone, sistemi, processi e tecnologie. [11] Questo messaggio è essenziale: la funzione sicurezza non può essere lasciata sola. Deve essere sostenuta da governance, budget, mandato e accesso alle sedi decisionali.
Fonti e riferimenti
Fonti pubbliche, autorevoli e raggiungibili, consultate per l’aggiornamento del testo al 7 luglio 2026. I link sono cliccabili; le date indicano la data di pubblicazione, entrata in vigore, aggiornamento della pagina o applicazione normativa quando disponibile.
| ID | Fonte | Data / aggiornamento rilevante | Rilevanza | Link |
|---|---|---|---|---|
| [1] | Commissione europea — AI Act, Shaping Europe’s digital future | Pagina con timeline aggiornata; consultata 7 luglio 2026 | Calendario applicativo AI Act, governance e obblighi. | Apri |
| [2] | Commissione europea — General-Purpose AI Code of Practice | Codice pubblicato 10 luglio 2025; pagina aggiornata 23 aprile 2026 | Trasparenza, copyright, safety & security per modelli GPAI. | Apri |
| [3] | Commissione europea — Guidelines for providers of GPAI models | 28 aprile 2026 | Ambito degli obblighi GPAI e calendario di enforcement. | Apri |
| [4] | Gazzetta Ufficiale — D.Lgs. 4 settembre 2024, n. 138 | GU n. 230 del 1 ottobre 2024 | Recepimento italiano della Direttiva NIS2. | Apri |
| [5] | EIOPA — Digital Operational Resilience Act (DORA) | Applicazione dal 17 gennaio 2025 | Resilienza operativa digitale nel settore finanziario. | Apri |
| [6] | Commissione europea — Cyber Resilience Act | Entrata in vigore 10 dicembre 2024; reporting dal 11 settembre 2026 | Security by design per prodotti con elementi digitali e vulnerability reporting. | Apri |
| [6b] | Commissione europea — CRA reporting obligations | Obblighi di reporting dal 11 settembre 2026 | Tempistiche 24h, 72h e report finale per vulnerabilità/incidenti gravi. | Apri |
| [7] | NIST — Artificial Intelligence Risk Management Framework | AI RMF 1.0; pagina NIST consultata 7 luglio 2026 | Framework volontario per rischi AI verso persone, organizzazioni e società. | Apri |
| [8] | NIST — Cybersecurity Framework 2.0 | 26 febbraio 2024 | Introduzione della funzione Govern e ciclo di gestione del rischio cyber. | Apri |
| [9] | ISO — ISO 31000:2018 Risk management — Guidelines | Standard ISO 31000:2018 | Principi e processo di risk management integrato nell’organizzazione. | Apri |
| [10] | ENISA — Awareness and Cyber Hygiene | Pagina consultata 7 luglio 2026 | Awareness, cambiamento comportamentale e cyber hygiene. | Apri |
| [11] | NCSC UK — Cyber Security Toolkit for Boards | Toolkit consultato 7 luglio 2026 | Ruolo del board nel governo del rischio cyber e della resilienza. | Apri |
| [12] | IBM — Cost of a Data Breach Report 2025 | Report 2025 | Costi medi delle violazioni dati e AI oversight gap. | Apri |
| [13] | World Economic Forum — Global Cybersecurity Outlook 2026 | 12 gennaio 2026 | Trend 2026: AI, geopolitica, cyber inequity, pressioni su strategia e investimenti. | Apri |
| [14] | CISA — Cybersecurity Awareness Program | Pagina consultata 7 luglio 2026 | Cybersecurity come responsabilità condivisa. | Apri |
| [15] | OECD — AI Principles | Adottati nel 2019, aggiornati nel 2024 | Principi per AI affidabile, innovativa e rispettosa di diritti e valori democratici. | Apri |