SANS AI Security Maturity Model (AISMM): cosa dicono i 3 pilastri e i 5 livelli

La maggior parte delle organizzazioni è oramai conscia di avere un problema di sicurezza legato all’intelligenza artificiale. Il vero ostacolo non è la consapevolezza, ma la capacità di tradurla in azione: pochissime aziende riescono a produrre anche solo un inventario di base degli strumenti AI in uso.

Il nuovo AI Security Maturity Model (AI-SMM) del SANS Institute nasce proprio per colmare questo divario, offrendo un percorso strutturato — dal caos iniziale fino a un’organizzazione realmente “AI-native” — per valutare, misurare e far crescere la sicurezza e la governance dell’intelligenza artificiale.

 Scenario: un rischio già fuori controllo

Secondo il Data Breach Investigations Report (DBIR) 2026 di Verizon, il 45% dei dipendenti utilizza regolarmente l’AI su dispositivi aziendali (contro il 15% del 2025) e il 67% ricorre ad account personali.

Inoltre, il 38% dei file caricati su strumenti di AI proviene da account “ombra”, non da quelli approvati dall’azienda. Su oltre 858 mila eventi DLP (Data Loss Prevention) che coinvolgono applicazioni di GenAI, le categorie di dati più esposte sono: codice sorgente (28%), dati strutturati (14%) e documenti/PDF (23% in totale).

È doveroso evidenziare che, in media, un’organizzazione utilizza oggi tool basati sull’AI:

• 16 applicazioni
• 17 estensioni browser
• 17 integrazioni OAuth – la maggior parte non approvate.

Non sorprende, quindi, che lo shadow AI risulti la terza azione interna più comune registrata nel DBIR, con un aumento di quattro volte rispetto al 2025. Il problema, però, non è solo la superficie di attacco non gestita: è l’incapacità diffusa di dimostrare controlli concreti su ciascuno di questi strumenti.

È esattamente in questo divario tra consapevolezza e capacità operativa che la maggior parte delle organizzazioni resta bloccata.

Cos’è l’AI Security Maturity Model (AISMM) di SANS

L’AI-SMM è un framework operativo pensato per trasformare i principi di sicurezza e governance dell’AI in controlli, responsabilità, metriche e azioni concrete. Esso propone un percorso progressivo che parte da un uso non governato dell’AI e arriva a un’organizzazione capace di adattarsi autonomamente a nuove minacce e cambiamenti normativi.

È doveroso evidenziare che l’obiettivo del modello non è raggiungere il livello più alto a tutti i costi, ma identificare il livello coerente con:

• il profilo di adozione dell’AI dell’organizzazione;
• il settore di appartenenza;
• la superficie d’attacco;
• gli obblighi regolamentari;
• la tolleranza al rischio;
• gli obiettivi di business.

Di fatto, un’azienda che usa solo funzionalità AI integrate in applicazioni SaaS ha esigenze molto diverse da un’organizzazione che sviluppa sistemi agentici autonomi o impiega l’AI in infrastrutture critiche.

L’ebook completo di SANS Institute è disponibile qui.

I tre pilastri del modello: Protect, Utilize, Govern

Il modello si basa sui seguenti pilastri:

1. Protect

Riguarda la difesa di sistemi, modelli e applicazioni AI: attacchi avversari, prompt injection, data poisoning, identità degli agenti, estensioni browser compromesse e agenti IA che operano con permessi non controllati.

2. Utilize

Consiste nel rafforzare le operazioni di sicurezza impiegando l’AI per il rilevamento e per la valutazione delle minacce: threat detection, triage degli alert, threat hunting, automazione della risposta, threat intelligence, analisi predittiva e comportamentale, playbook automatizzati.

3. Govern

Gestisce come l’AI viene adottata e utilizzata in azienda: politiche di uso accettabile, individuazione dello shadow AI, classificazione dei dati, controlli di accesso, valutazione del rischio.

È il pilastro che riceve più attenzione nei consigli di amministrazione, anche per effetto dei requisiti normativi in vigore.

