Scegliere un framework di sicurezza dell’IA prima di un audit sull’AI Act o di una certificazione ISO è diventato un esercizio di triage: il mercato ne offre più di quindici, pubblicati da legislatori, enti di normazione, agenzie e fornitori cloud, e ciascuno risponde a una domanda diversa. Li confrontiamo in quattro famiglie, poi chiudiamo con una regola di selezione per ruolo dell’operatore e con l’elenco delle evidenze che un auditor accetta.
In sintesi
- Prima della scelta viene la domanda: la legge dice che cosa provare, i cataloghi che cosa testare, i controlli che cosa dimostrare, le architetture chi ne risponde.
- Ottobre 2026 cambia la risposta: ISO/IEC 27090 è pubblicata, EN 18286 è la prima norma armonizzata in Gazzetta ufficiale, prEN 18282 ha chiuso l’inchiesta pubblica.
- Il nuovo articolo 42, paragrafo 3, consente ai prodotti con elementi digitali ad alto rischio di provare la cibersicurezza tramite il Cyber Resilience Act.
- Tra i framework dell’industria, solo CSA AICM e DASF mappano i controlli sull’AI Act e su ISO/IEC 42001.
- Un framework di sicurezza dell’IA efficace unisce controlli, catalogo delle minacce e modello di responsabilità, mappati una volta sull’articolo 15.
Che cos’è un framework di sicurezza dell’IA (e che cosa non è)
Per framework di sicurezza dell’IA intendiamo un insieme nominato e versionato di minacce, controlli o responsabilità per proteggere un sistema di IA (dati, modello, pipeline, applicazione, agenti), rispetto al quale un terzo può verificarvi. L’ultima condizione è decisiva: se nessuno può misurarvi su quel testo, avete una buona pratica, non un framework.
Quattro famiglie, quattro domande:
- la legge dice che cosa provare: articoli 15 e 55, paragrafo 1, lettera d), dell’AI Act, Cyber Resilience Act;
- i cataloghi delle minacce dicono che cosa testare: MITRE ATLAS, OWASP, NIST AI 100-2;
- gli insiemi di controlli dicono che cosa dimostrare: CSA AICM, DASF, allegato A di ISO/IEC 42001, ISO/IEC 27090, overlay NIST, ETSI EN 304 223, ENISA;
- le guide di architettura e responsabilità dicono chi possiede che cosa: SAIF, CoSAI, AWS, Microsoft.
ATLAS e ISO/IEC 42001 non si confrontano: il primo cataloga attacchi, il secondo prescrive procedure. Per questo un framework di sicurezza dell’IA completo prende un elemento per famiglia e lo mappa una sola volta.
Che cosa non è. Non è un prodotto di AI security posture management (AI-SPM), che è una categoria di strumenti. Non è un framework di safety: Cisco sostiene, il 16 dicembre 2025, che security e safety sono inseparabili, ma l’AI Act le tratta in articoli distinti. E non è il framework di governance dell’IA, di cui la sicurezza è un capitolo. Il quadro generale: la nostra guida sulla sicurezza dell’IA.
La mappa 2026: i framework in una tabella
| Framework | Editore | Famiglia | Ultima versione (data) | Dimensione | Mappatura su legge o norma |
|---|---|---|---|---|---|
| AI Act, articolo 15 | Unione europea | Legge | Reg. (UE) 2024/1689; 2 dicembre 2027 (allegato III), 2 agosto 2028 (allegato I) | un articolo, sei classi di attacco nominate | è la legge |
| Cyber Resilience Act | Unione europea | Legge | Reg. (UE) 2024/2847; segnalazioni dall’11 settembre 2026, piena applicazione dall’11 dicembre 2027 | requisiti essenziali dell’allegato I | art. 12(1): cibersicurezza dell’art. 15 considerata soddisfatta |
| prEN 18282 | CEN-CENELEC JTC 21 | Norma armonizzata (progetto) | inchiesta pubblica dal 15 maggio al 14 luglio 2026 | non pubblica | scritta per l’articolo 15 |
| ISO/IEC 27090:2026 | ISO/IEC JTC 1/SC 27 | Linee guida | pubblicata a ottobre 2026, 56 pagine | linee guida, non certificabile | evidenza negli audit ISO/IEC 27001 e 42001 |
| ISO/IEC 42001:2023, allegato A | ISO/IEC JTC 1/SC 42 | Sistema di gestione certificabile | dicembre 2023 | controlli dell’allegato A (A.6.2, A.7, A.8.4, A.10.3) | certificato |
| NIST AI RMF 1.0 e NIST AI 600-1 | NIST | Framework di rischio | gennaio 2023, luglio 2024 | quattro funzioni, caratteristica «secure and resilient» | volontario; mappato da AICM e DASF |
| NIST Cyber AI Profile (NIST IR 8596) | NIST e MITRE | Profilo di comunità CSF 2.0 | bozza preliminare iniziale del 16 dicembre 2025; nessuna bozza pubblica finora | tre aree (Secure, Defend, Thwart) | CSF 2.0 e AI RMF |
| NIST SP 800-53 Control Overlays for Securing AI Systems | NIST | Overlay di controlli | concept paper del 14 agosto 2025; nessun overlay in bozza | cinque overlay | SP 800-53 Rev. 5 |
| NIST AI 100-2 E2025 | NIST | Tassonomia delle minacce | 24 marzo 2025, 127 pagine | due tassonomie (IA predittiva e generativa) | nessuna |
| Guidelines for Secure AI System Development | NCSC e CISA, 23 organizzazioni firmatarie | Guida al ciclo di vita | 27 novembre 2023 | quattro fasi | nessuna |
| ETSI EN 304 223 | ETSI (dal codice di condotta britannico) | Requisiti di base | TS aprile 2025, EN dicembre 2025 | 13 principi, 72 disposizioni, cinque fasi | nessuna |
| ENISA FAICP | ENISA | Framework di buone pratiche | 7 giugno 2023 | tre livelli | considerando 78 dell’AI Act (cooperazione) |
| MITRE ATLAS | MITRE | Base di conoscenza delle minacce | release 2026.10 (28 ottobre 2026) | 16 tattiche, 129 tecniche, 92 sotto-tecniche, 44 mitigazioni | ATT&CK |
| OWASP Top 10 for LLM 2026, Agentic Top 10, AI Exchange | OWASP GenAI Security Project | Liste di minacce e guida ai controlli | agosto 2026, dicembre 2025, flagship da marzo 2025 | 10 + 10 voci, oltre 50 controlli | NIST, ATLAS, CWE; l’AI Exchange ha contribuito a ISO/IEC 27090 e prEN 18282 |
| CSA AI Controls Matrix | Cloud Security Alliance | Insieme di controlli | v1.1, 22 giugno 2026 | 247 controlli, 18 domini, AI-CAIQ di 320 domande | ISO/IEC 42001, ISO 27001, NIST AI RMF, AI 600-1, BSI AIC4, AI Act |
| Databricks DASF | Databricks | Insieme di controlli | v3.0, 20 marzo 2026 | 13 componenti, 97 rischi, 73 controlli | ATLAS, OWASP, SP 800-53, CSF, ENISA, ISO/IEC 42001, 27001, AI Act |
| Google SAIF | Google (dati donati a CoSAI) | Architettura e mappa dei rischi | SAIF 2.0, 6 ottobre 2025 | 15 rischi, 24 controlli, tre principi per gli agenti | nessuna |
| CoSAI, AWS, Microsoft | OASIS, AWS, Microsoft | Responsabilità condivisa e perimetro | CoSAI Shared Responsibility Framework v1.0, maggio 2026; AWS AI Security Framework, maggio 2026; modello Microsoft per gli agenti, agosto 2026 | livelli, perimetri, principi | nessuna (riferimenti a OWASP e ATLAS) |
La tabella dice che cos’è ciascun riferimento, non quale adottare: decidono le famiglie. Una lista di minacce non sostituisce una legge, e un catalogo come MITRE ATLAS non produce da solo evidenze. L’Integrated AI Security and Safety Framework di Cisco (16 dicembre 2025, 19 obiettivi dell’attaccante, oltre 150 tecniche) è una tassonomia: sta con i cataloghi delle minacce. Nessun framework di sicurezza dell’IA della tabella risponde da solo alle quattro domande.
Cataloghi delle minacce: che cosa testare secondo l’articolo 15, paragrafo 5
L’articolo 15, paragrafo 5, dell’AI Act chiede che i sistemi ad alto rischio resistano ai tentativi di terzi non autorizzati di modificarne l’uso, gli output o le prestazioni, e nomina gli attacchi da prevenire, accertare e contrastare: «avvelenamento dei dati», «avvelenamento del modello», «esempi antagonistici» o «evasione dal modello», attacchi alla riservatezza, difetti del modello. La legge elenca le classi, non dice come testarle: è il compito dei cataloghi dentro un framework di sicurezza dell’IA.
MITRE ATLAS, release 2026.10 del 28 ottobre 2026: 16 tattiche, 129 tecniche, 92 sotto-tecniche, 44 mitigazioni, 77 casi di studio. Le prime tecniche agentiche sono arrivate con la v5.0.0 del 30 settembre 2025; da metà 2026 le release sono mensili.
L’OWASP Top 10 per gli LLM 2026 (3 agosto 2026) elenca LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses, LLM10 Improper Output Handling. L’Agentic Top 10 del 9 dicembre 2025 va da ASI01 Agent Goal Hijack ad ASI10 Rogue Agents.
La tassonomia NIST AI 100-2 E2025 del 24 marzo 2025 separa IA predittiva (evasione, avvelenamento, privacy) e IA generativa (catena di fornitura, prompt injection diretta e indiretta, agenti), con aggiornamenti annuali previsti. Sulla meccanica degli attacchi: la nostra guida sull’IA avversaria. La nostra mappatura di lavoro:
| Classe di attacco (art. 15, par. 5) | MITRE ATLAS | OWASP | NIST AI 100-2 |
|---|---|---|---|
| Avvelenamento dei dati | tecniche di avvelenamento | LLM05 | avvelenamento |
| Avvelenamento del modello | tecniche di supply chain e di avvelenamento | LLM04 e LLM05 | avvelenamento e catena di fornitura |
| Esempi antagonistici o evasione dal modello | tecniche di evasione | LLM01 per l’evasione a livello di prompt | evasione |
| Attacchi alla riservatezza | tecniche di esfiltrazione e di inferenza | LLM02 | privacy |
| Difetti del modello | non è una classe di attacco | LLM07, LLM10 | nessuna voce dedicata |
| Alterazione non autorizzata di uso o output | avvelenamento del contesto e configurazione degli agenti (AML.T0080, AML.T0081) | ASI03, ASI06 | sezione sugli agenti |
Insiemi di controlli: dove il framework di sicurezza dell’IA diventa evidenza
Un catalogo dice che cosa testare; un insieme di controlli, che cosa mostrare. È qui che un framework di sicurezza dell’IA diventa evidenza.
La CSA AI Controls Matrix v1.1 del 22 giugno 2026 conta 247 obiettivi di controllo in 18 domini e cinque pilastri, mappati con gap analysis su ISO/IEC 42001, ISO 27001, NIST AI RMF, AI 600-1, BSI AIC4 e AI Act. Si aggiungono il questionario AI-CAIQ (320 domande) e STAR for AI: livello 1 in autovalutazione, livello 2 certificato su base ISO 42001 o 27001. È la scelta naturale se gestite già la CCM o ISO 27001.
DASF 3.0, del 20 marzo 2026: 13 componenti, 97 rischi, 73 controlli, schede di applicabilità e mappature su ATLAS, OWASP, SP 800-53, CSF, ENISA, ISO/IEC 42001, ISO/IEC 27001 e AI Act. Nato per una piattaforma, rende al meglio in un lakehouse.
ISO/IEC 42001 porta la sicurezza in alcuni controlli dell’allegato A: A.6.2.2 (requisiti), A.6.2.4 (verifica e validazione), A.6.2.5 (rilascio), A.6.2.6 (esercizio e monitoraggio), A.6.2.7 (documentazione tecnica), A.6.2.8 (registri degli eventi), da A.7.2 ad A.7.6 (dati), A.8.4 (comunicazione degli incidenti), A.10.3 (fornitori). ISO/IEC 27090:2026 spiega a un auditor ISO 27001 o 42001 che cosa significa proteggere un sistema di IA: 56 pagine, SC 27, non certificabile. ISO/IEC 27091 (privacy) è allo stadio FDIS da luglio 2026.
Gli overlay NIST SP 800-53 (concept paper del 14 agosto 2025, uno schema annotato a gennaio 2026, nessun overlay in bozza) e il Cyber AI Profile (bozza preliminare iniziale del 16 dicembre 2025, commenti chiusi il 30 gennaio 2026) non sono ancora una base da citare, e il NIST AI RMF non contiene controlli. Per chi parte dal NIST CSF, il profilo sarà il ponte naturale.
ETSI EN 304 223, nato dal codice di condotta britannico del 31 gennaio 2025, è l’unica base con disposizioni numerate: 13 principi, 72 disposizioni, cinque fasi. Le linee guida NCSC e CISA (quattro fasi) e la guida CISA sull’IA agentica del 1° maggio 2026 sono pratica di rilascio; i tre livelli del FAICP di ENISA ricordano che la cybersicurezza generale viene prima.
La regola: un solo insieme di controlli, con una gap analysis rispetto alla legge, tenuto come documento vivo del vostro framework di sicurezza dell’IA.
Architettura e responsabilità condivisa: SAIF, CoSAI, AWS, Microsoft
SAIF 2.0 di Google, annunciato il 6 ottobre 2025, conta quattro aree di componenti, 15 rischi e 24 controlli, più tre principi per gli agenti: controllori umani ben definiti, poteri limitati, azioni e pianificazione osservabili. Un’autovalutazione produce un report di rischio. A settembre 2025 Google ha donato i dati di SAIF a CoSAI, dove sono diventati la CoSAI Risk Map.
CoSAI (OASIS, lanciata a luglio 2024) ha pubblicato i principi per sistemi agentici sicuri fin dalla progettazione (16 luglio 2025: governati dalle persone e responsabili, delimitati e resilienti, trasparenti e verificabili), un AI Incident Response Framework (ottobre 2025, playbook mappati su ATLAS), l’AI Shared Responsibility Framework v1.0 (maggio 2026, cinque livelli, una parte responsabile per componente), MCP Security v2.0 (settembre 2026) e Zero Trust for AI Systems (16 settembre 2026).
AWS propone la Generative AI Security Scoping Matrix (cinque perimetri, ottobre 2023), l’Agentic AI Security Scoping Matrix (quattro perimetri, novembre 2025) e l’AWS AI Security Framework di maggio 2026: tre livelli, tre fasi, controlli cumulativi. Microsoft documenta un modello di responsabilità condivisa per l’IA e, da agosto 2026, un modello per gli agenti con rischi mappati su OWASP e ATLAS. Sugli agenti: la nostra analisi sulla protezione dei sistemi agentici.
Il nostro verdetto: questi testi rispondono a «chi possiede quale controllo» e a «dove si colloca». Nessuno, Cisco compreso, è mappato sull’articolo 15. In un framework di sicurezza dell’IA servono a ripartire i controlli tra voi, il cloud e il fornitore del modello, mai a dichiarare la conformità.
Il diritto dietro il framework di sicurezza dell’IA: articolo 15, articolo 42(3), Cyber Resilience Act
L’articolo 15, paragrafo 1, chiede un livello adeguato di accuratezza, robustezza e cibersicurezza, costante per tutto il ciclo di vita; il paragrafo 4, resilienza a errori e guasti, ridondanza tecnica e, per i sistemi che continuano ad apprendere, gestione dei circuiti di feedback; il paragrafo 5 nomina le classi di attacco. L’articolo 13, paragrafo 3, lettera b), punto ii), vuole che le istruzioni per l’uso dichiarino il livello di accuratezza, robustezza e cibersicurezza testato. Per i modelli per finalità generali con rischio sistemico, l’articolo 55, paragrafo 1, lettere a) e d), impone dal 2 agosto 2025 test avversariali documentati e un’adeguata cibersicurezza del modello e della sua infrastruttura fisica.
Due vie per provare la cibersicurezza. Per l’articolo 42, paragrafo 2, un certificato del Cybersecurity Act (Regolamento (UE) 2019/881) fa presumere la conformità alla cibersicurezza dell’articolo 15, dal 2 agosto 2026. Il nuovo paragrafo 3, introdotto dall’Omnibus digitale sull’IA (Regolamento (UE) 2026/1744, in vigore dal 27 luglio 2026), rinvia all’articolo 12, paragrafo 1, del Cyber Resilience Act: un sistema ad alto rischio che è un prodotto con elementi digitali è considerato conforme alla cibersicurezza dell’articolo 15 se rispetta i requisiti essenziali del CRA e la dichiarazione di conformità UE del CRA lo dimostra. Gli organismi notificati dell’AI Act possono verificare anche i requisiti CRA (articolo 12, paragrafo 2). Il considerando 77 fissa il perimetro: solo cibersicurezza, non robustezza né accuratezza.
Calendario dei sistemi ad alto rischio: allegato III dal 2 dicembre 2027, allegato I dal 2 agosto 2028; CRA: segnalazioni dall’11 settembre 2026, piena applicazione dall’11 dicembre 2027.
Quanto alle norme, EN 18286 (sistema di gestione della qualità) è stata citata in Gazzetta ufficiale a ottobre 2026 con la decisione di esecuzione (UE) 2026/2274: è la prima norma armonizzata dell’AI Act. prEN 18282, le specifiche di cibersicurezza per i sistemi di IA del JTC 21 WG 5, ha chiuso l’inchiesta pubblica (15 maggio-14 luglio 2026); la richiesta di normazione scade il 28 febbraio 2027. Come si incastrano le norme: quali norme servono davvero per l’AI Act.
ENISA aggiunge al FAICP il parere sull’IA di frontiera del 7 luglio 2026 (NIS2, CRA e AI Act da leggere insieme per i modelli a rischio sistemico), uscito con il piano d’azione UE su cybersicurezza e IA; l’ENISA Threat Landscape 2026 (22 settembre 2026) mette gli attacchi abilitati dall’IA tra le minacce principali.
Infine l’articolo 73: una violazione di sicurezza si notifica solo se è un incidente grave ai sensi dell’articolo 3, punto 49 (vedi segnalazione degli incidenti); il deployer monitora e sospende in base all’articolo 26, paragrafo 5. Ogni framework di sicurezza dell’IA va letto alla luce di questi articoli.
Come scegliere: una regola di selezione per ruolo dell’operatore
| Il vostro ruolo | Ancoraggio giuridico | Catalogo delle minacce | Insieme di controlli | Evidenze che un auditor accetta |
|---|---|---|---|---|
| Fornitore di un sistema di IA ad alto rischio | articoli 9, 11, 13, 15, 43 | ATLAS, OWASP, NIST AI 100-2 | allegato A di ISO/IEC 42001 o CSA AICM; prEN 18282 una volta armonizzata | sezione cibersicurezza dell’allegato IV, report di test e di red teaming, metriche nelle istruzioni per l’uso, dichiarazione di conformità UE |
| Fornitore di un prodotto con elementi digitali | articolo 12 del CRA, articolo 42(3) dell’AI Act | gli stessi | requisiti essenziali dell’allegato I del CRA | dichiarazione di conformità CRA che attesta il livello dell’articolo 15 |
| Deployer | articoli 26 e 73 | OWASP Agentic Top 10 per gli agenti | AI-CAIQ al fornitore, matrice di responsabilità condivisa (CoSAI, AWS o Microsoft), monitoraggio | questionario del fornitore, registro delle istruzioni per l’uso, log di monitoraggio, decisione di sospensione |
| Fornitore di GPAI con rischio sistemico | articolo 55, paragrafo 1, lettere a) e d) | ATLAS, valutazioni dei modelli di frontiera | CoSAI, il parere ENISA, il codice di buone pratiche | test avversariali documentati, misure di cibersicurezza per modello e infrastruttura |
| Impresa che sviluppa su una piattaforma cloud | articolo 15 o 26 secondo il ruolo | OWASP Top 10 per gli LLM | il framework della piattaforma (SAIF, DASF, AWS, Microsoft) come livello di implementazione, AICM per la dichiarazione di conformità | mappatura dei controlli con gap analysis |
Tre regole completano la tabella. Primo: un solo insieme di controlli, un solo catalogo delle minacce, un solo modello di responsabilità; aggiungerne altri moltiplica le mappature, non le evidenze. Secondo: ciascuno va mappato una volta sulle sei classi dell’articolo 15, paragrafo 5, e quella mappatura diventa l’indice del fascicolo per la valutazione della conformità. Terzo: la mappatura resta sotto controllo delle modifiche, perché una nuova versione del framework, un nuovo modello o un nuovo agente la riaprono. Con release ATLAS mensili, un framework di sicurezza dell’IA congelato al giorno dell’audit è già datato a quello successivo.
In Italia l’ACN (Agenzia per la cybersicurezza nazionale) e AgID sono le autorità nazionali per l’IA designate dalla legge 132/2025. Il Framework Nazionale per la Cybersecurity e la Data Protection, costruito sul NIST CSF, è il riferimento nazionale: conviene mapparvi anche il framework di sicurezza dell’IA scelto. Per i dati personali in addestramento e inferenza, l’interlocutore è il Garante per la protezione dei dati personali.
Dal framework di sicurezza dell’IA alle evidenze di audit
All’auditor non interessa quale framework avete scelto, ma che cosa potete mostrare. Sette documenti:
- La mappatura dei controlli con gap analysis rispetto all’articolo 15. AICM e DASF ne forniscono una ciascuno; partire da lì costa meno, purché ogni lacuna abbia un responsabile e una scadenza.
- Il modello delle minacce di ogni sistema sulle sei classi dell’articolo 15, paragrafo 5. Una classe esclusa va motivata per iscritto.
- I report di test avversariali e di red teaming, datati e rieseguiti dopo ogni modifica sostanziale. Un report vecchio su un modello sostituito non prova nulla.
- La sezione cibersicurezza dell’allegato IV e le metriche delle istruzioni per l’uso. Devono coincidere con ciò che è stato testato.
- Il questionario del fornitore (AI-CAIQ), la ripartizione scritta delle responsabilità e la distinta base dell’IA. Senza ripartizione, ogni controllo del fornitore resta una supposizione.
- I playbook di risposta agli incidenti e il registro delle decisioni ai sensi dell’articolo 73. Anche la scelta di non notificare va motivata.
- Il report di rischio SAIF o DASF come documento di lavoro, mai come dichiarazione di conformità. Aiuta a costruire i punti 1 e 2, non li sostituisce.
Questi documenti stanno meglio in una piattaforma di governance che in una cartella: prima l’inventario dei sistemi di IA, poi un insieme di controlli per sistema, poi le evidenze datate, sotto un monitoraggio continuo della conformità. È questo che rende un framework di sicurezza dell’IA verificabile da un terzo, non solo dichiarato.
Domande frequenti
<b>Che cos’è un framework di sicurezza dell’IA?</b>
È un insieme nominato e versionato di minacce, controlli o responsabilità per proteggere un sistema di IA, rispetto al quale un terzo può verificarvi. Ne distinguiamo quattro famiglie: la legge (articolo 15 dell’AI Act, CRA), i cataloghi delle minacce (ATLAS, OWASP, NIST AI 100-2), gli insiemi di controlli (CSA AICM, DASF, ISO/IEC 42001, ETSI EN 304 223) e le guide di responsabilità (SAIF, CoSAI, AWS, Microsoft). Serve un elemento per famiglia.
<b>Quale framework di sicurezza dell’IA richiede l’AI Act?</b>
Nessuno per nome. L’articolo 15 fissa un risultato: accuratezza, robustezza e cibersicurezza adeguate e resistenza alle classi di attacco del paragrafo 5. La conformità si presume con le norme armonizzate (prEN 18282 è in preparazione), con un certificato del Cybersecurity Act (articolo 42, paragrafo 2) o, per i prodotti con elementi digitali, tramite il CRA (articolo 42, paragrafo 3). Va bene qualsiasi insieme di controlli la cui mappatura sull’articolo 15 regga alla verifica.
<b>ISO/IEC 27090 è una norma certificabile?</b>
No. ISO/IEC 27090:2026, pubblicata a ottobre 2026 dal sottocomitato SC 27, è una linea guida di 56 pagine, senza requisiti certificabili. Dice però a un auditor ISO/IEC 27001 o 42001 che cosa significa, in concreto, proteggere un sistema di IA: è la lente con cui verrà letta la vostra evidenza. Si certifica il sistema di gestione; la 27090 orienta i controlli al suo interno.
<b>NIST AI RMF o NIST Cyber AI Profile: quale dei due è il framework di sicurezza?</b>
Oggi nessuno dei due. Il NIST AI RMF 1.0 (gennaio 2023) gestisce il rischio con quattro funzioni e la caratteristica «secure and resilient», ma non contiene controlli. Il Cyber AI Profile (NIST IR 8596) è il candidato naturale, perché aggancia l’IA al CSF 2.0 (Secure, Defend, Thwart), ma a ottobre 2026 esiste solo la bozza preliminare iniziale del 16 dicembre 2025. Intanto AICM e DASF mappano già l’AI RMF.
<b>Serve un framework se il modello lo gestisce il fornitore?</b>
Sì, ma il lavoro cambia. Come deployer, l’articolo 26 vi chiede di usare il sistema secondo le istruzioni, monitorarlo e sospenderlo in caso di rischio; l’articolo 73 vale per gli incidenti gravi. Il framework serve a chiedere al fornitore le prove giuste (AI-CAIQ), a ripartire le responsabilità con una matrice CoSAI, AWS o Microsoft e a coprire i rischi del vostro uso, come gli agenti con l’OWASP Agentic Top 10.
<b>Che differenza c’è tra un framework di sicurezza dell’IA e l’AI security posture management?</b>
Il framework è il riferimento: dice quali minacce considerare, quali controlli attuare e chi ne risponde. L’AI security posture management (AI-SPM) è una categoria di strumenti che individua modelli, agenti e dati e ne verifica la configurazione in continuo. Lo strumento produce evidenze, ma non sostituisce il riferimento: un auditor chiederà sempre su quale insieme di controlli la postura è stata giudicata e con quale mappatura sull’articolo 15.
Conclusione
Un framework di sicurezza dell’IA non si sceglie come un prodotto. La legge decide che cosa provare, il catalogo delle minacce che cosa testare, l’insieme di controlli che cosa mostrare, il modello di responsabilità chi risponde di ciascun controllo. Ottobre 2026 ha reso la scelta più concreta, con ISO/IEC 27090 pubblicata, la prima norma armonizzata in Gazzetta ufficiale e la via del Cyber Resilience Act aperta. Il nostro consiglio: un elemento per famiglia, mappato una volta sulle sei classi dell’articolo 15, paragrafo 5, e un framework di sicurezza dell’IA sotto controllo delle modifiche. Per tenere queste evidenze accanto alla vostra governance dell’IA, AI Sigil collega inventario, controlli e prove datate in un unico registro dei sistemi di IA.