The NIST AI Risk Management Framework: mappare la suite di base alla pratica di sicurezza

1. Introduzione

Praticanti, vendor e policy maker trattano sempre più spesso «il framework di sicurezza IA del NIST» come se nominasse una singola baseline di controlli. Non è così. Il NIST ha pubblicato una famiglia di documenti volontari sull’IA dal 2023, e l’espressione indica almeno tre cose diverse: l’Artificial Intelligence Risk Management Framework (AI RMF) stesso (NIST AI 100-1); il successivo Cybersecurity Framework Profile for Artificial Intelligence (NIST IR 8596); e, più ampiamente, l’unione di quei documenti con la guida su adversarial machine learning (NIST AI 100-2) e i controlli di cybersecurity ordinari (CSF 2.0, SP 800-53). Confonderli produce due modalità di fallimento. I team che volevano un programma di sicurezza implementano solo workshop di governance. Quelli che volevano IA affidabile implementano solo checklist di hardening del modello.

L’AI RMF è uscito il 26 gennaio 2023 come NIST AI 100-1, su mandato della National Artificial Intelligence Initiative Act of 2020. È volontario, rispettoso dei diritti, non settoriale e indipendente dal caso d’uso. Il suo oggetto non è un sistema informativo nel senso di SP 800-37. Il suo oggetto è un sistema di IA sociotecnico, e il criterio di successo è l’affidabilità piuttosto che sola riservatezza, integrità e disponibilità. Il NIST non ha consegnato il framework come PDF isolato. Ha consegnato un Playbook companion, una Roadmap di lavori successivi, un resoconto dettagliato delle caratteristiche di IA affidabile nel documento centrale e un catalogo comunitario di implementazioni e crosswalk tramite il Trustworthy and Responsible AI Resource Center. Quelle cinque risorse sono il programma AI RMF originale. Tutto il resto nello stack IA del NIST — il Generative AI Profile (AI 600-1), la bozza del Cyber AI Profile (IR 8596), la tassonomia adversarial (AI 100-2) e i profili per infrastrutture critiche — è una specializzazione che si collega a quel programma.

Questo paper è una mappa, non una valutazione di modelli né una pretesa di scoperta empirica. Leggiamo il corpus pubblico NIST ad agosto 2026 e gli standard accanto ai quali è pensato. Tre osservazioni strutturano il resto del paper.

La suite è il framework. L’AI RMF 1.0 è la Parte I (come inquadrare il rischio IA e cosa significa «affidabile») più la Parte II (quattro funzioni con categorie e sottocategorie). Playbook, Roadmap, discussione delle caratteristiche e catalogo comunitario sono come il NIST si aspettava che le organizzazioni operazionalizzassero, estendessero e condividessero quel nucleo. Trattare l’AI 100-1 come l’intero programma sottostima ciò che il NIST pubblicò nel primo trimestre del 2023.

La sicurezza è una caratteristica, non la cornice. Il NIST elenca sette caratteristiche di IA affidabile: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; e fair, with harmful bias managed. Secure and resilient è una riga in quell’elenco. Le quattro funzioni — Govern, Map, Measure, Manage — sono come un’organizzazione persegue tutte e sette, incluse le tensioni tra loro.

Gli strumenti di cybersecurity si collegano; non sostituiscono. Il commento del NIST sul Cyber AI Profile è che CSF 2.0, l’AI RMF e il Profile vanno usati insieme. L’AI 100-2 fornisce vocabolario d’attacco per Measure e Manage. SP 800-53 resta il catalogo di controlli per i sistemi che ne hanno bisogno. ISO/IEC 42001 e l’EU AI Act sono regimi adiacenti, non documenti NIST, e vanno crosswalkati piuttosto che fusi.

Contributi. Questo paper apporta quattro contributi:

1. Ricostruiamo la suite di risorse AI RMF originale e mostriamo come Playbook, Roadmap, caratteristiche di affidabilità e catalogo comunitario si rapportano all’AI 100-1.
2. Collociamo la cybersecurity nel modello a sette caratteristiche e precisiamo cosa copre e non copre «secure and resilient».
3. Mappiamo strumenti NIST successivi sulla sicurezza IA sulle quattro funzioni, inclusi CSF 2.0, IR 8596, AI 100-2, AI 600-1 e la nota concettuale sul profilo per infrastrutture critiche.
4. Forniamo una procedura d’uso e un esempio per un sistema di modello linguistico agentico, con modalità di fallimento che derivano dal trattare un solo documento come programma intero.

2. Contesto: il rischio IA non è rischio da sistema informativo

Il classico NIST Risk Management Framework (SP 800-37) autorizza un sistema informativo. Categorizza il sistema, seleziona controlli SP 800-53, li valuta, autorizza l’operazione e monitora. Quel ciclo resta necessario quando un sistema IA gira su infrastruttura federale o altrimenti controllata. Non basta per l’IA, e il NIST lo dice: i rischi IA differiscono dai rischi software tradizionali per natura, non solo per grado.

Tre differenze contano per i team di sicurezza.

L’unità di rischio è sociotecnica. Il comportamento di un sistema IA dipende da dati di training, dati di valutazione, prompt, tool, utenti e processi decisionali a valle. Un modello riservato e disponibile può restare ingiusto, non sicuro o strategicamente non conforme. L’AI RMF tratta quindi gli impatti su individui, gruppi, comunità, organizzazioni e società come in scope, non come esternalità per un ufficio etico separato.

Le caratteristiche di affidabilità confliggono. Un sistema più facile da spiegare può far trapelare di più sui dati di training. Un sistema che rifiuta richieste dual-use può essere meno «utile» su un obiettivo fissato dallo sviluppatore. Il NIST elenca questo problema di trade-off come priorità Roadmap piuttosto che fingere che le caratteristiche siano un pasto gratis. Un programma di sicurezza che ottimizza solo adversarial robustness può spostare il rischio verso equità, privacy o safety senza ridurre il danno totale.

Il framework è volontario e basato sui risultati. L’AI 100-1 non contiene un catalogo numerato di controlli. Contiene funzioni, categorie e sottocategorie che descrivono risultati («i rischi IA sono identificati e documentati») piuttosto che meccanismi («distribuire il filtraggio input X»). Il Playbook suggerisce azioni; non è esplicitamente una checklist da completare in ordine. Le organizzazioni che servono un sistema di gestione auditabile devono guardare a ISO/IEC 42001 o legare l’AI RMF a un confine di autorizzazione RMF esistente — non inventare una certificazione dall’AI 100-1 stesso.

Questi fatti spiegano la confusione terminologica. Gli ingegneri di sicurezza sentono «framework» e vanno verso CSF o SP 800-53. I team di governance IA sentono «framework» e vanno verso AI 100-1. Entrambi gli istinti sono a metà giusti. Il resto di questo paper tratta di tenerli collegati allo stesso sistema piuttosto che sostituirsi a vicenda.

3. La suite di risorse AI RMF originale

Il lancio di gennaio 2023 del NIST era un pacchetto, non un singolo file. La tabella sotto elenca le cinque risorse che, in pratica, le persone intendono con «l’AI RMF». Profili e tassonomie successivi sono complementi, non voci di questa tabella.

3.1 AI RMF 1.0 (NIST AI 100-1)

L’AI 100-1 ha due parti. La Parte I inquadra il rischio IA: chi sono gli attori IA, come il danno IA differisce dal danno software e cosa significa «affidabile». La Parte II è il Core: quattro funzioni, ciascuna scomposta in categorie e sottocategorie.

Govern è trasversale. Copre policy organizzativa, accountability, cultura, governance di terze parti e coinvolgimento delle parti interessate. Map, Measure e Manage formano poi un ciclo su un dato sistema o caso d’uso IA. Map stabilisce il contesto e inventaria gli impatti. Measure seleziona metodi, valuta caratteristiche di affidabilità e traccia il rischio nel tempo. Manage prioritizza trattamenti, incluso rischio residuo, risposta agli incidenti ed esposizione a terze parti. Il NIST presenta questo come concorrente e iterativo, non a cascata.

