Rischi dell'intelligenza artificiale: il NIST AI RMF in pratica

Per rispondere alla domanda «Seguite il NIST AI RMF?», servono prove di come vengono gestiti i rischi dell'intelligenza artificiale in un sistema ben identificato: chi ne risponde, quali test sono stati eseguiti, quali azioni gli sono consentite e cosa succede quando qualcosa va storto. Il framework comprende 4 funzioni e la sua adozione è volontaria; nei primi 30 giorni l'obiettivo è avviare un processo di gestione del rischio che funzioni e descriverne con precisione le lacune. Il framework del NIST fornisce la struttura.

L'AI Risk Management Framework (AI RMF) del National Institute of Standards and Technology (NIST) aiuta le organizzazioni ad affrontare i rischi per le persone, le organizzazioni stesse e la società quando progettano, sviluppano, mettono in produzione o utilizzano l'IA. Il suo ambito va oltre il modello: contano anche le persone, i dati, le autorizzazioni e il contesto in cui opera il sistema. L'AI RMF 1.0 descrive questa prospettiva più ampia.

Per un'azienda con un organico da 20 a 200 persone che porta in produzione modelli linguistici di grandi dimensioni, o LLM, conviene partire da un'implementazione dal perimetro definito. Si sceglie una funzionalità con conseguenze rilevanti, si collegano i suoi rischi a decisioni e registrazioni documentate, poi si amplia il lavoro. Acquistare un modello da un'altra azienda non spiega al cliente come viene controllata la funzionalità costruita attorno a quel modello.

Verifica delle fonti: 26 ottobre 2026. Il framework, il Playbook e il Generative AI Profile sono stati verificati sulle pagine e nelle pubblicazioni correnti del NIST. La pagina del framework indica che l'AI RMF 1.0 è in revisione e continua a rimandare a quella versione. L'avviso non equivale alla pubblicazione di una nuova versione, né ne annuncia la data di rilascio.

Rischi dell'intelligenza artificiale: come funziona il NIST AI RMF

Il framework chiede di tenere collegate responsabilità, contesto, prove e azioni lungo l'intera vita di un sistema. Si può pensare al piano antincendio di un edificio: sapere dove sono le uscite è utile, ma serve anche chi risponda della loro accessibilità, un modo per verificarla e una procedura da attivare se qualcosa va storto.

NIST AI 100-1: il documento di riferimento

NIST AI 100-1 è l'identificativo della pubblicazione AI RMF 1.0, uscita il 26 gennaio 2023. La prima parte illustra i concetti di rischio e affidabilità; la seconda contiene il Core e i Profiles. Il Core organizza la gestione del rischio nelle funzioni Govern, Map, Measure e Manage, ciascuna articolata in categorie e sottocategorie. Queste descrivono risultati da raggiungere e azioni da svolgere, anziché una checklist universale di audit con esito positivo o negativo. Framework del NIST e informazioni sul rilascio; AI RMF 1.0, parti 1 e 2.

Le caratteristiche di affidabilità riguardano la validità e l'affidabilità del sistema; la sicurezza rispetto ai danni; la protezione dalle minacce e la resilienza; l'attribuzione delle responsabilità e la trasparenza; la spiegabilità e l'interpretabilità; la tutela rafforzata della privacy; l'equità, con una gestione dei bias dannosi. Una risposta scorrevole, da sola, non dimostra nessuna di queste qualità. Il NIST ne discute le caratteristiche e i compromessi nell'AI RMF 1.0, sezione 3.

Un assistente per il supporto clienti, per esempio, potrebbe rispondere correttamente alle domande sul prodotto e allo stesso tempo esporre i dati di un altro cliente. Una valutazione utile deve esaminare sia la risposta sia i limiti di accesso. Misurare soltanto la qualità delle risposte lascerebbe inosservato il problema dalle conseguenze più gravi.

NIST AI RMF Playbook: scegliere le azioni adatte al contesto

