AI Bill of Materials (AIBOM): Guida completa

Un AI bill of materials (AIBOM) è un inventario strutturato dei set di dati, dei modelli e delle dipendenze in un sistema di IA, che apporta trasparenza alla supply chain dell'IA.

Che cos'è un AI Bill of Materials (AIBOM)?

Nel maggio 2026, un repository Hugging Face malevolo che impersonava una release ufficiale di OpenAI ha raggiunto la prima posizione tra i contenuti di tendenza della piattaforma prima di essere segnalato e rimosso. Avendo copiato la model card autentica quasi riga per riga, l'inserzione sembrava legittima e chiunque l'avesse già scaricata non aveva modo di saperlo, perché una scansione delle dipendenze software ispeziona librerie e pacchetti mentre la compromissione risiedeva nel modello stesso.

Un AI bill of materials (AIBOM) ti offre ciò che quella scansione non poteva offrire: un modo per sapere se un modello compromesso o un dataset avvelenato è già presente nel tuo ambiente.

Un AIBOM è un inventario strutturato dei dataset, modelli, framework e dipendenze che compongono un sistema di IA, con la provenienza di ciascun componente registrata. Copre gli asset la cui origine altrimenti non sarebbe documentata: dati di terze parti, modelli preaddestrati e librerie open source.

Come un AIBOM si relaziona a un Software Bill of Materials

Un software bill of materials elenca i componenti software e le dipendenze di un'applicazione: librerie, pacchetti, identificatori di versione e licenze. Un AIBOM estende questa pratica di inventario agli asset specifici dell'IA, inclusi dati di addestramento, pesi del modello, provenienza del modello e baseline delle prestazioni. CycloneDX, lo standard BOM di OWASP, implementa questo approccio definendo SBOM e AI/ML-BOM come tipi di BOM interoperabili.

Componenti principali di un AIBOM

Un AIBOM registra l'insieme completo dei componenti che definiscono la composizione, l'origine e il profilo operativo di un sistema di IA. La guida del maggio 2026 del G7 Cybersecurity Working Group, pubblicata come elementi minimi AI SBOM di CISA, organizza questi componenti in sette cluster.

Cluster di componenti	Cosa acquisisce	Perché è incluso
Metadati	Autore dell'AIBOM, data di creazione, versione dello schema, identificatore del documento	Stabilisce la catena di custodia per l'artefatto di inventario
Proprietà a livello di sistema	Dipendenze software, framework, ambienti di runtime, logica di elaborazione dei dati	Corrisponde al contenuto tradizionale di uno SBOM; consente il tracciamento dei CVE
Modelli	Identità del modello, architettura, modalità di produzione dei pesi (addestrati, fine-tuned o distillati), limitazioni documentate	I pesi del modello non hanno un equivalente nel package manager; la provenienza consente l'identificazione delle manomissioni
Proprietà dei dataset	Identità, provenienza, licenze, metodologia di raccolta e preelaborazione applicata ai dataset di addestramento, validazione e test	Il data poisoning non è identificabile tramite analisi software; i registri di provenienza tracciano se i dati di addestramento sono stati manomessi
Indicatori chiave di prestazione	Benchmark di accuratezza, equità e resilienza agli attacchi avversari registrati al momento del deployment	Stabilisce baseline comportamentali; il degrado può indicare manipolazione avversaria
Infrastruttura	Infrastruttura fisica e virtuale, collegamenti a Hardware BOM per hardware IA specializzato (GPU, TPU)	Documenta l'ambiente di calcolo che ha prodotto ed esegue il modello
Struttura del documento e cadenza di aggiornamento	Versioning del formato AIBOM, trigger di aggiornamento, registri delle transizioni del ciclo di vita	Definisce quando e come si aggiorna l'inventario; collega ogni transizione del ciclo di vita alle modifiche richieste nei cluster interessati

Questi sette cluster descrivono ciò che contiene un AIBOM. Il momento in cui popolare ciascuno dipende dal ciclo di vita del modello: il record viene costruito per fasi, non in un unico passaggio.

