Una AI BOM (in italiano, distinta base dell’IA) è il registro strutturato e leggibile da una macchina di ciò di cui è fatto un sistema di IA: modelli, dataset, dipendenze software, infrastruttura e le relazioni che li legano. Fino al 2026 il suo contenuto era quello che decideva il produttore dello strumento che la generava. Dal 12 maggio 2026 esiste una base ufficiale, pubblicata dalle agenzie di cibersicurezza del G7: 7 gruppi e 50 elementi secondo il nostro conteggio, su base volontaria. Questa guida legge quell’elenco come farebbe un auditor: che cosa registra, che cosa lascia fuori, quali norme ne rendono esigibile il contenuto e come si costruisce.
In sintesi
- Una AI BOM estende la distinta base del software (SBOM) a modelli, dataset, infrastruttura e relativa genealogia: si aggiunge alla SBOM, non la sostituisce.
- Le linee guida del G7 del 12 maggio 2026 elencano 7 gruppi e 50 elementi minimi secondo il nostro conteggio: sono volontarie e non citano alcuna legge.
- Nessun testo dell’UE impone una “AI BOM” con questo nome, ma l’allegato IV, l’articolo 25, paragrafo 4, e gli allegati XI e XII dell’AI Act, insieme all’allegato I del regolamento sulla ciberresilienza, ne richiedono gran parte del contenuto.
- Non registra il rischio legato alla finalità prevista, la sorveglianza umana, i risultati delle prove né il fascicolo dei rischi: è un elenco di ingredienti, non una documentazione tecnica.
- Date: obblighi documentali per i modelli per finalità generali dal 2 agosto 2025, segnalazioni CRA dall’11 settembre 2026, obblighi per l’alto rischio e obbligo di SBOM del CRA da dicembre 2027.
Che cos’è una AI BOM?
Il documento del G7 la definisce come un registro strutturato, o inventario, dei dettagli e delle relazioni di catena di fornitura dei componenti usati per costruire un sistema di IA. L’immagine che propone è quella di un elenco di ingredienti. L’oggetto da cui deriva è la SBOM, la distinta base del software. La SBOM classica però non basta, per tre ragioni. Un modello non è una libreria: il suo comportamento dipende da pesi e dati di addestramento che nessun manifest di pacchetti descrive. Un dataset ha una provenienza, una licenza e un livello di sensibilità, informazioni che una lista di dipendenze non prevede. Infine un sistema di IA chiama servizi esterni. Per le agenzie del G7 i sistemi di IA sono anche sistemi software, quindi la SBOM resta valida e gli elementi specifici dell’IA si aggiungono a quelli generali.
AI BOM, AIBOM, ML-BOM, SBOM per l’IA: un artefatto, più nomi
I nomi in circolazione indicano lo stesso oggetto. AIBOM o AI bill of materials è l’uso corrente nell’industria e in OWASP. ML-BOM è il nome che CycloneDX dà al proprio oggetto. SBOM for AI è la formula scelta dal G7 e dalle agenzie. AI SBOM è il nome dell’iniziativa OWASP dedicata. Due vicini vanno invece tenuti distinti. La model card è la documentazione in prosa di un singolo modello, scritta per le persone: l’elenco del G7 vi rimanda con un link, non la riproduce. L’inventario dei sistemi di IA è l’elenco a livello di organizzazione: sotto ogni scheda dell’inventario si aggancia una AI BOM per ciascuna versione del sistema.
Che cosa contiene una AI BOM: i 50 elementi minimi del G7
Il testo di riferimento si intitola “Software Bill of Materials for AI, Minimum Elements”. È stato pubblicato il 12 maggio 2026 da BSI (Germania), ACN (Italia), ANSSI (Francia), CSE (Canada), CISA (Stati Uniti), NCSC (Regno Unito) e NCO (Giappone), in collaborazione con la Commissione europea. Il filone di lavoro è stato guidato congiuntamente da ACN e BSI sotto le presidenze canadese (2025) e francese (2026) del G7. Segue la visione condivisa del G7 di giugno 2025 ed è stato redatto tra agosto 2025 e febbraio 2026. Sono 26 pagine, scaricabili anche dal sito del BSI. <table header-row=”true”> <tr> <td>Gruppo</td> <td>Elementi</td> <td>Che cosa registra</td> </tr> <tr> <td>Metadati</td> <td>10</td> <td>Il documento stesso: autore, versione, nome e versione del formato dati, firma digitale dell’autore, nome e versione dello strumento, contesto di generazione (prima della build, build, dopo la build), marca temporale, relazione di dipendenza</td> </tr> <tr> <td>Proprietà a livello di sistema</td> <td>9</td> <td>Il sistema di IA nel suo insieme: nome, componenti (modelli, basi di dati, altro software), produttore, versione, marca temporale, flusso dei dati tra componenti e verso servizi esterni, uso dei dati, proprietà di input e output, ambito applicativo previsto</td> </tr> <tr> <td>Modelli</td> <td>13</td> <td>Ogni modello: nome, identificativo, versione, marca temporale, produttore, descrizione (capacità, limiti noti, genealogia come il modello di base usato per il fine-tuning), valore di hash e algoritmo di hash, proprietà (architettura, numero di parametri), proprietà di input e output (lunghezza del contesto, modalità), proprietà di addestramento, licenza, riferimenti esterni (model card, articolo scientifico)</td> </tr> <tr> <td>Proprietà dei dataset</td> <td>10</td> <td>Ogni dataset: nome, descrizione (uso per pre-addestramento, fine-tuning o valutazione), contenuto, identificativo, hash, provenienza (origine, metodo di raccolta come web crawling o accordi commerciali, fasi di trattamento ed etichettatura, metodi per i dati sintetici), proprietà statistiche, sensibilità (dati personali, dati protetti da diritto d’autore, dati finanziari o sanitari), relazione di dipendenza, licenza</td> </tr> <tr> <td>Infrastruttura</td> <td>2</td> <td>Il software necessario a far funzionare il sistema (firmware, librerie, framework, ambienti di esecuzione, strumenti usati dal sistema) e l’hardware, tramite link a una distinta base dell’hardware (HBOM)</td> </tr> <tr> <td>Proprietà di sicurezza</td> <td>4</td> <td>Controlli di sicurezza (generali e specifici dell’IA, per esempio controlli contro la prompt injection e filtri di input e output), conformità di sicurezza (certificazioni e norme), informazioni sulla politica di cibersicurezza (link al file security.txt del produttore), riferimenti alle vulnerabilità</td> </tr> <tr> <td>Indicatori chiave di prestazione</td> <td>2</td> <td>Metriche di sicurezza (per esempio la resilienza alla manipolazione da parte di terzi) e prestazioni operative (disponibilità, tempo di risoluzione degli incidenti, latenza, throughput)</td> </tr> </table> Primo, il peso sta nei modelli e nei dati: 23 dei 50 elementi li descrivono, soltanto 2 descrivono l’infrastruttura, e l’hardware è risolto con un rinvio a una HBOM. Il campo “sensibilità” riprende una parte di ciò che già si documenta per il GDPR. Secondo, l’integrità è incorporata: un hash e il relativo algoritmo per ogni modello, un hash per ogni dataset, la firma digitale dell’autore sul documento stesso. Se l’autore non ha l’informazione, le linee guida chiedono di dichiararla sconosciuta, non di lasciare il campo vuoto. Terzo, la AI BOM non sostituisce la model card: gli elementi “proprietà di addestramento del modello” e “riferimenti esterni del modello” vi rimandano tramite link.
Formati della AI BOM: CycloneDX e SPDX
Oggi due formati aperti trasportano la AI BOM. CycloneDX, progetto OWASP standardizzato come ECMA-424, dispone dalla versione 1.5 di una distinta base per il machine learning (ML-BOM). SPDX 3.0, della Linux Foundation, ha aggiunto un profilo AI e un profilo Dataset, descritti nel rapporto sull’attuazione con SPDX 3.0. Il confronto che segue riprende una presentazione tenuta al NIST il 19 maggio 2026 da Cassie Crossley e Allan Friedman. <table header-row=”true”> <tr> <td>Formato</td> <td>Punto di forza</td> <td>Limite</td> </tr> <tr> <td>CycloneDX ML-BOM (versioni da 1.5 a 1.7)</td> <td>Tipi nativi per il machine learning e ampio supporto negli strumenti</td> <td>Meno campi di metadati sull’IA; nessun campo nativo per dati personali sensibili, spiegabilità, autonomia o rischio per la sicurezza</td> </tr> <tr> <td>SPDX 3.0.1, profilo AI</td> <td>I metadati più ricchi (spiegabilità, energia, dati personali sensibili, rischio per la sicurezza) e relazioni formali “addestrato su” e “testato su”</td> <td>Strumenti ancora in fase di maturazione e un formato JSON-LD meno comodo nelle pipeline di build</td> </tr> </table> Secondo la stessa presentazione, il generatore AIBOM di OWASP, open source e presentato alla RSAC 2025 nell’ambito dell’iniziativa AI SBOM, produce documenti CycloneDX 1.6 per i modelli ospitati su Hugging Face. La mappatura verso il profilo AI di SPDX era ancora in corso a maggio 2026. Le linee guida del G7 non prescrivono alcun formato: il gruppo dei metadati chiede soltanto di indicare nome e versione del formato usato. La regola pratica: scegliere quello che i vostri strumenti SBOM producono già, perché il regolamento sulla ciberresilienza chiederà la SBOM nella stessa pipeline. In un programma di sicurezza dell’IA, due formati paralleli sono due flussi da mantenere.
Che cosa una AI BOM non dimostra
Il testo del G7 dichiara di non creare requisiti, norme o legislazione, e le sue 26 pagine non citano alcun regolamento (verifica nostra sul testo integrale). È un documento di cibersicurezza. Delle 14 pagine meglio posizionate che abbiamo analizzato su questa ricerca, nessuna riporta l’elenco del G7, una sola collega l’artefatto all’allegato IV dell’AI Act e una sola nomina il regolamento sulla ciberresilienza. La tabella confronta l’elenco con ciò che l’allegato IV chiede per la documentazione di un sistema di IA: è una nostra lettura, non una mappatura del G7 o della Commissione. <table header-row=”true”> <tr> <td>Che cosa chiede l’allegato IV</td> <td>È nella AI BOM?</td> <td>Dove si trova la prova</td> </tr> <tr> <td>Finalità prevista, fornitore, versioni (punto 1)</td> <td>In parte: nome del sistema, produttore, versione, ambito applicativo previsto</td> <td>Istruzioni per l’uso, registrazione della classificazione</td> </tr> <tr> <td>Sistemi preaddestrati e strumenti di terzi utilizzati, e come sono stati integrati (punto 2, lettera a)</td> <td>Sì: gruppo Modelli, genealogia, componenti del sistema</td> <td>AI BOM e accordi con i fornitori</td> </tr> <tr> <td>Architettura del sistema e modo in cui i componenti si alimentano a vicenda (punto 2, lettera c)</td> <td>Sì: componenti del sistema, flusso dei dati</td> <td>AI BOM e descrizione dell’architettura</td> </tr> <tr> <td>Dati di addestramento: provenienza, ambito, modalità di ottenimento, etichettatura, pulizia (punto 2, lettera d)</td> <td>In larga parte: gruppo Dataset</td> <td>Schede dei dati, registro di governance dei dati (articolo 10)</td> </tr> <tr> <td>Misure di sorveglianza umana (punto 2, lettera e)</td> <td>No</td> <td>Progettazione e assegnazione della sorveglianza (articolo 14)</td> </tr> <tr> <td>Convalida e prove: metriche, log di prova, relazioni firmate (punto 2, lettera g)</td> <td>Marginale: due elementi sugli indicatori</td> <td>Relazioni di prova, metriche di accuratezza (articolo 15)</td> </tr> <tr> <td>Sistema di gestione dei rischi (punto 5)</td> <td>No</td> <td>Fascicolo di gestione dei rischi (articolo 9)</td> </tr> <tr> <td>Norme applicate, dichiarazione UE di conformità, piano di monitoraggio successivo all’immissione sul mercato (punti 7, 8 e 9)</td> <td>No (solo certificazioni di sicurezza)</td> <td>Fascicolo di conformità</td> </tr> </table> C’è poi un’omissione voluta. Il gruppo del G7 ha discusso un elemento sul livello di autonomia decisionale del sistema, ne ha riconosciuto la rilevanza per l’IA agentica e ha deciso di non farne un elemento a sé, osservando che le giurisdizioni possono trattarlo in modi diversi, anche attraverso requisiti di sicurezza. Per un lettore europeo è esattamente il terreno dell’articolo 14 sulla sorveglianza umana e della classificazione dei sistemi ad alto rischio: quella registrazione deve esistere, ma altrove. Le agenzie concludono nello stesso senso: da sola, una SBOM per l’IA non è sufficiente, va collegata agli strumenti di scansione e gestione delle vulnerabilità e ai bollettini di sicurezza. In una valutazione della conformità la AI BOM è quindi un allegato del fascicolo.
Quali norme rendono esigibile il contenuto di una AI BOM
Nessun testo impone la AI BOM per nome. Diversi ne chiedono la sostanza.
- AI Act, articolo 11 e allegato IV. La documentazione tecnica dei sistemi ad alto rischio va redatta prima dell’immissione sul mercato e tenuta aggiornata. Il punto 2 dell’allegato IV chiede tra l’altro i sistemi preaddestrati o gli strumenti di terzi utilizzati e la loro integrazione, l’architettura del sistema e le schede sui dati di addestramento e sulla loro provenienza. L’articolo 18 ne impone la conservazione per 10 anni. Dopo l’omnibus digitale, regolamento (UE) 2026/1744, si applica ai sistemi dell’allegato III dal 2 dicembre 2027 e a quelli integrati in prodotti dell’allegato I dal 2 agosto 2028.
- AI Act, articolo 25, paragrafo 4. Il fornitore di un sistema ad alto rischio e il terzo che fornisce un sistema, uno strumento, un servizio, un componente o un processo utilizzato in quel sistema precisano con accordo scritto le informazioni, le capacità, l’accesso tecnico e l’assistenza necessari. Fanno eccezione strumenti e componenti, diversi dai modelli per finalità generali, rilasciati con licenza libera e open source. È la base giuridica per chiedere una AI BOM a un fornitore.
- AI Act, articolo 53 e allegati XI e XII. I fornitori di modelli di IA per finalità generali tengono una documentazione tecnica per l’ufficio per l’IA e forniscono informazioni ai fornitori a valle: architettura e numero di parametri, modalità e formato di input e output, licenza, tipo e provenienza dei dati di addestramento. Obblighi applicabili dal 2 agosto 2025.
- AI Act, articolo 15. Accuratezza, resilienza e cibersicurezza dei sistemi ad alto rischio, comprese le misure contro l’avvelenamento dei dati e dei modelli.
- Regolamento sulla ciberresilienza, regolamento (UE) 2024/2847. L’allegato I, parte II, chiede ai fabbricanti di prodotti con elementi digitali di redigere una distinta base del software in un formato di uso comune e leggibile da una macchina, che copra almeno le dipendenze di primo livello. La SBOM fa parte della documentazione tecnica, va consegnata alle autorità di vigilanza del mercato su richiesta e non deve essere pubblicata. La segnalazione delle vulnerabilità attivamente sfruttate si applica dall’11 settembre 2026, il regolamento nel suo insieme dall’11 dicembre 2027. Secondo l’articolo 12, un sistema di IA ad alto rischio che è un prodotto con elementi digitali e soddisfa i requisiti essenziali del CRA si considera conforme al requisito di cibersicurezza dell’articolo 15 dell’AI Act.
- NIS2. La sicurezza della catena di approvvigionamento è una delle misure di gestione dei rischi dell’articolo 21.
I testi di riferimento sono il regolamento sull’IA (AI Act) e il regolamento sulla ciberresilienza. Lo studio Morgan Lewis, in un’analisi del 16 giugno 2026, osserva che l’elenco del G7 si sovrappone agli articoli 11 e 13 e all’allegato IV e si aspetta che gli orientamenti dell’UE ne riprendano alcuni elementi. È una loro valutazione, non una posizione ufficiale. Per l’Italia c’è un elemento in più. L’ACN ha guidato il filone di lavoro del G7 insieme al BSI tedesco e ospita la visione condivisa del 2025. Con la legge 132/2025 la stessa agenzia è anche l’autorità di vigilanza del mercato per l’AI Act, mentre AgID è l’autorità di notifica. Chi ha scritto l’elenco è anche chi può chiedervi il fascicolo.
Come costruire una AI BOM: un metodo in sette passi
- Delimitare il perimetro. Una AI BOM per sistema di IA e per versione, agganciata alla scheda del sistema nell’inventario o nel registro dei sistemi di IA.
- Generare, non scrivere a mano. Estraete i dati dal registro dei modelli, dalla pipeline di addestramento e dalla build, nel formato dei vostri strumenti SBOM. Un documento scritto a mano è superato al primo riaddestramento.
- Compilare i sette gruppi. Dove l’informazione manca, scrivete “sconosciuto”, soprattutto per i modelli di terzi.
- Calcolare gli hash e firmare. File dei modelli, file dei dataset e il documento stesso.
- Collegare ciò che la AI BOM non contiene. Model card, fascicolo di gestione dei rischi, misure di sorveglianza, relazioni di prova.
- Inserirla nei contratti. Chiedetela ai fornitori all’ingresso e a ogni nuova versione del modello, in base all’articolo 25, paragrafo 4, quando il sistema è ad alto rischio: è un punto della due diligence sui fornitori di IA.
- Tenerla viva. Rigeneratela a ogni riaddestramento, fine-tuning, cambio di dipendenza o di strumento, alimentate con essa la gestione delle vulnerabilità e conservate le versioni per 10 anni dove si applicano l’AI Act o il CRA. Una versione datata serve anche per indagare una deriva del modello o si prepara una segnalazione di incidente.
Ogni passo lascia una registrazione datata.
AI BOM per i modelli di terzi e gli agenti di IA
Il primo riguarda i modelli consumati tramite API. Non avete i pesi, quindi nella AI BOM non c’è un hash. La voce onesta è “sconosciuto”, accompagnata dalla documentazione del fornitore. Per i modelli per finalità generali il fornitore deve ai fornitori a valle le informazioni dell’allegato XII, che coprono la maggior parte del gruppo Modelli: si veda la guida sull’IA per finalità generali. Il secondo riguarda gli agenti. L’elemento “flusso dei dati del sistema” del G7 nomina già le API di servizi esterni, i protocolli di comunicazione tra agenti e il web grounding. La presentazione del NIST di maggio 2026 abbozza una distinta base del sistema agentico che aggiunge strumenti, server MCP, prompt, politiche, memoria e legami di identità, oltre alle prove di esecuzione: chiamate agli strumenti, approvazioni, azioni negate. Oggi nessun formato standardizza quel livello. Registrate quindi gli strumenti e i relativi perimetri nei gruppi dei componenti di sistema e dell’infrastruttura e conservate a parte i log di esecuzione (si veda la sicurezza dell’IA agentica). E il deployer? Raramente scrive una AI BOM. La chiede, vi legge tre cose (quale modello e quale versione, quale sensibilità dei dati, quali servizi esterni) e la archivia con la scheda del sistema.
Domande frequenti
Che cos’è una AI BOM in parole semplici? È l’elenco degli ingredienti di un sistema di IA, scritto in un formato che una macchina può leggere. Dice quali modelli usa il sistema e in quale versione, su quali dataset sono stati addestrati, quali librerie e servizi esterni servono e come questi pezzi dipendono l’uno dall’altro. Serve a rispondere in un’ora, e non in una settimana, alla domanda di un cliente o di un’autorità. Non dice a che cosa serve il sistema né quanto è rischioso. Qual è la differenza tra una AI BOM e una SBOM? La SBOM elenca i componenti software di un prodotto: librerie, pacchetti, versioni, dipendenze. La AI BOM aggiunge ciò che un manifest di pacchetti non vede: i modelli con hash, architettura e genealogia, i dataset con provenienza, licenza e sensibilità, il flusso dei dati verso servizi esterni. Secondo le agenzie del G7 le due non sono alternative: gli elementi minimi della SBOM continuano a valere e quelli specifici dell’IA si sommano. Una AI BOM è obbligatoria secondo l’AI Act? Non con questo nome. Il regolamento ne rende però obbligatorio gran parte del contenuto: per i sistemi ad alto rischio attraverso la documentazione tecnica dell’articolo 11 e dell’allegato IV, per i modelli per finalità generali attraverso l’articolo 53 e gli allegati XI e XII. A questo si aggiunge il regolamento sulla ciberresilienza, che per i prodotti con elementi digitali impone una SBOM vera e propria. Quale formato conviene usare? Quello che i vostri strumenti SBOM producono già. CycloneDX offre tipi nativi per il machine learning e ampio supporto; il profilo AI di SPDX 3.0.1 ha metadati più ricchi ma strumenti meno maturi. Il criterio decisivo è operativo: il documento deve uscire dalla build in automatico. Chi deve produrla, il fornitore o il deployer? Chi costruisce il sistema, perché è l’unico ad avere accesso a modelli, dati e pipeline. Per i sistemi ad alto rischio è il fornitore, che può esigere le informazioni dai propri fornitori con l’accordo scritto dell’articolo 25, paragrafo 4. Il deployer di norma non la redige: la richiede in fase di acquisto, la legge e la conserva insieme alla scheda del sistema. Una AI BOM sostituisce la model card o la documentazione tecnica? No. La model card spiega in prosa a che cosa serve un modello e quali limiti ha: l’elenco del G7 la richiama con un link. La documentazione tecnica dell’allegato IV contiene anche la gestione dei rischi, la sorveglianza umana, le prove e la dichiarazione di conformità, che la AI BOM non registra. I tre documenti sono complementari.
Conclusione
Il contenuto di una AI BOM non è più l’opinione di un produttore di strumenti: sette gruppi, cinquanta elementi, sottoscritti da sette agenzie. Quello che l’elenco non dice è quale legge si applica al vostro sistema e che cos’altro vi chiederà un’autorità. Scegliete un sistema, generate la AI BOM dalla pipeline, scrivete “sconosciuto” dove è vero e collegate il resto del fascicolo, dalla model card alla gestione dei rischi. AI Sigil conserva ogni sistema di IA come una scheda con i suoi modelli, dataset, componenti, rischi, controlli e prove: la AI BOM ha così un posto a cui agganciarsi e il resto del fascicolo è a un clic di distanza.