Il NIST AI RMF Playbook aggiunge azioni suggerite, riferimenti e indicazioni per raggiungere i risultati descritti nel Core. Il NIST consente espressamente alle organizzazioni di scegliere i suggerimenti adatti alle proprie esigenze; non si aspetta che tutte mettano in pratica ogni indicazione. Il Playbook non è una checklist da seguire in ordine. Playbook del NIST; FAQ sul Playbook del NIST.

Va usato quando occorre dare una risposta concreta a un rischio. Se l'assistente di supporto può esporre dati riservati, si cercano azioni relative a dati, accessi, misurazione e gestione degli incidenti. Si documenta cosa è stato scelto, perché è adatto e come se ne verifica il funzionamento. Copiare ogni suggerimento in un foglio di calcolo produce lavoro senza aiutare a decidere se la funzionalità possa essere rilasciata.

Le quattro funzioni e la documentazione per un piccolo team

Le funzioni vanno mantenute collegate. Govern si applica trasversalmente a Map, Measure e Manage, e il lavoro procede per iterazioni lungo il ciclo di vita dell'IA. Un test può far emergere un rischio che richiede di riesaminare il contesto; un incidente può rendere necessario modificare una policy. Il NIST non prescrive una sequenza a senso unico. Core del NIST AI RMF.

La corrispondenza tra funzioni e documenti riportata qui sotto è una nostra proposta di implementazione per piccoli team. Il NIST definisce i risultati da raggiungere; questi formati e queste attribuzioni di responsabilità sono scelte pratiche per documentarli. Uno stesso documento può supportare più funzioni.

Gli identificativi e le descrizioni dei risultati riportati sopra provengono dalle tabelle delle funzioni del Core del NIST. Sono riferimenti selezionati: la tabella non pretende di coprire tutte le sottocategorie.

Govern: dare a qualcuno l'autorità di fermare il sistema

Govern definisce le policy, le responsabilità e la cultura necessarie a gestire il rischio. Il NIST include in questa funzione ruoli documentati, responsabilità della dirigenza, formazione del personale e supervisione umana. Core del NIST, Govern.

In un'ipotetica azienda software di 40 persone, il fondatore potrebbe essere responsabile della policy sul rischio, il responsabile del supporto potrebbe rispondere dell'assistente e un ingegnere dei controlli di accesso. Non bastano i loro nomi su un documento: servono anche poteri effettivi. Va precisato chi può sospendere la funzionalità e chi può accettare il rischio che rimane dopo l'applicazione delle misure di protezione, ossia il rischio residuo.

Una regola di supervisione umana concretamente applicabile potrebbe essere: «L'assistente può preparare bozze di risposta usando materiale di supporto approvato. Prima dell'invio, un addetto al supporto deve verificare la fonte e il destinatario. L'assistente non è autorizzato a emettere rimborsi o modificare gli accessi agli account. Il responsabile del supporto può disattivarlo; per riavviarlo occorre l'approvazione del referente tecnico e del responsabile del supporto».

Questa regola è un esempio di scelta progettuale. Un flusso di lavoro diverso può giustificare autorizzazioni diverse. Ciò che conta è che gli accessi effettivi e le modalità di revisione in produzione corrispondano alla regola.

Map: descrivere la funzionalità, oltre al modello

Map definisce il contesto necessario a comprendere rischi e impatti, inclusi i componenti del sistema e le terze parti. Aiuta anche a decidere, prima di tutto, se una soluzione di IA sia appropriata. Core del NIST, Map.

L'assistente di supporto deve avere una propria voce nell'inventario. Vanno registrati finalità, responsabile, destinatari, categorie di dati, fonti da cui recupera informazioni, sistemi collegati, identificativo del modello o del servizio, azioni consentite e stato di approvazione. Vanno incluse le persone che possono subire le conseguenze dei suoi errori, anche i clienti che non interagiscono mai direttamente con l'assistente.