Come viene generato e mantenuto un AIBOM lungo il ciclo di vita del modello

Un record AIBOM prende forma attraverso quattro fasi del ciclo di vita, con ciascuna fase che popola cluster specifici dalla tassonomia dei componenti sopra descritta.

1. Approvvigionamento e preparazione dei dati. L'AIBOM inizia qui con le Proprietà dei dataset: acquisisci identità, provenienza, licenze e integrità di ogni dataset di addestramento, validazione e test prima che inizi l'addestramento del modello. Aggiorna questo cluster alla raccolta iniziale e a ogni evento di riaddestramento o fine-tuning.
2. Addestramento e fine-tuning del modello. Durante l'addestramento, registri il collegamento tra dataset di input, codice di addestramento, configurazioni degli iperparametri e pesi del modello risultanti. Gli eventi di fine-tuning richiedono aggiornamenti sia al cluster del modello sia al cluster del dataset.
3. Build e deployment. Al deployment, popoli completamente il cluster Proprietà a livello di sistema con dipendenze software, framework e dettagli dell'ambiente di runtime. Vengono registrati i valori baseline dei KPI. I componenti dell'infrastruttura vengono documentati o collegati tramite un HBOM.
4. Monitoraggio e manutenzione continui. La manutenzione dell'AIBOM è guidata dagli eventi. Le modifiche a qualsiasi componente nei sette cluster attivano aggiornamenti, inclusi modelli riaddestrati, dipendenze corrette, versioni dei dataset e cambiamenti dell'infrastruttura. Strumenti di discovery autonomi e formati machine-readable mantengono accurato il record aggiornandolo quando si verificano cambiamenti.

In queste quattro fasi, un AIBOM rimane affidabile solo quando il suo formato e le sue regole di aggiornamento sono fissati in anticipo, come specificano gli standard attuali.

Standard e framework AIBOM

Quattro standard interconnessi costituiscono l'attuale base autorevole per l'implementazione dell'AIBOM. Ognuno affronta un diverso livello dello stack di governance.

1. NIST AI Risk Management Framework. Il Risk Management Framework per l'IA del NIST stabilisce tracciabilità e accountability come proprietà fondamentali per un'IA affidabile. La sua prima release, AI RMF 1.0, ha definito questa baseline nel gennaio 2023, e il Generative AI Profile l'ha estesa ai sistemi generativi nel luglio 2024. Il report del NIST dell'aprile 2025 AI 100-5e2025 collega esplicitamente le supply chain dell'IA ai meccanismi SBOM, facendo riferimento a model card e data card insieme ai software bill of materials come strumenti di trasparenza.
2. OWASP CycloneDX ML-BOM. La funzionalità ML-BOM, introdotta in CycloneDX v1.5 ed estesa nelle versioni successive, rappresenta dataset, modelli e configurazioni per sistemi AI/ML, inclusa la documentazione della provenienza e considerazioni etiche per i dataset.
3. Profili AI e Dataset di SPDX 3.0. SPDX, uno standard ISO/IEC, ha aggiunto i profili AI e Dataset nella versione 3.0. Questi profili documentano modelli di IA, dati di addestramento, template di prompt, agenti IA e licenze.
4. Elementi minimi di CISA e G7. CISA ha pubblicato gli elementi minimi di SBOM che coprono il software di IA nell' agosto 2025. Nel maggio 2026, le agenzie di cybersecurity di tutti gli Stati membri del G7 più l'UE hanno pubblicato una guida congiunta che definisce sette cluster di potenziali elementi per gli AI SBOM, illustrati nella guida congiunta del G7.

L'adozione dell'AIBOM è ancora nelle fasi iniziali e le implementazioni attuali sono spesso incomplete o inaccurate. Ma gli standard ti offrono una base su cui costruire.

Perché un AIBOM è importante per sicurezza, conformità e verificabilità

