26/10/2026

NIST AI 100-2: la tassonomia degli attacchi all’IA

NIST AI 100-2 è il documento con cui il National Institute of Standards and Technology mette ordine negli attacchi ai sistemi di intelligenza artificiale: una tassonomia degli attacchi all’IA, cioè del machine learning avversario, con un lessico comune e, dall’edizione 2025, un codice stabile per ogni classe di attacco. A un team europeo interessa perché l’articolo 15 dell’AI Act chiede di resistere proprio a quegli attacchi. Qui trasformiamo la tassonomia in un registro delle minacce e in un fascicolo di evidenze difendibile.

Cassetto da collezione in legno aperto, con scomparti etichettati, piccole chiavi di ottone, una lente d'ingrandimento incrinata e un sigillo di ceralacca spezzato: la tassonomia NIST AI 100-2 degli attacchi all'IA

In sintesi

NIST AI 100-2 è il miglior vocabolario disponibile per gli attacchi elencati dall’articolo 15, paragrafo 5, dell’AI Act, ma non è uno strumento di conformità.
L’edizione <code>NIST AI 100-2e2025</code> introduce codici stabili: contiamo 5 categorie di violazione e 25 identificativi di attacco <code>NISTAML</code>.
Quei codici sono la chiave primaria giusta per registro delle minacce, piano di test e fascicolo dell’articolo 15.
Il documento lascia fuori di proposito la decisione sul rischio residuo, che l’AI Act invece impone (articolo 9 e allegato IV).
Le norme arrivate o in arrivo nel 2026 e il Cyber Resilience Act elencano le stesse classi: un registro costruito sui codici NIST si rietichetta, non si ricostruisce.

Che cos’è NIST AI 100-2 e che cosa non è

Il titolo completo è «Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations». L’edizione in vigore, <code>NIST AI 100-2e2025</code>, è stata approvata dall’Editorial Review Board del NIST il 20 marzo 2025 e annunciata dal CSRC il 24 marzo 2025. Sostituisce la <code>NIST AI 100-2e2023</code>, pubblicata nel gennaio 2024. Firmano Apostol Vassilev (NIST), Alina Oprea (Northeastern University), Alie Fordyce e Hyrum Anderson (Cisco), Xander Davies (UK AI Security Institute) e Maia Hamin (US AI Safety Institute).

Il nostro conteggio con pypdf sul PDF ufficiale: 127 pagine e 449 riferimenti numerati, contro 107 pagine e 354 riferimenti della versione precedente. In coda c’è un glossario ricco, utile per allineare team di sicurezza e funzioni di conformità. Il testo è volontario e lo dichiara in nota: «does not establish any legal standard or any other legal requirement or defense under any law». Si appoggia al NIST AI RMF, di cui riprende i concetti di sicurezza, resilienza e resistenza, e precisa nella sintesi iniziale che «does not make recommendations on risk tolerance». È una mappa del terreno, non un regolamento.

Dalla E2023 alla E2025: che cosa cambia in NIST AI 100-2

La novità che conta per chi gestisce un registro sono i codici <code>NISTAML</code>, assenti nella prima versione. Il termine «abuse», usato nel 2023 per le violazioni tipiche dell’IA generativa, diventa «misuse». Compaiono una sezione dedicata alla supply chain dell’IA generativa e nuove sezioni sulla sicurezza degli agenti e sui benchmark, mentre i riferimenti salgono da 354 a 449. Chi conosce il profilo NIST AI 600-1 sull’IA generativa ritroverà molti temi, qui visti dal lato dell’attaccante.

L’etichetta «Super Intelligence»

Un ordine esecutivo del 29 settembre 2026 impone alle agenzie federali statunitensi di scrivere «Super Intelligence» al posto di «Artificial Intelligence» nelle comunicazioni ufficiali. Da allora la pagina del NCCoE si intitola «Super Intelligence: Adversarial Machine Learning». Il 20 ottobre 2026 gli overlay COSAiS per la SP 800-53 sono diventati COSIS, che citano <code>NIST AI 100-2e2025</code> tra le fonti, con la precisazione che «Previously issued documents and publications have not been altered». L’identificativo resta quindi valido. Al 22 ottobre 2026 non risulta alcuna edizione E2026 né bozza pubblica, benché nel marzo 2025 il NIST avesse annunciato aggiornamenti annuali.

Come è costruita la tassonomia