Il rischio va poi descritto come causa, evento e conseguenza: «Un filtro errato sull'account recupera il ticket di un altro cliente; l'assistente lo inserisce in una bozza; un revisore invia informazioni riservate al cliente sbagliato». La sola etichetta «rischio per la privacy» non dice a un ingegnere cosa correggere.

Accanto allo scenario vanno riportate le misure di protezione proposte, con un responsabile, uno stato e un collegamento alle prove. Una nuova finalità o una nuova autorizzazione richiedono una nuova valutazione anche se il modello sottostante resta lo stesso.

Measure: verificare il rischio individuato

Measure impiega metodi quantitativi, qualitativi o misti per valutare rischi e affidabilità. Il NIST include test in condizioni simili a quelle di produzione, documentazione dei limiti e valutazioni di aspetti quali sicurezza, privacy e bias dannosi. Core del NIST, Measure.

Per l'assistente di supporto, i casi di test devono comprendere una domanda ordinaria, l'assenza di materiale di riferimento, policy in conflitto, dati di un altro cliente e un'istruzione malevola inserita nel testo recuperato. Con prompt injection si intende un attacco in cui vengono fornite istruzioni per deviare il comportamento del sistema; il Generative AI Profile del NIST, sezione 2.9 tratta sia gli attacchi diretti sia quelli veicolati dal materiale recuperato dal sistema.

Ogni registrazione di valutazione deve identificare la configurazione testata, gli input del caso, il comportamento atteso, l'output o l'azione effettivi, il revisore e l'esito. Un caso fallito va collegato al rischio che rivela. Le prove sensibili vanno conservate con controlli di accesso adeguati, evitando di copiare i dati dei clienti in un rapporto di uso generale.

I criteri di accettazione vanno scritti prima di esaminare i risultati. In questo esempio, la divulgazione di dati di un cliente a un altro blocca il rilascio anche se le altre risposte sembrano buone. È una regola di rilascio proposta qui, non una soglia fissata dal NIST. Un insieme ristretto di test può individuare un errore; superarli non dimostra che non possano verificarsene altri.

Manage: trasformare i risultati in decisioni

Manage stabilisce le priorità tra i rischi e assegna le risorse per affrontarli. Il NIST include decisioni sull'opportunità di proseguire lo sviluppo o la messa in produzione, opzioni come la mitigazione o l'accettazione del rischio, meccanismi di disattivazione dei sistemi, monitoraggio continuo e risposta agli incidenti. Core del NIST, Manage.

Se fallisce il test sulla separazione degli accessi tra account, si disabilita il percorso di recupero interessato, si corregge il controllo di autorizzazione e si ripete il test prima di ripristinare l'accesso. Se l'errore ha conseguenze meno gravi, si documenta perché sia accettabile un rilascio limitato con monitoraggio e chi abbia preso la decisione. Scrivere «accettato» senza motivazione o senza un responsabile dell'approvazione fornisce una prova debole.

Il registro degli incidenti deve riportare il momento del rilevamento, il sistema e la configurazione interessati, l'impatto noto, le misure di contenimento, la posizione delle prove, le comunicazioni, l'azione correttiva e l'approvazione del riavvio. Vanno registrati anche i quasi incidenti. Se non è successo nulla, un registro vuoto è una rappresentazione onesta; lo si può affiancare a un'esercitazione, chiaramente indicata come tale, che dimostri la capacità di eseguire la risposta.

NIST AI 600-1: cosa aggiunge il Generative AI Profile

Il NIST AI 600-1, intitolato Generative Artificial Intelligence Profile, applica il framework ai rischi specifici dell'IA generativa o da essa amplificati. Pubblicato il 26 luglio 2024, affianca l'AI RMF 1.0: non è un framework sostitutivo né una certificazione separata. Pagina della pubblicazione del NIST.