Due scelte strutturali passano facilmente inosservate.

Primo, i profili sono first-class. Un profilo è un’implementazione delle funzioni per un contesto, tolleranza al rischio e budget di risorse dati. Il Generative AI Profile (AI 600-1) e il profilo per infrastrutture critiche in arrivo sono istanze di profilo, non framework concorrenti.

Secondo, il Core descrive risultati, non tool. «MEASURE 2: AI systems are evaluated for trustworthy characteristics» non nomina un vendor di red team, un benchmark di bias o una metrica di adversarial robustness. Quelle scelte appartengono al Playbook, a un profilo organizzativo o a un complemento come l’AI 100-2.

3.2 Il Playbook

Il Playbook è il companion di implementazione. Per ogni sottocategoria offre azioni suggerite, riferimenti informativi e note sulla documentazione. Il NIST è esplicito su tre vincoli: il Playbook è volontario; le organizzazioni possono usare tante o poche suggerimenti quante applicano; non è una sequenza da completare per intero. La prima versione web completa è stata annunciata il 30 marzo 2023, con il lancio del Resource Center. Il NIST ha indicato che il Playbook sarà aggiornato dopo la revisione dell’AI RMF 1.0.

Per un lettore di sicurezza, il Playbook è dove «secure and resilient» diventa tattico — logging, valutazione, processi di incidente, domande sulla supply chain — senza diventare SP 800-53. Se un team serve un ID controllo auditabile, ha lasciato il Playbook e dovrebbe dirlo.

3.3 La Roadmap

La Roadmap è l’elenco delle lacune del NIST al momento della 1.0, non un calendario con date di consegna. Le priorità pubblicate includono allineamento con standard internazionali e crosswalk; espansione di test, evaluation, verification and validation (TEVV); profili AI RMF; guida sui trade-off tra caratteristiche di affidabilità; metodi per misurare l’efficacia dell’AI RMF stesso; casi studio; fattori umani; explainability collegata alla gestione del rischio; metodi per fissare tolleranze al rischio ragionevoli; e materiale educativo.

Diversi di questi sono diventati documenti a sé (profili, tassonomie adiacenti al TEVV). Altri restano aperti, soprattutto guida sui trade-off e misura dell’efficacia. Un team che tratta la 1.0 come dottrina finita sarà sorpreso dal processo di revisione.

3.4 Trustworthy AI characteristics

Le caratteristiche non sono un quinto PDF. Sono la Parte I dell’AI 100-1 e sono l’oggetto di MEASURE 2. Il punto importante a livello di suite è che il NIST ha definito la «buona IA» prima di definire le quattro funzioni. Le funzioni esistono per perseguire quelle caratteristiche, anche quando tirano in direzioni opposte.

3.5 Il catalogo comunitario (AIRC)

Il 30 marzo 2023 il NIST ha lanciato il Trustworthy and Responsible AI Resource Center per ospitare contenuti del Playbook, crosswalk, prospettive e casi d’uso contribuiti. È la risorsa spesso descritta informalmente come «database di gestione del rischio IA»: un catalogo di implementazioni comunitarie, non un database di vulnerabilità né una libreria di controlli. La sua funzione è sociale — profili e mapping condivisi — piuttosto che valutazione tecnica. Non va confuso con database di incidenti o con MITRE ATLAS.

4. Caratteristiche di affidabilità e la riga sicurezza

Il modello di affidabilità del NIST è la parte dell’AI RMF più spesso saltata dai programmi di sicurezza e più spesso trattata come programma intero dai programmi di IA responsabile. Entrambi i tagli perdono la struttura.

4.1 Sette caratteristiche

L’AI 100-1 afferma che i sistemi di IA affidabili sono, in combinazione:

1. Valid and reliable — performano come previsto in condizioni attese e ragionevolmente inattese, con limiti documentati.
2. Safe — non mettono in pericolo vita, salute, proprietà o ambiente umano in condizioni d’uso definite.
3. Secure and resilient — resistono a eventi avversi inattesi, inclusi accesso, uso o disruption non autorizzati, e si riprendono.
4. Accountable and transparent — gli attori sono identificabili e l’informazione sul sistema è disponibile a chi ne ha bisogno.
5. Explainable and interpretable — output IA e comportamento del sistema sono comprensibili a un livello adeguato al pubblico e alla decisione.
6. Privacy-enhanced — incorporano valori di privacy come anonimato, riservatezza e controllo.
7. Fair, with harmful bias managed — gestiscono bias dannoso e rischi di discriminazione correlati.

La validity è descritta come prerequisito per le altre: un sistema invalido non può essere equo o safe in senso robusto. Oltre a ciò, il NIST non classifica le restanti sei. La Roadmap segnala invece i trade-off come problema aperto di ricerca e guida.

4.2 Cosa copre «secure and resilient»

In linguaggio RMF, secure and resilient è la caratteristica che sovrappone la triade CIA classica e gli esiti CSF. Include riservatezza di pesi del modello, dati di training e prompt; integrità di dati, modelli e output dei tool; disponibilità di inferenza e della pipeline circostante; e resilienza sotto attacco, distribution shift e guasto operativo.

Da sola non include:

• se l’obiettivo dichiarato del modello corrisponde ai valori del deployer (accountability);
• se rifiuti e policy dual-use sono adeguati (safety, spesso anche equità);
• se le spiegazioni sono faithful (explainability);
• se dati di training o log creano danno alla privacy (privacy);
• se le valutazioni sono statisticamente valide (validity).

L’adversarial machine learning sta al confine. Evasion, poisoning, attacchi privacy e misuse generativo sono eventi di sicurezza, ma anche di validity, privacy e safety. Per questo il NIST ha scritto una tassonomia dedicata piuttosto che ripiegare l’AML interamente in Identify-Protect-Detect-Respond-Recover del CSF.

4.3 Come le quattro funzioni si applicano alla riga sicurezza

Una lettura solo sicurezza delle quattro funzioni ha contenuto ed è più stretta di un programma AI RMF completo:

Govern. Chi possiede il rischio modello versus application security versus safety policy? Modelli di terze parti, corpora RAG e tool sono nel processo di vendor risk? C’è una acceptable-use policy che non è solo una policy di sicurezza dell’informazione?

Map. Cos’è il sistema IA — modello, prompt, tool, retrieval, evaluator, umani nel loop? Chi è danneggiato se fallisce chiuso, fallisce aperto o è guidato? Quali ambienti sono training, valutazione e produzione, e il modello può inferire la differenza?

Measure. Quali test esistono per jailbreak, prompt injection, data exfiltration, poisoning, membership inference e tool abuse — e quali test per le caratteristiche non di sicurezza che quegli attacchi possono indurre? Le metriche sono tracciate nel tempo o solo al lancio?

Manage. Qual è il rischio residuo dopo le mitigazioni? Qual è il percorso di incidente quando un’azione del modello causa danno che non è un incidente di sicurezza classico? Come sono trattati gli aggiornamenti di modelli di terze parti?

Questo non è ancora una baseline di controlli. È un modo per notare che «abbiamo fatto red team una volta» è un’attività Measure, non un sistema Govern o Manage.

5. Complementi: cybersecurity e profili specializzati

Se la suite è il tronco, i documenti in questa sezione sono i rami che più spesso si etichettano erroneamente come «il framework di sicurezza IA del NIST». Sono reali, utili e più stretti.

5.1 CSF 2.0

Il Cybersecurity Framework 2.0 organizza gli esiti di cybersecurity in sei funzioni: Govern, Identify, Protect, Detect, Respond, Recover. È tecnologicamente neutro e già ampiamente distribuito. Non sa cos’è un peso del modello, una prompt injection o una chain-of-thought leak. Usare CSF da solo su un sistema LLM tipicamente cattura l’account cloud e l’applicazione circostanti e perde le modalità di fallimento specifiche del modello.