La tassonomia di NIST AI 100-2 incrocia cinque dimensioni. La prima è il tipo di sistema: IA predittiva o IA generativa. La seconda è la fase del ciclo di vita in cui l’attacco colpisce, dall’addestramento al deployment. La terza sono gli obiettivi dell’attaccante: disponibilità, integrità e privacy, a cui per l’IA generativa si aggiunge l’uso improprio (misuse). La quarta sono le capacità: controllo dei dati di addestramento, controllo del modello, accesso alle query, controllo delle risorse che un sistema RAG o un agente con strumenti consulta. La quinta è la conoscenza del bersaglio: white-box, black-box o gray-box. Insieme, le cinque dimensioni descrivono uno scenario d’attacco in modo che due team, o un auditor, lo leggano allo stesso modo.

Su questa griglia la E2025 appoggia cinque categorie di violazione, ciascuna con il proprio codice:

<code>NISTAML.01</code> disponibilità
<code>NISTAML.02</code> integrità
<code>NISTAML.03</code> privacy
<code>NISTAML.04</code> uso improprio (misuse)
<code>NISTAML.05</code> supply chain

Sotto le categorie stanno 25 identificativi di attacco, per un totale di 30 codici nel nostro conteggio. Perché contano? Un registro delle minacce costruito su etichette libere («prompt injection grave», «furto del modello») invecchia al primo cambio di strumento o di fornitore. Un codice come <code>NISTAML.033</code> resta invece identico nel piano di test, nel report di red teaming, nella documentazione tecnica e nelle tabelle di raccordo verso MITRE ATLAS. È la chiave primaria che mancava alla sicurezza dell’IA intesa come disciplina documentabile. Chi cerca un termine di paragone europeo può incrociare questi codici con il catalogo di minacce e controlli del rapporto ENISA Securing Machine Learning Algorithms (2021).

Attacchi all’IA predittiva: evasione, avvelenamento, privacy

Evasione. L’attacco di evasione (<code>NISTAML.022</code>) altera l’input al momento dell’inferenza per ottenere una decisione sbagliata; la variante black-box (<code>NISTAML.025</code>) lavora soltanto tramite query. La trasferibilità peggiora il quadro: un esempio costruito contro un modello sostitutivo spesso funziona anche contro quello reale. Il caso di scuola resta quello dei segnali di stop letti come limiti di velocità, ma nei sistemi di visione, antifrode o moderazione dei contenuti è il primo scenario da testare.

Avvelenamento. Sul versante della disponibilità NIST AI 100-2 distingue avvelenamento dei dati (<code>NISTAML.013</code>), avvelenamento del modello (<code>NISTAML.011</code>), avvelenamento clean-label (<code>NISTAML.012</code>) e attacchi energia-latenza (<code>NISTAML.014</code>). Sul versante dell’integrità troviamo l’avvelenamento mirato (<code>NISTAML.024</code>), le backdoor (<code>NISTAML.023</code>) e le backdoor clean-label (<code>NISTAML.021</code>), l’avvelenamento del modello (<code>NISTAML.026</code>) e quello che transita dalla supply chain (<code>NISTAML.051</code>).

Privacy. Gli attacchi alla riservatezza comprendono l’estrazione del modello (<code>NISTAML.031</code>), la ricostruzione dei dati (<code>NISTAML.032</code>), l’inferenza di appartenenza (<code>NISTAML.033</code>) e l’inferenza di proprietà (<code>NISTAML.034</code>).

Le contromisure elencate sono note: addestramento avversario, randomized smoothing e verifica formale contro l’evasione; sanificazione dei dati e ispezione del modello contro l’avvelenamento; privacy differenziale contro gli attacchi alla privacy. Il NIST però è franco. Le mitigazioni sono in gran parte empiriche, mancano prove di sicurezza fondate sulla teoria dell’informazione per gli algoritmi di ML più diffusi, e la ricerca citata mostra che, finché un modello conserva una probabilità non nulla di comportarsi in modo indesiderato, esiste un prompt capace di innescare quel comportamento. Per questo la prova sul campo conta più della promessa del fornitore, e il red teaming dell’IA diventa un’attività ricorrente, non un collaudo una tantum.

Attacchi all’IA generativa: supply chain, prompt diretti, iniezione indiretta, agenti