Il Profile individua 12 aree di rischio e propone azioni collegate al framework. Il suo sviluppo si è concentrato su governance, provenienza dei contenuti, test prima della messa in produzione e comunicazione degli incidenti. La provenienza dei contenuti riguarda la loro origine e la loro storia. Questi aspetti aiutano a collegare gli output generati a pratiche operative con responsabilità definite. NIST AI 600-1, introduzione, sezione 2 e appendice A.

Per l'assistente di supporto, si può iniziare traducendo i rischi pertinenti in casi concreti di malfunzionamento:

• Confabulazione: una risposta sicura ma falsa inventa il diritto a un rimborso. Si conserva la risposta attesa in base alla policy e si verifica se il materiale citato dal sistema la supporta.
• Privacy dei dati e sicurezza delle informazioni: i dati dei clienti vengono divulgati oppure un contenuto malevolo recuperato devia il comportamento dell'assistente. Vanno testati sia i limiti di accesso ai dati sia il comportamento in presenza di input ostili.
• Configurazione del rapporto tra persone e IA: un revisore si fida eccessivamente di una bozza ben scritta. Deve avere a disposizione la fonte originale, i criteri per respingerla e l'autorità per fermare l'azione.
• Bias dannosi o omogeneizzazione: la qualità del servizio varia tra gruppi di utenti o lingue rilevanti. Si esaminano i contesti effettivamente serviti e si documentano i limiti delle prove raccolte.
• Catena del valore e integrazione dei componenti: un modello, una fonte di dati o un'integrazione cambia senza che se ne comprendano gli effetti. Si conservano registrazioni delle dipendenze e delle modifiche, poi si rivalutano i rischi interessati.

Sono esempi di implementazione ricavati dalle descrizioni dei rischi del Profile, non una checklist ufficiale abbreviata. Le altre aree indicate sono informazioni o capacità CBRN (chimiche, biologiche, radiologiche o nucleari); contenuti pericolosi, violenti o che incitano all'odio; impatti ambientali; integrità delle informazioni; proprietà intellettuale; contenuti osceni, degradanti e/o offensivi. Occorre valutarne la rilevanza per il proprio sistema e documentare le motivazioni. Le definizioni complete si trovano nel NIST AI 600-1, sezione 2.

Un modo utile di applicare il Profile consiste nel registrare il rischio pertinente, l'azione scelta, il responsabile e le prove, spiegando poi le esclusioni significative. Per un agente in grado di agire tramite software collegato, va valutato il percorso che porta all'azione, oltre al testo generato. Una bozza accurata non dimostra che una modifica all'account fosse autorizzata.

I primi 30 giorni: una proposta di piano operativo

L'obiettivo è un processo dimostrabile entro un perimetro definito. Questa tabella di marcia è una nostra raccomandazione, non una scadenza del NIST, un livello di maturità o una garanzia di completamento. La governance deve restare attiva per tutto il percorso; il calendario serve a organizzare il primo mese, non rappresenta una sequenza imposta dal framework.

1. 1

   Giorni 1-5: definire perimetro e responsabilità

   Individuare un dirigente responsabile e un referente del sistema. Censire gli usi attuali dell'IA, comprese le funzionalità integrate nei software già acquistati. Per la prima valutazione approfondita, scegliere una funzionalità in produzione con rischi rilevanti per i clienti, per i dati o legati alle azioni che può compiere.

   Descriverne finalità e limiti, individuare le persone interessate e raccogliere le procedure esistenti per rilasci, accessi e incidenti. Documentare le lacune nella ricognizione, anziché dichiarare completo l'inventario senza prove.

   Da conservare: l'inventario iniziale, le responsabilità nominative e una regola di supervisione umana verificata rispetto alle autorizzazioni effettive della funzionalità.