La sovrapposizione lessicale di «Govern» con l’AI RMF è coincidenza nel nome e allineamento nello spirito. Govern CSF è governance di cybersecurity. Govern AI RMF è governance di affidabilità IA, che include sicurezza e molto altro.

5.2 Cyber AI Profile (NIST IR 8596)

Il Cybersecurity Framework Profile for Artificial Intelligence, pubblicato come initial preliminary draft a dicembre 2025, è il documento NIST più vicino a un «framework di sicurezza IA» in senso colloquiale. Applica esiti CSF 2.0 all’IA ed è organizzato intorno a tre aree di focus:

1. Secure — cybersecurity dei componenti del sistema IA (modelli, dati, pipeline, agenti, infrastruttura).
2. Defend — usare l’IA per potenziare operazioni difensive, incluse le nuove modalità di fallimento che introduce.
3. Thwart — resilienza contro attacchi abilitati dall’IA (phishing automatizzato, malware, intrusione).

L’intento dichiarato del NIST è che CSF 2.0, l’AI RMF e questo Profile siano usati insieme, non che il Profile sostituisca l’AI 100-1. La bozza assegna livelli di priorità alle considerazioni come guida di pianificazione; le organizzazioni devono adattare quelle priorità alla propria tolleranza al rischio. Al momento della scrittura il documento resta una bozza verso un initial public draft dopo il periodo di commenti di gennaio 2026.

5.3 Adversarial machine learning taxonomy (NIST AI 100-2)

NIST AI 100-2 è un report di terminologia e tassonomia, aggiornato nel 2025. Classifica gli attacchi per paradigma di apprendimento, fase del ciclo di vita, obiettivi dell’attaccante, capacità e conoscenza. Per sistemi predittivi le classi principali sono evasion, poisoning e attacchi privacy. Per sistemi generativi aggiunge misuse. Discute anche mitigazioni e i loro limiti.

È il documento da citare quando Measure serve un linguaggio condiviso per «cosa è successo al modello». Non è un framework di governance né un profilo CSF. ATLAS è un threat landscape pratico correlato; l’AI 100-2 è il vocabolario NIST pensato per informare futuri standard e guide di pratica.

5.4 Generative AI Profile (NIST AI 600-1)

NIST AI 600-1 è un profilo AI RMF, non un profilo CSF. Applica Govern–Map–Measure–Manage a rischi unici o amplificati nei sistemi generativi: confabulation, privacy dei dati, sicurezza dell’informazione, contenuti dannosi, omogeneizzazione, configurazione umano-IA e altri. Un team che distribuisce LLM o agenti e implementa la 1.0 senza la 600-1 usa la cornice generale senza l’elenco di rischi GenAI che il NIST ha già scritto.

5.5 SP 800-53 e overlay di controlli IA

SP 800-53 resta il catalogo di controlli per sistemi federali USA e per molti programmi privati che già lo usano. Il NIST sta sviluppando overlay di controlli orientati all’IA: selezioni e interpretazioni di controlli esistenti per tipi di sistema IA, piuttosto che un catalogo sostitutivo. Fino a quando gli overlay non sono finali, il percorso di implementazione onesto è: RMF autorizza la piattaforma; AI RMF governa il modello; CSF / Cyber AI Profile prioritizzano esiti cyber; SP 800-53 (o catalogo privato) istanzia controlli tecnici.

5.6 Profilo infrastrutture critiche

Ad aprile 2026 il NIST ha pubblicato una nota concettuale per un profilo AI RMF su IA affidabile nelle infrastrutture critiche. Il pubblico sono operatori CI in contesti IT, OT e ICS che devono enunciare requisiti di affidabilità a vendor e team interni. È un profilo settoriale dell’AI 100-1, non un sostituto della regolamentazione cyber settoriale.

5.7 Revisione dell’AI RMF 1.0

Il NIST indica che l’AI RMF 1.0 è in revisione nell’ambito del White House AI Action Plan e che il Playbook sarà aggiornato dopo quella revisione. Qualsiasi paper di mapping, incluso questo, va letto come mappa della suite dell’era 1.0 più i complementi pubblicati fino a metà 2026 — non come congelamento del testo 2.0.