È doveroso evidenziare che i tre pilastri devono evolvere in modo equilibrato e la governance è la base abilitante. Ne consegue che, senza di essa, l’uso dell’AI per la sicurezza rischia di diventare sperimentazione incontrollata; mentre le misure di protezione restano prive di autorità, responsabilità e processi di supporto.

Le cinque fasi del modello

L’AI SMF di SANS delinea 5 fasi che le organizzazioni devono attraversare per raggiungere un livello di sicurezza ottimale. Vediamo come sono articolate.

1 – Inconsapevole/Ad Hoc (Unaware/Ad Hoc)

I dipendenti usano liberamente strumenti di AI senza supervisione; non esiste un inventario e la dirigenza spesso non sa nemmeno quanta AI sia realmente in uso. Inoltre, non essendoci ancora in essere una policy nell’organizzazione, non si tratta tecnicamente di shadow AI, ma semplicemente di adozione non gestita.

Ne consegue che risulta prioritario: creare visibilità e responsabilità; rilevare l’AI in uso; nominare un owner; redigere una policy; erogare la formazione; stabilire i controlli di accesso di base.

Inoltre, la classificazione dei dati è considerata un prerequisito imprescindibile: non si può scrivere una policy IA efficace senza sapere quali dati sono sensibili e dove risiedono.

2 – Reattiva/Emergente in termini di politiche (Reactive/Policy Emerging)

L’organizzazione riconosce l’AI come fattore di rischio e introduce le prime policy e i controlli, spesso ancora semplicistici (i.e. divieti generalizzati, blocklist/allowlist).

SANS segnala, in questa fase, il rischio del cosiddetto “Framework of No”, ovvero: policy troppo restrittive spingono gli utenti verso strumenti non autorizzati, alimentando la shadow AI.

DI fatto, il problema non è impedire l’uso dell’AI, ma renderlo visibile e governabile.

Di seguito le azioni chiave per progredire alla fase successiva:

• istituire un organismo di governance interfunzionale;
• effettuare discovery tecnica del BYOAI;
• sviluppare policy articolate per caso d’uso e classificazione dei dati;
• implementare controlli DLP “AI-aware”;
• creare un inventario parziale degli asset AI;
• introdurre criteri di valutazione dei fornitori;
• monitorare e registrare l’uso degli strumenti AI.

3 – Definita/Informata sul rischio (Defined/Risk-Informed)

La fase è caratterizzata dal passaggio a una gestione intenzionale e basata sul rischio. L’organizzazione dispone di una governance formale, integra l’AI nei processi di gestione del rischio e utilizza strumenti aziendali autorizzati, anziché affidarsi esclusivamente a divieti.

Tra gli indicatori più significativi figurano: inventario completo di sistemi, modelli e agenti; documentazione dei flussi di dati e della data lineage; identità distinte per gli agenti IA; accessi API e privilegi rigorosamente limitati; difese contro prompt injection e manipulation; input validation e output filtering; penetration test e adversarial testing; verifica della provenienza dei modelli; controlli mappati sulle tecniche MITRE ATLAS; logging strutturato degli step degli agenti e delle chiamate ai tool; assegnazione di un responsabile umano per ogni agente.

È importante evidenziare che a questo livello emergono due concetti centrali, quali:

• Non-Human Identity (NHI) – Ogni agente deve avere un’identità distinta, credenziali a permessi limitati e un owner umano identificabile.
• Principle of Least Agency – Analogo al minimo privilegio, consiste nel verificare se l’obiettivo è raggiungibile con un’architettura meno autonoma, prima di concedere autonomia a un agente.

4 – Gestita/Integrata (Managed /Integrated)

Siamo dinanzi ad una gestione quantitativa e integrata. L’AI è incorporata nelle operation di sicurezza, mentre la sicurezza viene integrata nel ciclo di vita di sviluppo dei modelli e degli agenti.

Le caratteristiche di questa fase includono:

• threat modeling obbligatorio per i sistemi AI;
• red teaming specifico per prompt injection, model extraction e manipulation;
• adversarial testing automatizzato nelle pipeline CI/CD;
• MLSecOps per pipeline di training, versioning e provenienza dei modelli;
• execution guardrails e monitoraggio in tempo reale delle chiamate API;
• difese contro il Confused Deputy, per impedire che input non affidabili inducano un agente a utilizzare strumenti privilegiati;
• controlli contro i guasti a cascata nei sistemi multi-agente;
• modelli ML personalizzati per il rilevamento delle minacce;
• threat hunting supportato dall’AI;
• risposta autonoma in scenari definiti e validati;
• governance integrata con l’Enterprise Risk Management (ERP);
• quantificazione del rischio IA e definizione del risk appetite;
• monitoraggio di bias, fairness e tracciabilità delle decisioni.

Inoltre, con l’accelerazione degli attacchi supportati dall’AI, anche le decisioni di autorizzazione degli agenti devono operare a velocità quasi automatica. Pertanto, per le azioni ordinarie sono indicati controlli come Just-in-Time access, intent validation e consequence-based authorization.

Ancora, la revisione umana dovrebbe essere riservata alle operazioni ad alto impatto o irreversibili.

In questa fase l’AI risulta essere profondamente integrata nelle operazioni di sicurezza, con risultati misurabili: i sistemi di AI sono protetti by design; il rischio è quantificato (non stimato) ; le decisioni sono data-driven.

È il livello in cui un’organizzazione può gestire le minacce specifiche dell’AI, operando al ritmo richiesto da avversari a loro volta potenziati dall’AI.

5 – Ottimizzazione/Adattamento (Optimizing/Adaptive)

Rappresenta il traguardo della maturità: l’AI non è più solo uno strumento di supporto, ma una componente fondamentale delle operazioni di sicurezza e della resilienza aziendale.

All’interno delle organizzazioni sono presenti:

• difese adattive e auto-miglioranti;
• rilevamento autonomo di tecniche adversariali nuove;
• architetture Zero Trust estese agli agenti autonomi;
• permessi contestuali e just-in-time;
• chaos engineering applicato ai sistemi AI;
• self-healing security infrastructure;
• predictive defense;
• simulazione di attacchi con AI generativa;
• correlazione inter-organizzativa delle minacce;
• capacità di previsione dell’evoluzione normativa; programmi di ricerca e contributi agli standard di settore.

È doveroso evidenziare che il livello 5 non è un obiettivo necessario per tutte le organizzazioni. È soprattutto da considerarsi un percorso pluriennale per aziende AI-native, grandi imprese tecnologiche, operatori della difesa e organizzazioni che intendono fare della sicurezza IA un elemento distintivo.

L’approccio evidence-based: la maturità si dimostra, non si dichiara

Uno degli aspetti più interessanti del framework è il principio dell’evidence-based approach: ogni domanda di assessment viene valutata su una scala da 0 a 5:

• 0 – Non presente: non esistono evidenze;
• 1 – Ad hoc: esistono solo attività occasionali o dipendenti da singole persone;
• 2 – In sviluppo: è presente un piano o una policy parziale;
• 3 – Stabilito: policy approvate e applicazione coerente;
• 4 – Misurato: metriche, dashboard e decisioni basate sui dati;
• 5 – Ottimizzato: miglioramento continuo, analisi dei trend e adattamento proattivo.

Una regola importante è che le capacità autodichiarate, senza evidenze documentali, non possono superare il livello 2. Inoltre, le evidenze ammesse includono: policy approvate, screenshot di configurazione, risultati di test, audit log, report e dashboard.

Il punteggio complessivo deriva dalla ponderazione dei tre pilastri, con questa distribuzione di default:

35% – Protect

30% – Utilize

35% – Govern

Il modello SANS ha previsto, altresì, ponderazioni diverse per settori, quali: servizi finanziari, sanità, tecnologia, difesa, infrastrutture critiche e educazione.

Il framework introduce, inoltre, due limiti pensati per evitare che una media complessiva mascheri criticità strutturali e, precisamente:

• il livello complessivo non può superare di più di uno il livello del pilastro “Govern”;
• il livello complessivo non può superare di più di uno il pilastro con il punteggio più basso.

In altre parole: un’organizzazione non può dichiararsi “matura” se presenta lacune rilevanti nella governance o in uno qualsiasi dei tre pilastri fondamentali.