2. 2

   Giorni 6-10: mappare i problemi e scegliere le risposte

   Esaminare il funzionamento della funzionalità scelta insieme a chi l'ha sviluppata e a chi gestisce il flusso operativo. Coinvolgere una persona capace di mettere in discussione le ipotesi sull'impatto per i clienti. Ricostruire input, materiale recuperato, output e azioni sui sistemi collegati.

   Inserire gli scenari di danno nel registro dei rischi. Usare il Generative AI Profile per mettere alla prova l'elenco. Stabilire le priorità in base all'impatto potenziale e alla probabilità, tenendo conto dell'incertezza, e assegnare un responsabile del trattamento del rischio. Decidere quali problemi bloccano il rilascio e quali richiedono di restringere il perimetro operativo.

   Da conservare: la descrizione del sistema, il registro dei rischi, le azioni selezionate, le prove ancora mancanti e i criteri di accettazione proposti.

3. 3

   Giorni 11-20: valutare la configurazione destinata alla produzione

   Eseguire casi rappresentativi, casi di errore e test avversariali sulla configurazione che si intende usare. Registrare gli identificativi del modello o del servizio, i prompt, le impostazioni di recupero delle informazioni e le autorizzazioni degli strumenti, nella misura in cui siano disponibili. Se un fornitore non rende accessibile un dettaglio rilevante, riportare questo limite nella valutazione.

   Includere il passaggio di consegne alla persona incaricata: il revisore riesce a riconoscere una risposta sbagliata, trovare la fonte e respingerla? Correggere i problemi e documentare la ripetizione dei test. Ove possibile, affidare la revisione a una persona diversa da chi ha sviluppato il sistema; un'azienda molto piccola può ricorrere a un revisore esterno adeguatamente qualificato per le decisioni dalle conseguenze rilevanti.

   Da conservare: registrazioni delle valutazioni con controllo delle versioni, problemi irrisolti e collegamenti ai rischi associati. Un'ipotesi non verificata non va trasformata in un esito positivo.

4. 4

   Giorni 21-30: decidere, esercitarsi e rendicontare

   Approvare, limitare o sospendere la funzionalità sulla base delle prove. Indicare chi accetta il rischio residuo e stabilire quali modifiche a dati, modelli, finalità o autorizzazioni richiedano una nuova revisione.

   Simulare un incidente: un cliente segnala che una risposta contiene informazioni di un altro account. Verificare chi può disabilitare l'accesso, conservare le prove, valutare l'impatto, coordinare le comunicazioni e autorizzare il riavvio. Indicare chiaramente che si tratta di un'esercitazione.

   Da conservare: una decisione documentata sul rilascio, l'attribuzione della responsabilità di monitoraggio, il registro degli incidenti e una breve comunicazione per clienti o consiglio di amministrazione che distingua i controlli operativi dal lavoro ancora da completare.

Formazione sul NIST AI RMF: esercitarsi a prendere una decisione

La formazione deve preparare le persone alle decisioni di cui rispondono. GOVERN 2.2 riguarda la formazione sulla gestione del rischio per personale e partner; il risultato atteso è che sappiano svolgere i propri compiti. Core del NIST, Govern.

Per un responsabile del supporto significa riconoscere una divulgazione di dati non sicura, sospendere l'assistente e segnalare il problema ai referenti competenti. Per un ingegnere significa sapere quale modifica alle autorizzazioni richiede una nuova valutazione. Dell'esercitazione vanno conservati scenario, partecipanti, decisioni e azioni successive. Un attestato di completamento di un corso, da solo, non dimostra che la risposta in produzione funzioni.

Il NIST descrive anche i Current Profiles e i Target Profiles, che rappresentano rispettivamente i risultati attuali e quelli desiderati nella gestione del rischio. Confrontarli fa emergere il lavoro ancora da fare. Una piccola azienda può usare questa distinzione nel proprio indice delle prove: attuato, parzialmente attuato, pianificato oppure non applicabile con motivazione. Queste etichette di stato sono una nostra proposta. AI RMF 1.0, sezione 6.