6. Mappa d’uso

La domanda pratica non è quale documento è «il» framework. È quale documento risponde a quale domanda.

1. Quali risultati dobbiamo? → AI RMF 1.0 + profilo (600-1 o settoriale)
2. Come potremmo perseguirli? → Playbook + esempi AIRC
3. Quali sono gli esiti cyber? → CSF 2.0 + Cyber AI Profile
4. Cosa può succedere al modello? → AI 100-2 (+ ATLAS)
5. Quali controlli lo istanziano? → SP 800-53 / overlay / ISO 27001

Saltare una riga è comune; affermare che la riga saltata era coperta è l’errore usuale.

6.1 Procedura

1. Nomina sistema e attori (Map). Annota modello/i, datastore, tool, evaluator, utenti e parti interessate. Se questo inventario non esiste, né CSF né il Playbook salveranno il programma.

1. Seleziona un profilo. I sistemi generali usano la 1.0 così com’è. I sistemi generativi e agentici aggiungono AI 600-1. Gli operatori CI devono seguire il profilo infrastrutture critiche. Un profilo è una decisione di scope, non burocrazia fine a se stessa.

1. Metti in piedi Govern prima del teatro di Measure. Assegna owner per rischio modello, application security, safety policy e IA vendor. Decidi esplicitamente la tolleranza al rischio — l’item 9 della Roadmap esiste perché questo passo di solito è simulato.

1. Porta la cybersecurity tramite CSF, non per metafora. Mappa considerazioni Secure / Defend / Thwart da IR 8596 sulle categorie CSF esistenti. Non riscrivere l’ISMS intorno alle sottocategorie AI 100-1.

1. Dai a Measure un vocabolario d’attacco. Usa classi AI 100-2 (evasion, poisoning, privacy, misuse) come tassonomia minima per test centrati sul modello. Aggiungi valutazioni non di sicurezza per validity, equità, privacy e safety o smetti di rivendicare quelle caratteristiche.

1. Istanzia controlli in un catalogo reale. SP 800-53, mapping controlli di un cloud provider o ISO/IEC 27001 possono contenere gli oggetti tecnici. Registra rischio residuo in Manage, inclusi danni che non appariranno mai in un SIEM.

1. Documenta lo spazio negativo. Se l’organizzazione implementa solo Secure-and-resilient + CSF, di’ «gestiamo un programma di cybersecurity IA informato dall’AI RMF», non «implementiamo l’AI RMF».

6.2 Esempio: un sistema chat agentico

Considera un assistente ospitato che recupera documenti privati, chiama tool e agisce su più turni — la forma di molti agenti LLM in produzione.

Map. Il sistema non è «il modello». È modello, system prompt, corpora recuperati, API tool, memoria di sessione, evaluator e operatori umani. Le parti interessate includono utenti finali, terzi i cui dati compaiono nel retrieval e chi è dall’altra parte di una tool call. L’elenco rischi GenAI dell’AI 600-1 è in scope; una lettura 1.0 solo ML predittivo non lo è.

Govern. Owner separati per: application security (authn/z, isolamento tenant); change control modello e prompt; safety policy (refusals, dual-use); modelli vendor. Third-party Govern (GOVERN 6 / MANAGE 3) si applica alle API di foundation model come al SaaS.

Measure. Classi misuse e privacy dell’AI 100-2 coprono jailbreak, prompt injection via documenti recuperati e data exfiltration via tool. Non coprono confabulation che danneggia un utente senza attaccante, o fallimenti sistematici di refusal in alcune lingue. Quelle sono misure di validity, safety e equità. Un report red team che conta solo il tasso di successo degli attacchi è Measure incompleto rispetto alla 600-1.

Manage. I tipi di incidente includono breach classici e azioni tool completate e dannose, leakage di segreti nei log e alignment-faking o ragionamento ingannevole scoperto se il modello è valutato per quello. Il recovery può significare rollback di prompt o modello, non solo rotazione credenziali.