Con l’IA generativa la superficie si allarga. La prompt injection diretta (<code>NISTAML.018</code>) comprende i jailbreak: l’utente scrive istruzioni che aggirano le regole del sistema. La prompt injection indiretta (<code>NISTAML.015</code>) è più insidiosa, perché le istruzioni malevole arrivano da contenuti recuperati: una pagina web, un’email, un documento indicizzato dal RAG. Con <code>NISTAML.017</code> lo stesso canale serve a far eseguire in background compiti lunghi che consumano risorse.

Gli altri identificativi di NIST AI 100-2 coprono output non allineati (<code>NISTAML.027</code>), estrazione del prompt di sistema (<code>NISTAML.035</code>), fuga di informazioni dalle interazioni con gli utenti (<code>NISTAML.036</code>), attacchi ai dati di addestramento (<code>NISTAML.037</code>), estrazione di dati (<code>NISTAML.038</code>) e compromissione delle risorse collegate (<code>NISTAML.039</code>). La sezione sulla supply chain ricorda che pesi, dataset e componenti di terzi entrano nel sistema portandosi dietro i propri rischi.

Sugli agenti il NIST è prudente: la ricerca di sicurezza dedicata «is still in its early stages» (sezione 3.5). La conseguenza pratica è però chiara. Quando un modello può chiamare strumenti, una prompt injection non produce più soltanto testo sbagliato, ma esecuzione di codice o esfiltrazione di dati. Ne parliamo nella guida alla sicurezza dell’IA agentica e nella lettura della OWASP Top 10 per gli LLM in chiave di conformità.

Il documento cita anche benchmark e strumenti di misura: JailbreakBench e HarmBench per i jailbreak, AgentDojo per gli agenti, scanner come Garak e PyRIT. Non sono certificazioni, ma danno metodo e ripetibilità ai test, che è esattamente ciò che un fascicolo deve dimostrare.

Che cosa NIST AI 100-2 lascia deliberatamente fuori

Abbiamo cercato nel testo della <code>NIST AI 100-2e2025</code>, sempre con pypdf, i riferimenti normativi. Risultato: nessuna menzione dell’AI Act europeo né dell’«Artificial Intelligence Act», nessuna di ISO/IEC 42001 o di qualsiasi altra norma ISO/IEC; «compliance» compare una sola volta, «regulation» due. Non è una svista. La sezione 4.2.5 lo dice apertamente:

«A key question that this taxonomy deliberately leaves aside is how organizations can make decisions about the development and use of AI systems in light of evidence about the increasing diversity of AML attacks and the efficacy and limitations of available mitigations.»

In altre parole, il NIST descrive attacchi e difese, ma non dice come un’organizzazione debba decidere se sviluppare o adottare un sistema alla luce di quegli attacchi e dei limiti delle contromisure. Restano fuori anche gli attacchi di cybersecurity tradizionali contro la piattaforma (server, rete, credenziali), i difetti di progettazione non avversari e ogni indicazione sulla tolleranza al rischio. Per un CISO significa che la tassonomia si affianca al programma di sicurezza esistente, senza sostituirlo: identità, patching e segmentazione restano dove sono.

Quel vuoto è esattamente lo spazio che occupa l’AI Act. Per un sistema di IA ad alto rischio l’articolo 9 impone una gestione del rischio che copra anche l’uso improprio ragionevolmente prevedibile e chiede, al paragrafo 5, di giudicare accettabile il rischio residuo. L’allegato IV, punto 2, lettera h), pretende nella documentazione tecnica la descrizione delle misure di cybersicurezza adottate. La tassonomia fornisce il lessico; la decisione firmata resta a carico vostro.

NIST AI 100-2 e l’articolo 15, paragrafo 5, dell’AI Act: la tabella di raccordo

L’articolo 15, paragrafo 5, del regolamento (UE) 2024/1689 chiede anzitutto che i sistemi ad alto rischio resistano ai tentativi di terzi non autorizzati di alterarne l’uso, gli output o le prestazioni sfruttando le vulnerabilità del sistema. Aggiunge che le soluzioni tecniche contro le vulnerabilità specifiche dell’IA comprendono, ove opportuno, misure per prevenire, accertare, rispondere, risolvere e controllare gli attacchi che tentano di manipolare il set di dati di addestramento (data poisoning) o i componenti preaddestrati usati nell’addestramento (model poisoning), gli input progettati per indurre il modello in errore (esempi antagonistici o evasione dal modello), gli attacchi alla riservatezza o i difetti del modello. La parafrasi, fedele, è nostra: fa fede il testo italiano su EUR-Lex.