Cosa comunicare a clienti, auditor e consiglio di amministrazione

Prima di dichiarare l'allineamento al framework, occorre descrivere il perimetro e la maturità del lavoro svolto. Un cliente che valuta un assistente di supporto deve sapere se le prove coprono quella funzionalità, la configurazione attuale e le azioni consentite.

Se l'implementazione è ancora in corso, va detto. Per esempio:

Stiamo implementando le pratiche del NIST AI RMF per il nostro assistente di supporto clienti. Abbiamo definito le responsabilità, predisposto l'inventario del sistema e svolto la valutazione dei rischi. Restano da completare la valutazione del sistema e l'esercitazione di risposta agli incidenti. La funzionalità rimane entro l'attuale perimetro ristretto fino al completamento delle relative decisioni.

Se le pratiche sono operative e la documentazione lo dimostra, una risposta più completa potrebbe essere:

Usiamo il NIST AI RMF 1.0 per organizzare la gestione del rischio del nostro assistente di supporto clienti, integrando le azioni pertinenti del Generative AI Profile. Manteniamo regole di responsabilità e supervisione, documentazione del sistema e dei rischi, prove delle valutazioni e procedure per gli incidenti. La dichiarazione di perimetro identifica le configurazioni valutate, i limiti noti, le azioni aperte e la prossima revisione. Questa è una descrizione della nostra implementazione, non una certificazione del NIST.

Sono dichiarazioni esemplificative da adattare alle prove effettivamente disponibili. La formulazione più impegnativa non va copiata se i controlli che dovrebbero sostenerla sono ancora soltanto pianificati.

Si può inviare un breve indice delle prove, con responsabili dei documenti, date e collegamenti ad accesso controllato. Per ogni affermazione, occorre distinguere la policy dalla registrazione che dimostra la sua applicazione. La regola di supervisione descrive ciò che dovrebbe accadere; la registrazione della revisione di un rilascio o di un'approvazione mostra cosa è avvenuto in pratica. Se le prove sottostanti contengono dati dei clienti o dettagli di sicurezza sensibili, si condivide una valutazione con le informazioni riservate oscurate.

Al consiglio di amministrazione vanno presentati soprattutto i rischi irrisolti dalle conseguenze rilevanti, le decisioni necessarie e i relativi responsabili. La percentuale di righe completate in un foglio di calcolo può nascondere l'unico problema aperto che dovrebbe impedire la messa in produzione.

Cosa cambia per chi sviluppa, gestisce e acquista

Chi sviluppa: una nuova facoltà di azione va trattata come una modifica progettuale. Consentire i rimborsi a un assistente che prepara bozze cambia il rischio anche se modello e prompt restano invariati. Prima di abilitare la funzione, vanno aggiornati la descrizione del sistema, i test sulle autorizzazioni e la decisione di approvazione.

Chi gestisce: i feedback devono restare collegati al registro dei rischi. Una lamentela ricorrente su regole inventate deve tradursi nell'analisi di un problema ricorrente, in un caso di valutazione e in una decisione sull'opportunità di continuare a usare il sistema. Serve qualcuno incaricato di portare a termine questo percorso.

Chi acquista e chi fonda un'azienda: occorre chiedere il perimetro valutato, prove recenti delle valutazioni e i limiti ancora presenti. La dichiarazione di allineamento di un fornitore deve spiegare cosa controlla lui e cosa il cliente deve configurare o monitorare in autonomia.

Intervenire subito quando una funzionalità tratta informazioni sensibili, incide su una decisione importante, invia contenuti ai clienti o può modificare registrazioni su sistemi esterni. Adottare un processo più leggero per un esperimento circoscritto che usa informazioni pubbliche o sintetiche e non compie azioni esterne. Rimandare l'ampliamento dell'autonomia quando non si riescono a dimostrare i limiti delle autorizzazioni, il percorso di revisione o il meccanismo di arresto. Sono criteri di priorità proposti qui, non classificazioni del rischio del NIST.