Come il modello si collega a normative e standard esistenti

Il modello è progettato per collegarsi a diversi framework e standard, tra cui:

• NIST AI Risk Management Framework;
• EU AI Act;
• ISO/IEC 42001;
• OWASP AI Exchange;
• MITRE ATLAS;
• Cloud Security Alliance AI Controls Matrix;
• linee guida CISA per l’integrazione sicura dell’IA nell’Operational Technology.

La sua utilità principale consiste nel colmare il divario tra i principi generali degli standard e l’implementazione operativa. Di fatto, mentre un regolamento o uno standard può definire responsabilità, controlli e obiettivi, l’AISMM fornisce una progressione concreta, ovvero: cosa fare prima, quali prerequisiti rispettare, come misurare i risultati e quali capacità sviluppare per il passaggio al livello successivo.

Per le organizzazioni europee, il modello può quindi essere utilizzato come:

• strumento preliminare di gap assessment;
• supporto alla preparazione dei controlli richiesti dall’AI Act;
• modello per definire ownership e accountability;
• base per integrare l’AI nel sistema di enterprise risk management;
• riferimento per programmi di AI security, MLSecOps e AI incident response;
• linguaggio comune per collegare sicurezza, compliance, IT, procurement e business.

Si rimanda alla pubblicazione di SANS Institute per maggiori dettagli sulle fasi, requisiti e come progredire nelle fasi.

Punti di forza e limiti del modello: una valutazione

Il principale punto di forza del framework è la sua natura operativa: il modello non tratta la sicurezza IA come un insieme di soli requisiti tecnici, bensì la collega a persone, processi, dati, responsabilità, strumenti e metriche.

Inoltre, risulta particolarmente interessante l’attenzione alla gestione degli agenti autonomi, alle identità non umane, alla tracciabilità delle azioni e alla distinzione tra incidenti di sicurezza e incidenti di safety/affidabilità.

Un secondo elemento di valore del modello è il rifiuto della “maturità nominale”. Ovvero, l’organizzazione deve dimostrare ciò che dichiara attraverso evidenze verificabili. Inoltre, una buona performance tecnica non può compensare una governance debole.

Il modello va, comunque, applicato con attenzione: le tempistiche indicate sono orientative e i livelli più avanzati richiedono competenze specialistiche, investimenti, qualità dei dati, capacità di monitoraggio e sponsorship executive.

Inoltre, la maturità non dovrebbe essere perseguita come un traguardo reputazionale, ma come strumento per ridurre il rischio e sostenere un’adozione dell’IA coerente con il contesto aziendale.

La parola all’esperto di settore; Fabrizio Degni

Fabrizio Degni, ricercatore in etica e governance dell’AI, presidente Italiano del Global Council for Responsible AI, commenta: “«Da Chief AI Officer, considero il modello SANS un riferimento utile per affrontare una questione che accompagna ogni percorso di adozione dell’intelligenza artificiale: su quali basi un’organizzazione decide che un sistema può essere utilizzato, con quale autonomia e sotto la responsabilità di chi?

La maturità si costruisce rendendo queste decisioni verificabili e aggiornandole quando cambiano le condizioni che le hanno rese possibili. Il passaggio più impegnativo consiste nel collegare gli obiettivi di business ai controlli effettivamente applicati, con evidenze che permettano di valutarne l’efficacia. In questa prospettiva, la governance diventa parte delle scelte di progettazione, acquisto e utilizzo dell’AI, fin dalle prime sperimentazioni.

Per tradurre questa impostazione in pratica, occorre partire da ciascun caso d’uso e renderne espliciti lo scopo, i dati coinvolti, le responsabilità e le condizioni di approvazione. A ciascun controllo devono corrispondere evidenze pertinenti al sistema esaminato: una policy approvata documenta una decisione organizzativa; un test o una verifica operativa aiutano a stabilire se quella decisione trova applicazione. Bisogna inoltre sapere a quale versione del sistema si riferiscano le evidenze e quando debbano essere riesaminate. Un aggiornamento del modello, l’introduzione di un nuovo strumento o un cambiamento nei dati utilizzati possono modificare il rischio e richiedere una nuova valutazione. Il presidio deve quindi accompagnare l’intero ciclo di vita, includendo incidenti, eccezioni e dismissione”.