Per la sicurezza, un AIBOM registra la provenienza dei dataset e i checksum dei pesi del modello in modo che i team possano verificare se i modelli sono stati addestrati su dati manomessi. Quando vulnerabilità o componenti compromessi interessano l'infrastruttura IA, l'AIBOM ti indica quali sistemi sono coinvolti.

Per la conformità, l'EU AI Act include obblighi di trasparenza e documentazione per determinati sistemi e modelli di IA, inclusi documentazione tecnica e riepiloghi dei contenuti di addestramento. Un AIBOM supporta tali obblighi creando un record strutturato della composizione.

Per la verificabilità, l'AIBOM fornisce agli auditor e ai team di incident response una risposta tracciabile e versionata quando chiedono da cosa è stato costruito uno specifico sistema di IA. Il record mostra quali dataset lo hanno addestrato, quali pesi del modello sono distribuiti e quali framework e dipendenze lo supportano. Senza questo record, la tua risposta a qualsiasi domanda di audit sulla composizione dell'IA è, nel migliore dei casi, un tentativo di ricostruzione.

Ciascuno di questi risultati presuppone che il record sia accurato e aggiornato. Raggiungere questo stato su scala enterprise incontra vincoli strutturali che il solo impegno non elimina.

Sfide nell'implementazione di un AIBOM

I vincoli strutturali rendono difficile l'implementazione dell'AIBOM indipendentemente dalla maturità organizzativa o dalle risorse disponibili.

• Immaturità di standard e strumenti. CycloneDX ML-BOM, i profili AI di SPDX 3.0 e la guida del G7 sono tutti arrivati di recente, quindi pratiche e strumenti sono ancora in fase di assestamento.
• Modelli opachi di terze parti. I foundation model proprietari accessibili tramite API di inferenza rivelano poco dei loro elementi interni. Puoi registrare nome, versione, endpoint, controlli di accesso e attestazioni del fornitore, ma la composizione completa dei modelli chiusi resta fuori portata.
• Provenienza dei dati di addestramento. Per i modelli addestrati esternamente, la provenienza potrebbe non essere mai divulgata. Per i modelli interni, devi acquisirla durante l'addestramento, perché la ricostruzione a posteriori non è affidabile.
• Versioning rapido dei modelli. Ogni riaddestramento o modifica dei parametri crea una nuova versione effettiva con un proprio profilo di rischio, producendo una proliferazione di versioni che nessun processo manuale può tracciare su larga scala.
• Ambienti eterogenei. L'IA enterprise si estende tra cloud provider, infrastruttura on-premises, strumenti IA SaaS, IA incorporata in applicazioni di terze parti, sistemi agentici e database vettoriali.

Questi vincoli sono esterni, quindi il massimo che puoi fare è progettare tenendone conto. I fallimenti nella sezione successiva sono l'opposto, ed è tua responsabilità prevenirli.

Errori comuni nell'implementazione di un AIBOM

Errore	Conseguenza
Trattare l'AIBOM come un documento una tantum prodotto per un audit	L'incident response prende decisioni basandosi su un record che non riflette più la produzione
Mantenere l'inventario manualmente	Il ritmo di cambiamento di modelli, dataset e API supera qualsiasi processo gestito da esseri umani, quindi il record diventa obsoleto
Registrare nomi e versioni dei modelli senza provenienza	Il data poisoning e il model poisoning restano non identificabili, perché l'identificazione dipende dalla lineage dell'addestramento, dai checksum dei pesi e dai metadati di esecuzione che non possono essere ricostruiti a posteriori
Gestire l'AIBOM come un file di conformità standalone scollegato dagli strumenti di engineering	Si formano due inventari che divergono; la guida SBOM di CISA definisce il bill of materials come un inventario annidato per il rischio della supply chain, e gestire l'AIBOM al di fuori della toolchain SBOM interrompe quel collegamento
Limitare l'ambito dell'inventario all'IA approvata dall'IT e omettere la shadow AI	Nel record permane un punto cieco sistematico