Una revisione del framework non fa sparire i rischi già noti. Occorre continuare a gestirli, indicando esplicitamente nella documentazione la versione utilizzata.

Come si affiancano ISO/IEC 42001 e AI Act europeo

Ogni documento va usato per la propria finalità. ISO/IEC 42001:2023 specifica i requisiti per un sistema di gestione dell'IA a livello organizzativo. Le organizzazioni possono richiedere una certificazione indipendente di quel sistema di gestione; ISO non rilascia direttamente i certificati. Panoramica dello standard ISO; spiegazione della certificazione da parte di ISO.

L'AI Act dell'Unione europea impone obblighi giuridici in funzione del ruolo, del sistema e dell'uso pertinenti. La documentazione prodotta nell'ambito dell'AI RMF può sostenere questo lavoro, ma l'allineamento al framework non dimostra la conformità all'AI Act. Per le regole e le scadenze applicabili, si consultino le indicazioni della Commissione europea sull'AI Act; la nostra pagina sull'AI Act europeo raccoglie gli approfondimenti del sito sul tema.

Il nostro framework di governance dell'IA definisce le responsabilità a livello aziendale; la policy di uso accettabile dell'IA stabilisce le regole rivolte ai dipendenti. Entrambi vanno collegati alle prove relative ai sistemi, evitando di mantenere policy scollegate per ogni framework.

Le promesse eccessive: certificati, percentuali di completamento e modelli sicuri

L'affermazione più esagerata è che adottare il framework dimostri la sicurezza di un sistema. Le indicazioni del NIST organizzano la gestione del rischio; le prove utili restano legate al sistema, al contesto e alle decisioni specifiche. Il Core è espressamente flessibile e iterativo. Core del NIST AI RMF.

Certificazione NIST AI RMF: non è un attestato rilasciato dal NIST

Il NIST non certifica le organizzazioni rispetto all'AI RMF. Occorre descrivere implementazione, perimetro e prove, senza dichiararsi «certificati dal NIST». Una valutazione indipendente può essere utile, ma il rapporto deve indicare chi ha valutato cosa e secondo quali criteri. Non diventa per questo un certificato emesso dal NIST. Il punto di partenza ufficiale è l'AI RMF volontario del NIST.

Una checklist completata non equivale a una decisione sul rischio. Il NIST non fissa una tolleranza universale al rischio e il Playbook non richiede di adottare ogni azione suggerita. Vanno scelti criteri di accettazione adeguati al danno potenziale, spiegandone le ragioni. AI RMF 1.0, sezione 1.2.2; indicazioni del Playbook.

Le prove di un fornitore non coprono l'intera applicazione. I dati recuperati, i controlli di accesso, le integrazioni e gli utenti aggiungono elementi di contesto. Il NIST affronta espressamente i componenti di terze parti e la loro gestione continuativa; occorre conservare le prove del fornitore e verificare al contempo la propria configurazione operativa. Core del NIST, Map e Manage.

La revisione umana non è una protezione magica. Il revisore deve disporre della fonte, del tempo necessario, delle conoscenze pertinenti e dell'autorità per intervenire. Se il flusso di lavoro rende l'approvazione di fatto automatica, va modificato prima di descriverlo come una supervisione efficace.

Domande frequenti

Perché serve un framework per gestire i rischi dell'IA?

Il rischio legato all'IA nasce dall'interazione tra tecnologia, persone e contesto d'uso. Il framework aiuta le organizzazioni a gestire queste interazioni lungo il ciclo di vita, compresi gli impatti sulle persone diverse dall'utente diretto. È una risorsa volontaria: adottarlo non è un obbligo di legge. NIST AI RMF 1.0.

Quali sono 5 rischi dell'IA?