La tabella è nostra, non del NIST né della Commissione.

Termine dell’articolo 15, paragrafo 5	Classi e identificativi NIST AI 100-2	Evidenze da tenere nel fascicolo
Avvelenamento dei dati (data poisoning)	<code>NISTAML.013</code>, <code>NISTAML.012</code>, <code>NISTAML.024</code>, backdoor <code>NISTAML.021</code> e <code>NISTAML.023</code>	Provenienza e sanificazione dei dati di addestramento, test di avvelenamento, legame con l’articolo 10 sulla governance dei dati
Avvelenamento del modello (componenti preaddestrati)	<code>NISTAML.011</code>, <code>NISTAML.026</code>, supply chain <code>NISTAML.051</code>	AI bill of materials, provenienza del modello e verifica degli hash, attestazioni dei fornitori
Esempi antagonistici o evasione dal modello	<code>NISTAML.022</code>, <code>NISTAML.025</code>; per i sistemi generativi, nella nostra lettura, anche <code>NISTAML.018</code> e <code>NISTAML.015</code>	Piano e risultati dei test avversari, metriche di resistenza nella sezione sui test dell’allegato IV
Attacchi alla riservatezza	Da <code>NISTAML.031</code> a <code>NISTAML.039</code> (estrazione, inferenze di appartenenza e proprietà, estrazione di prompt e dati)	Test di attacco alla privacy, prove di rate limiting e filtraggio degli output, collegamento con la valutazione d’impatto GDPR
Difetti del modello	In gran parte fuori da NIST AI 100-2 (i difetti non avversari sono esclusi)	Test di accuratezza e resistenza ai sensi dell’articolo 15, paragrafi da 1 a 4
Circuiti di feedback (articolo 15, paragrafo 4, sistemi che continuano ad apprendere)	Avvelenamento tramite feedback, <code>NISTAML.013</code> e <code>NISTAML.024</code>	Monitoraggio della deriva e dei dati in ingresso, piano di monitoraggio successivo all’immissione sul mercato (articolo 72)

Per effetto dell’Omnibus digitale sull’IA (regolamento (UE) 2026/1744) l’articolo 15 vincola i sistemi ad alto rischio dell’allegato III dal 2 dicembre 2027 e quelli dell’allegato I dal 2 agosto 2028. Per i modelli di IA per finalità generali con rischio sistemico l’articolo 55, paragrafo 1, lettera a) (valutazione del modello con test avversari documentati) e lettera d) (adeguata protezione di cybersicurezza) si applica dal 2 agosto 2025, e dal 2 agosto 2026 la Commissione può sanzionare i fornitori. Il capitolo Safety and Security del codice di buone pratiche (10 luglio 2025) li traduce in valutazioni, test avversari e misure di sicurezza.

Le norme europee che daranno contenuto all’articolo 15

prEN 18282. È il progetto di norma europea sulla cybersicurezza dei sistemi di IA preparato dal gruppo di lavoro 5 del CEN-CENELEC JTC 21 a supporto dell’articolo 15. L’inchiesta pubblica si è svolta dal 15 maggio a metà luglio 2026 e la pubblicazione è attesa tra la fine del 2026 e l’inizio del 2027. Darà presunzione di conformità solo dopo la citazione nella Gazzetta ufficiale dell’UE.

ETSI EN 304 223. Pubblicata il 14 gennaio 2026 (comunicato ETSI), fissa 13 principi distribuiti su cinque fasi del ciclo di vita: progettazione sicura, sviluppo, deployment, manutenzione, fine vita. Riprende la specifica ETSI TS 104 223; per l’IA generativa è annunciato il rapporto tecnico ETSI TR 104 159.

ISO/IEC 27090:2026. La prima edizione è uscita a ottobre 2026: 56 pagine di linee guida, non certificabili, che trattano avvelenamento, manipolazione dei pesi, evasione, estrazione, inferenza di appartenenza e inversione del modello, prompt injection (sintesi di heise).