Ciascun errore sopra è una scelta di processo, quindi ciascuno ha una correzione di processo. Le pratiche seguenti trasformano l'inventario da file statico a controllo operativo.

Best practice per l'AIBOM

Le seguenti azioni portano il tuo programma AIBOM dalla documentazione statica a uno strumento operativo di governance.

• Distribuisci discovery e generazione autonome. Integrale nei registri dei modelli, negli API gateway e negli inventari dei servizi cloud di IA.
• Standardizza su un formato machine-readable. Produci CycloneDX ML-BOM o i profili AI di SPDX 3.0. I fogli di calcolo leggibili dall'uomo non possono alimentare i workflow che rendono operativo il valore di sicurezza dell'inventario.
• Acquisisci la provenienza alla fonte. Registra identificatori dei dataset di addestramento e fine-tuning, checksum dei pesi del modello, metadati delle esecuzioni di addestramento e version pin delle API di inferenza. Per i modelli interni, integra il tracciamento della provenienza nella pipeline ML al momento dell'addestramento.
• Applica controlli CI/CD basati sull'AIBOM. Genera l'AIBOM alla creazione degli artefatti di addestramento, agli eventi di push nel registry e alle modifiche della configurazione di deployment, e tratta un AIBOM mancante o obsoleto come un errore della pipeline che interrompe la promozione all'ambiente successivo.
• Monitora continuamente il drift. Confronta gli hash degli artefatti del modello distribuito con gli hash registrati nell'AIBOM a ogni evento di deployment. Una cadenza guidata dagli eventi è ciò che distingue un record di governance da un documento obsoleto.
• Individua la shadow AI tramite discovery attiva. Identifica le connessioni a endpoint di inferenza IA noti e aggiungi gli asset scoperti all'AIBOM con una classificazione esplicita del rischio non governato.

Queste pratiche trasformano il tuo AIBOM da artefatto di audit a record vivo. Eseguirle su scala cloud richiede strumenti adeguati, ed è qui che entra in gioco AI Security Posture Management di SentinelOne.

Migliora la governance dell'AIBOM con SentinelOne

Un AIBOM è valido solo quanto la discovery che lo alimenta. Singularity Cloud Security, la Cloud-Native Application Protection Platform di SentinelOne, costruisce e mantiene un AIBOM negli ambienti cloud tramite la sua funzionalità AI Security Posture Management (AI-SPM), con Data Security Posture Management (DSPM) integrato per il livello dati.

• Discovery che popola l'inventario. AI-SPM individua le pipeline IA, i modelli ML e le dipendenze in esecuzione nel tuo ambiente, inclusi i job su servizi come Amazon SageMaker. Poiché copre sia l'IA approvata sia la shadow AI, ogni componente che enumera diventa una potenziale voce AIBOM senza punti ciechi silenziosi.
• Contesto di rischio sopra il record. I controlli di configurazione e Verified Exploit Paths mostrano quali componenti catalogati sono configurati in modo errato o sfruttabili, e DSPM mantiene i dati ad alto rischio fuori dalle pipeline IA tramite un controllo safe-to-train. Prompt Security ispeziona prompt e risposte e governa l'IA agentica, estendendo la governance del tuo AIBOM al livello di runtime.
• Convalida su tutta la piattaforma. La Singularity Platform unifica la telemetria di endpoint, cloud e identità in un unico data lake, così puoi confermare che l'ambiente distribuito corrisponda ancora al tuo AIBOM. Quando si verifica drift, Purple AI interviene come analista in linguaggio naturale che indaga autonomamente sugli stessi dati. Secondo IDC, i clienti di Purple AI hanno registrato un'identificazione delle minacce più rapida del 63% e una riduzione del 55% del mean time to respond (MTTR). 

Prenota una demo di SentinelOne per valutare il rischio della tua supply chain IA e costruire un programma di governance dell'IA difendibile nei tuoi ambienti cloud.

Punti chiave