Inoltre, Degni evidenzia: “Questa continuità richiede anche un monitoraggio dei cambiamenti nelle policy pubbliche dei fornitori. Un esempio concreto è la modifica delle condizioni di conservazione o utilizzo dei dati: il valore del monitoraggio consiste nel consentire all’organizzazione di individuare i servizi interessati e risalire ai casi d’uso che ne dipendono. Le informazioni raccolte devono alimentare il riesame dei controlli e delle evidenze associati a quei casi. Occorre poi valutare l’effettiva applicabilità del cambiamento, documentare il giudizio del responsabile e stabilire se mantenere l’approvazione, introdurre condizioni aggiuntive o sospendere l’utilizzo. La rilevazione del segnale e la decisione sulla sua rilevanza sono passaggi distinti, ciascuno con proprie evidenze. Questa distinzione rende il monitoraggio utile alle decisioni aziendali e preserva la responsabilità umana nell’interpretazione.

Nei sistemi agentici, la stessa impostazione richiede di governare le azioni che l’AI può compiere. L’autonomia deve avere un perimetro definito rispetto allo scopo, alle risorse accessibili e alle conseguenze delle operazioni. Un agente che consulta informazioni e uno che modifica dati aziendali o dispone una transazione richiedono condizioni di delega differenti. Nella governance dei sistemi agentici, un punto centrale è distinguere l’autorizzazione dell’azione dalla verifica dei suoi effetti. Un’operazione consentita può produrre un risultato inatteso o lasciare uno stato incerto: servono quindi riscontri sull’esito effettivo e criteri per attivare una revisione o sospendere ulteriori operazioni. La supervisione umana acquista consistenza quando chi ne è responsabile dispone di competenze, informazioni e strumenti per intervenire tempestivamente”.

Degni suggerisce, altresì: “Per gli agenti, aggiungerei il monitoraggio degli esiti inattesi o non verificabili e delle successive azioni correttive. Sono elementi che aiutano a stabilire dove concentrare gli investimenti e quali condizioni soddisfare prima di ampliare l’autonomia.

Il Chief AI Officer deve costruire questo raccordo con il CISO, le funzioni legali e i responsabili di business, affinché le decisioni sull’A abbiano un responsabile riconoscibile e un fondamento condiviso”.

Ancora Degni evidenzia: “Il livello di maturità da perseguire va, infine, rapportato all’esposizione concreta dell’organizzazione. Anche un perimetro limitato di utilizzo dell’IA richiede responsabilità chiare e controlli applicati con continuità; la crescita dell’autonomia e dell’impatto delle decisioni richiede verifiche più profonde. Un approccio proporzionato deve rendere ricostruibile il percorso che conduce da un requisito o da un cambiamento osservato a una decisione operativa. Su queste basi, l’organizzazione può estendere l’adozione dell’IA sapendo quali rischi accetta, quali condizioni deve mantenere e quali eventi richiedono di rivedere le proprie scelte”.

Conclusione: a quale livello deve puntare un’organizzazione?

Per la maggior parte delle organizzazioni, il traguardo realistico è raggiungere almeno il Livello 3, ovvero: governance formale, gestione del rischio, inventario degli asset, responsabilità definite e controlli tecnici mirati.

Mentre, le imprese che operano in settori regolamentati, gestiscono dati sensibili o utilizzano sistemi AI agentici dovrebbero considerare il Livello 4 come obiettivo strategico.

Il Livello 5 resta, quindi, una frontiera per le organizzazioni che vogliono fare della sicurezza AI una capacità adattiva e un vero vantaggio competitivo.

Concludendo, si raccomanda alle organizzazioni di avviare quanto prima un assessment strutturato della propria maturità in materia di sicurezza AI, considerando il framework SANS come un buon riferimento metodologico per definire priorità, responsabilità e piani di investimento coerenti con il proprio profilo di rischio.”