La via del Cyber Resilience Act. In base all’articolo 12 del regolamento (UE) 2024/2847, un sistema di IA ad alto rischio che è anche un prodotto con elementi digitali si considera conforme ai requisiti di cybersicurezza dell’articolo 15 se soddisfa l’allegato I del CRA e se il livello di protezione risulta dalla dichiarazione di conformità UE prevista dal CRA. Accuratezza e resistenza restano sotto l’AI Act. Dall’11 settembre 2026 valgono gli obblighi di segnalazione del CRA per vulnerabilità attivamente sfruttate e incidenti gravi: preallarme entro 24 ore e notifica entro 72 ore, tramite la piattaforma unica di segnalazione dell’ENISA; per le vulnerabilità sfruttate la relazione finale va inviata entro 14 giorni dalla disponibilità di una misura correttiva. Infine l’articolo 42, paragrafo 2, dell’AI Act riconosce la stessa presunzione ai sistemi ad alto rischio certificati nell’ambito di uno schema adottato ai sensi del regolamento (UE) 2019/881.

In Italia il punto d’incontro è uno solo. La legge 132/2025 designa l’Agenzia per la Cybersicurezza Nazionale (ACN) come autorità di vigilanza del mercato per l’AI Act, accanto all’AgID, autorità di notifica. Poiché l’ACN è anche l’autorità nazionale per la cybersicurezza, evidenze di sicurezza dell’IA ed evidenze cyber arriveranno sullo stesso tavolo.

La nostra lettura: tutte queste fonti elencano le stesse classi di attacco già catalogate da NIST AI 100-2, con nomi diversi. Un registro indicizzato sui codici <code>NISTAML</code> si rietichetta per ciascuna norma invece di essere ricostruito. Per il quadro completo dei percorsi di valutazione della conformità rimandiamo alla nostra analisi dello stack di norme dietro l’AI Act.

Da NIST AI 100-2 al fascicolo delle evidenze in sette passaggi

Inventariare e classificare. Censite ogni sistema e classificatelo come predittivo, generativo o agentico, e poi come ad alto rischio, modello per finalità generali o altro. Questa doppia classificazione decide quali articoli si applicano e quali identificativi sono pertinenti; il punto di partenza è la guida ai sistemi di IA ad alto rischio.
Modellare le minacce. Confrontate ogni sistema con gli identificativi <code>NISTAML</code> e registrate le capacità realistiche dell’attaccante: solo accesso alle query, API di fine-tuning, ingestione nel RAG, accesso agli strumenti. Un chatbot interno senza strumenti e un agente con accesso alla posta non hanno lo stesso profilo.
Collegare i controlli. Associate a ogni identificativo trattenuto i controlli che lo mitigano, usando MITRE ATLAS e la OWASP Top 10 per il dettaglio delle tecniche. Annotate anche i controlli di piattaforma che il NIST esclude dal perimetro, come identità e segmentazione di rete, per i quali il riferimento naturale resta il NIST CSF.
Testare. Pianificate test avversari e red teaming con gli strumenti citati dal NIST, per esempio Garak, PyRIT o AgentDojo. Registrate metodo, perimetro, versione del modello e risultati, indicizzati per identificativo.
Decidere e firmare il rischio residuo. Per ogni identificativo, una persona con l’autorità per farlo dichiara se il rischio residuo è accettabile e perché. È la decisione che il NIST lascia da parte e che l’articolo 9, paragrafo 5, richiede.
Scrivere la documentazione. Redigete la sezione sulla cybersicurezza prevista dall’allegato IV, punto 2, lettera h), e la parte della dichiarazione di conformità relativa all’articolo 15, citando gli identificativi. Un valutatore deve poter risalire da ogni affermazione al test che la sostiene.
Monitorare e segnalare. Integrate gli identificativi nel monitoraggio successivo all’immissione sul mercato (articolo 72) e nella segnalazione degli incidenti gravi (articolo 73), senza dimenticare il preallarme di 24 ore del CRA per le vulnerabilità attivamente sfruttate. Rivedete il registro una volta l’anno, in linea con il ciclo di aggiornamento annunciato dal NIST.

AI Sigil riunisce per ciascun sistema registro dei rischi, controlli, evidenze e decisioni sul rischio residuo nello stesso fascicolo: è il compito del nostro software di gestione dei rischi dell’IA.

Domande frequenti

NIST AI 100-2 è obbligatorio in Europa?