Un AIBOM inventaria i dataset, i modelli, i framework e le dipendenze alla base di un sistema di IA e registra da dove proviene ciascun componente. Estende la pratica consolidata dello SBOM agli asset specifici dell'IA come dati di addestramento, pesi del modello e provenienza del modello. 

Gli standard di NIST, OWASP CycloneDX, SPDX e G7 definiscono ciò che registra un AIBOM. L'inventario è importante per sicurezza, conformità e verificabilità, ma richiede discovery autonoma, formati machine-readable, acquisizione della provenienza e integrazione CI/CD per restare accurato mentre i modelli cambiano. Se implementato correttamente, l'AIBOM smette di essere burocrazia e diventa un controllo su cui puoi agire.

FAQ

Che cos'è un AI Bill of Materials?

Una distinta base dell'AI, o AIBOM, è un inventario leggibile da macchina dei componenti di un sistema di AI: i suoi set di dati, modelli, framework, dipendenze software e metadati come provenienza e licenze. Il suo scopo è operativo.

Quando si scopre che un modello è compromesso o si dimostra che un set di dati è avvelenato, l'AIBOM è ciò che consente di rispondere, con evidenze, quali dei propri sistemi contengono quel componente e quando vi è entrato. Senza di esso, quella risposta diventa un'attività di ricostruzione sotto pressione temporale.

È possibile creare un AIBOM per un modello chiuso o di terze parti?

In parte. Per un modello di base chiuso raggiunto tramite un'API di inferenza, non è possibile registrare la composizione interna completa, perché il fornitore non divulga i dati di addestramento o i pesi. È comunque possibile acquisire e fissare ciò che è conoscibile: nome del modello, versione, endpoint API, controlli di accesso ed eventuali attestazioni del fornitore. 

Registrali come una voce AIBOM di primo livello e contrassegna esplicitamente i campi non divulgati, in modo che l'inventario mostri dove termina la trasparenza e non lasci alcun vuoto implicito.

Che cosa dovrebbe includere un AIBOM?

Le linee guida di maggio 2026 del G7 organizzano il contenuto dell'AIBOM in sette cluster: metadati, proprietà del software a livello di sistema, identità del modello e provenienza dei pesi, proprietà del dataset, indicatori chiave di prestazione, documentazione dell'infrastruttura e struttura del documento con registri della cadenza di aggiornamento. 

Nel loro insieme, questi cluster documentano come è stato costruito un sistema di IA, su cosa viene eseguito e come l'inventario cambia nel corso del ciclo di vita.

Quali standard si applicano agli AIBOM?

Quattro standard e framework ancorano l'attuale pratica AIBOM. Il NIST AI Risk Management Framework definisce aspettative di governance e tracciabilità. OWASP CycloneDX ML-BOM e SPDX 3.0 AI profiles, uno standard ISO/IEC, forniscono specifiche di formato leggibili dalla macchina per modelli e set di dati. 

Gli elementi minimi dell'SBOM del CISA e le linee guida a sette cluster del G7 definiscono ciò che la trasparenza dei sistemi di IA dovrebbe includere. Insieme, estendono gli approcci SBOM consolidati ai modelli di inventario dell'IA.

Come si mantiene aggiornato un AIBOM man mano che i modelli cambiano?

Tratta l'AIBOM come un record guidato dagli eventi collegato alla tua pipeline ML. Attiva gli aggiornamenti alla creazione degli artefatti di addestramento del modello, agli eventi di push nel registry, al riaddestramento, al fine-tuning e alle modifiche della configurazione di distribuzione. Confronta gli hash dei modelli distribuiti con gli hash registrati e genera avvisi su nuovi endpoint di inferenza o voci del registry senza un record AIBOM corrispondente.

Gli strumenti di AI security posture management possono eseguire questi controlli in modo continuo e segnalare la deriva nel momento in cui si verifica. Quando la generazione è un passaggio CI/CD obbligatorio, gli inventari obsoleti bloccano la promozione prima che un modello non governato raggiunga la produzione.