Per una funzionalità di IA generativa, cinque esempi utili sono output falsi ma formulati con sicurezza, divulgazione di dati privati, bias dannosi, eccessivo affidamento da parte delle persone e attacchi che deviano il comportamento del sistema. Corrispondono ad aree trattate nel Generative AI Profile, ma non ne esauriscono l'elenco dei rischi. NIST AI 600-1, sezione 2.

Qual è l'obiettivo principale del framework di gestione del rischio del NIST (RMF)?

Nel caso dell'AI RMF trattato qui, l'obiettivo è aiutare le organizzazioni a gestire i rischi dell'IA e a integrare l'affidabilità nello sviluppo e nell'uso. In una risposta a un cliente è bene specificare «AI RMF», così è chiaro a quale framework ci si riferisce. Panoramica del framework del NIST.

Il NIST AI RMF è obbligatorio?

Il framework in sé è volontario. Occorre verificare separatamente gli impegni contrattuali, i requisiti di approvvigionamento e gli obblighi di legge applicabili all'azienda: adottare un framework volontario non risolve tali obblighi. Panoramica del framework del NIST.

Cosa sostituirà l'RMF?

Per l'AI RMF, la pagina del NIST verificata il 26 ottobre 2026 indica che la versione 1.0 è in revisione e continua a rimandare a essa. Da quell'avviso non va dedotto che sia già stata pubblicata una versione successiva. Il NIST AI 600-1 è il Generative AI Profile che affianca il framework. Pagina del framework del NIST.

L'IA sostituirà la gestione del rischio finanziario (FRM)?

Dall'AI RMF non si può dedurre se il lavoro nella gestione del rischio finanziario verrà sostituito. Questo framework riguarda il modo in cui le organizzazioni gestiscono i rischi dell'IA, comprese le responsabilità umane e la supervisione; non formula previsioni sulla sostituzione di una professione. Core del NIST, Govern.

Quali sono i 3 migliori framework di cybersecurity?

Non esiste una classifica universale dei tre migliori valida per ogni organizzazione. Le indicazioni per la cybersecurity vanno scelte in base ai sistemi, agli obblighi e alle esigenze di garanzia. In questa scelta, l'AI RMF serve ad affrontare i rischi specifici dell'IA affiancandosi al programma di sicurezza esistente; i suoi risultati attesi in materia di sicurezza e resilienza non coprono l'intera funzione di cybersecurity. NIST AI RMF 1.0.

La cybersecurity è un settore destinato a scomparire?

L'introduzione dell'IA non elimina la necessità di occuparsi di sicurezza. L'AI RMF include la valutazione di sicurezza e resilienza, la gestione dei rischi di terze parti e la risposta agli incidenti. Per chi gestisce un sistema in produzione, restano responsabilità da assegnare, il cui svolgimento va dimostrato. È una conseguenza operativa, non una previsione sul mercato del lavoro. Core del NIST.

Qual è oggi la minaccia numero 1 per la cybersecurity?

Nessuna singola minaccia merita quel primato per tutte le aziende. Occorre dare priorità ai fattori che possono causare danni nel proprio contesto operativo. Nell'esempio dell'assistente di supporto, l'accesso non autorizzato ai dati e la prompt injection meritano test espliciti; la loro priorità dipende dai dati e dalle autorizzazioni coinvolti. Generative AI Profile del NIST, sezione 2.9.

Da dove cominciare lunedì

Aprire l'inventario insieme al responsabile della funzionalità di IA dalle conseguenze più rilevanti. Scegliere un problema plausibile, individuare chi potrebbe subirne un danno e collegarlo a un test, a una decisione sul rilascio e a una procedura di arresto. Se manca un collegamento, colmare quella lacuna diventa la prossima azione, assegnata a un responsabile preciso.

La prossima risposta a un cliente avrà così una base concreta: il sistema compreso nel perimetro, le prove disponibili e il lavoro ancora necessario.

Per indicazioni pratiche su come portare l'IA in produzione, iscriviti alla newsletter.