Overlay CSF / IR 8596. Secure copre lo stack di serving e la pipeline di training o fine-tuning. Defend copre qualsiasi uso di modelli nei flussi SOC — e il rischio di prompt injection che crea. Thwart copre attaccanti che usano altri modelli contro questo sistema (credential stuffing con esche generate, scoperta automatizzata di vulnerabilità).

Niente di questo richiede di fingere che IR 8596 sia AI 100-1, o che AI 100-1 sia SP 800-53.

6.3 Modalità di fallimento

Osserviamo quattro errori di categoria ricorrenti nelle affermazioni pubbliche (non un campione statistico; una tipologia):

• Compliance PDF. Trattare un foglio Playbook compilato come implementazione di MEASURE 2.
• Sinécdoche sicurezza. Equiparare implementazione AI RMF a valutazione di adversarial robustness.
• Sinécdoche etica. Equiparare implementazione AI RMF a dashboard di equità senza percorso di incidente.
• Teatro di certificazione. Pubblicizzare «certificato NIST AI RMF» nonostante il NIST non offra tale certificazione per la 1.0.

L’ultimo è il più fuorviante. ISO/IEC 42001 è il sistema di gestione IA certificabile. L’AI RMF è un framework di risultati volontario che può essere allineato con quel sistema.

7. Lavori correlati

Lo stack NIST. Questo paper è una lettura di quello stack, non un concorrente. Le fonti primarie sono AI 100-1, Playbook e Roadmap, AIRC, AI 600-1, AI 100-2, CSF 2.0 e IR 8596. SP 800-37 e SP 800-53 restano la spina dorsale di autorizzazione e controlli per sistemi informativi federali.

Sistemi di gestione internazionali e diritto. ISO/IEC 42001 specifica un sistema di gestione IA auditabile. ISO/IEC 22989 fornisce vocabolario; ISO/IEC 42005 tratta impact assessment. La Roadmap AI RMF elencava già crosswalk a questa famiglia come priorità top. L’EU AI Act è regolamentazione vincolante a livelli di rischio per sistemi nel suo scope. Non è un profilo NIST. I crosswalk sono appropriati; l’identità no. I OECD AI Principles stanno a quota più alta e hanno informato gran parte del vocabolario trustworthy-AI 2019–2023 che il NIST ha distillato.

Linee guida per sviluppo sicuro. Le linee guida CISA e NCSC per lo sviluppo sicuro di sistemi IA sono più vicine all’area Secure di IR 8596 che all’AI RMF nel complesso. Sono input utili Measure/Manage, non un modello Govern sostitutivo per equità o accountability.

Threat landscape. MITRE ATLAS cataloga tattiche avversarie contro sistemi IA. Biggio e Roli passano in rassegna il primo decennio di adversarial ML. Weidinger et al. tassonomizzano rischi dei modelli linguistici oltre l’ambito adversarial. Amodei et al. hanno inquadrato rischio da incidente che non è primariamente un problema di attaccante. L’AI RMF è deliberatamente più ampio di ciascuna di queste liste; l’AI 100-2 è il documento NIST che assorbe più direttamente il sottoinsieme adversarial.

Alignment come problema di affidabilità. Il lavoro su assistenti helpful, honest, harmless e su constitutional training riguarda safety, accountability e validity più che cybersecurity classica. Appartiene comunque sotto Map e Measure per sistemi agentici: un modello che si conforma strategicamente sotto oversight è una modalità di fallimento Manage rilevante anche quando nessun controllo SP 800-53 è fallito. L’AI RMF non usa «alignment» come primitiva; le organizzazioni a cui importa dovrebbero trattarlo come rischio nominato in Map, non come sinonimo di secure-and-resilient.

8. Discussione

8.1 Cosa non fa questo mapping