No. È una pubblicazione volontaria di un’agenzia federale statunitense e lo scrive esplicitamente: non crea alcun obbligo né alcuna difesa legale. In Europa l’obbligo viene dall’AI Act, che all’articolo 15 chiede ai sistemi ad alto rischio di resistere ad attacchi come avvelenamento, evasione e violazioni della riservatezza, e all’articolo 55 impone test avversari ai modelli per finalità generali con rischio sistemico. NIST AI 100-2 resta però il riferimento più pratico per dare un nome preciso a quegli attacchi e strutturare test ed evidenze.

Che cosa è cambiato tra l’edizione 2023 e quella 2025?

La <code>NIST AI 100-2e2025</code> introduce i codici stabili <code>NISTAML</code>: nel nostro conteggio 5 categorie di violazione e 25 identificativi di attacco, assenti nella versione del gennaio 2024. Il termine «abuse» diventa «misuse» e arrivano una sezione sulla supply chain dell’IA generativa e nuove sezioni dedicate agli agenti e ai benchmark. Il documento passa da 107 a 127 pagine e da 354 a 449 riferimenti. Per chi gestisce un registro, i codici sono il cambiamento decisivo.

NIST AI 100-2 copre gli agenti di IA?

Sì, ma con cautela. L’edizione 2025 dedica una sezione alla sicurezza degli agenti e ammette che la ricerca specifica è ancora agli inizi. Il rischio centrale è la prompt injection indiretta (<code>NISTAML.015</code>): un agente che legge contenuti esterni e può chiamare strumenti trasforma un’istruzione nascosta in esecuzione di codice o esfiltrazione di dati. Tra i benchmark citati figura AgentDojo, pensato proprio per misurare la tenuta degli agenti di fronte a questi attacchi.

Come si collega a MITRE ATLAS e alla OWASP Top 10 per le applicazioni LLM?

Sono complementari. NIST AI 100-2 fornisce tassonomia e lessico: classi di attacco, obiettivi, capacità dell’attaccante. MITRE ATLAS scende al livello delle tattiche e delle tecniche osservate, mentre la OWASP Top 10 per gli LLM mette in fila i rischi applicativi più frequenti. Nella nostra pratica il codice <code>NISTAML</code> fa da chiave primaria del registro e a ciascun codice colleghiamo le voci ATLAS e OWASP pertinenti, così un cambio di framework non obbliga a rifare il lavoro.

Seguire NIST AI 100-2 basta per l’articolo 15 dell’AI Act?

No. Il documento descrive attacchi e mitigazioni, ma non fissa soglie, non raccomanda livelli di tolleranza al rischio e lascia esplicitamente fuori la decisione su come procedere. L’AI Act chiede invece un rischio residuo giudicato accettabile (articolo 9), una descrizione delle misure di cybersicurezza nella documentazione tecnica (allegato IV) e prove di test. NIST AI 100-2 è un ottimo indice per organizzare quelle prove; la presunzione di conformità arriverà dalle norme armonizzate, come <code>prEN 18282</code>, una volta citate in Gazzetta.

Perché le pagine del NIST ora parlano di «Super Intelligence»?

Per effetto dell’ordine esecutivo del 29 settembre 2026, che impone alle agenzie federali statunitensi di usare «Super Intelligence» o «SI» al posto di «Artificial Intelligence» o «AI» nelle comunicazioni ufficiali e nei documenti non legislativi. Per le aziende private non nasce alcun obbligo. Il NIST ha aggiornato titoli e nomi di progetto, ma ha precisato che i documenti già pubblicati non sono stati modificati: l’identificativo <code>NIST AI 100-2e2025</code> resta quello da citare nei vostri fascicoli.

Conclusione

NIST AI 100-2 è oggi il modo più preciso per descrivere che cosa può andare storto in un sistema di IA sotto attacco, ma non dice che cosa farne. L’AI Act colma proprio quel vuoto: obbliga a scegliere, a firmare il rischio residuo e a documentare le misure adottate. La nostra raccomandazione è semplice. Adottate i codici <code>NISTAML</code> come chiave primaria del registro delle minacce, del piano di test e del fascicolo dell’articolo 15, e collegate a ciascun codice controlli, prove e decisioni. Quando <code>prEN 18282</code> sarà citata in Gazzetta e il NIST pubblicherà la prossima edizione, vi basterà rietichettare, senza ricostruire nulla. Se volete partire dal vostro inventario, il nostro software di gestione dei rischi dell’IA è pensato per tenere insieme registro, controlli ed evidenze.

Marco Conti