Non abbiamo misurato se le organizzazioni che rivendicano allineamento AI RMF differiscono nei tassi di incidente da quelle che non lo fanno. L’item 5 della Roadmap (efficacia del framework) resta un workstream NIST aperto. Non abbiamo neanche prodotto un nuovo overlay di controlli o un crosswalk completo verso ISO/IEC 42001 o l’EU AI Act; sono progetti da dimensione documento, alcuni già in AIRC.

Il paper è quindi un contributo cartografico. La sua modalità di fallimento è quella usuale delle mappe: sembrare più autorevole del terreno, soprattutto mentre la 1.0 è in revisione.

8.2 Framework volontari e linguaggio di procurement

Poiché l’AI 100-1 è volontario e basato sui risultati, è un cattivo oggetto di clausole di procurement binarie («il fornitore deve essere conforme AI RMF»). Una clausola più precisa nomina il profilo (es. AI 600-1), le caratteristiche in scope, le evidenze attese per Measure e il catalogo di controlli usato per istanziare oggetti tecnici Protect/Detect. Dove serve un sistema di gestione certificabile, ISO/IEC 42001 è lo strumento progettato. Dove serve un insieme di controlli di sicurezza certificabile, SP 800-53 o un equivalente resta lo strumento progettato.

8.3 Il gap di misura

Govern e Map si possono fare con workshop. Measure no. L’item TEVV della Roadmap esiste perché la valutazione sociotecnica dei sistemi IA è ancora metodologicamente sottile rispetto alle affermazioni che i buyer vogliono sentire. I team di sicurezza non dovrebbero colmare quel gap sovraccaricando i tassi pass/fail del red team per fare da validity, equità e safety. Quella sostituzione è come «framework di sicurezza IA del NIST» diventa una frase di marketing.

8.4 Agenti, tool e il testo del 2023

L’AI 100-1 precede la diffusione di agenti che usano tool. L’AI 600-1 e IR 8596 sono i documenti che iniziano a recuperare. Un agente che può inviare email, cambiare infrastruttura o scrivere codice espande l’inventario Map e la tassonomia di incidenti Manage. Non richiede un nuovo nome marketing per l’AI RMF; richiede un profilo che nomini tool, memoria e authorization come componenti di sistema first-class.

8.5 Rischio di revisione

I lettori che implementano da questo paper dovrebbero seguire la revisione 1.0. I nomi delle funzioni possono persistere mentre sottocategorie, aspettative di profilo e azioni Playbook cambiano. L’affermazione strutturale che ci importa — suite versus complementi; caratteristiche versus controlli — probabilmente sopravviverà; citazioni a livello di sottocategorie 1.0 forse no.

9. Conclusione

Non esiste un singolo documento NIST intitolato AI Security Framework. C’è un programma del 2023 — la suite AI RMF di AI 100-1, Playbook, Roadmap, caratteristiche di affidabilità e catalogo comunitario — e un insieme di strumenti successivi che approfondiscono cybersecurity, IA generativa e pratica settoriale.

La sicurezza è una delle sette caratteristiche di IA affidabile. Le quattro funzioni operazionalizzano tutte e sette. CSF 2.0 e la bozza del Cyber AI Profile sono lo strato di esiti cybersecurity. L’AI 100-2 è il vocabolario d’attacco. SP 800-53 (e overlay in arrivo) sono lo strato di controlli. ISO/IEC 42001 e l’EU AI Act sono regimi adiacenti.

Usati insieme, questi documenti sono coerenti. Usati come sinonimi, producono programmi che sono o sicurezza con vocabolario etico, o etica senza percorso di incidente. La correzione più economica è linguistica: dire quale documento risponde a quale domanda e smettere di rivendicare il resto.

Ringraziamenti

Questo paper è una lettura strutturata di documenti NIST pubblici e standard correlati. Non è affiliato al NIST, non costituisce consulenza legale o di conformità e non afferma che un prodotto implementi l’AI RMF.

@online{violet2026nistairmf,
  author = {Haigh, John},
  title = {The NIST AI Risk Management Framework: Mapping the Core Suite to Security Practice},
  date = {2026-09-12},
  year = {2026},
  url = {https://www.violetai.ca/it/research/nist-ai-rmf/paper},
}