AI-BOM: l’AI Bill of Materials per sapere che cosa c’è dentro un modello

L’AI-BOM, sigla di AI Bill of Materials, porta al mondo dei modelli di intelligenza artificiale un’idea già rodata nel software: sapere di che cosa è fatto ciò che si usa. Come la distinta base di un prodotto industriale elenca i suoi componenti, e come il Software Bill of Materials elenca le librerie di cui un programma è composto, l’AI-BOM elenca gli ingredienti di un sistema di intelligenza artificiale: i modelli, i dataset con cui sono stati addestrati, i pesi, le configurazioni, le licenze e la provenienza. È l’inventario di una cosa che, fino a ieri, quasi nessuno inventariava, perché la si trattava come una scatola nera calata dall’alto.

La differenza rispetto al software tradizionale è che qui gli ingredienti sono molto più opachi e molto meno verificabili, e il bisogno di elencarli è cresciuto insieme alla loro diffusione: nel momento in cui le aziende scaricano modelli da repository pubblici e li innestano nei propri prodotti, ereditano rischi che non sanno di avere. L’AI-BOM è la prima mossa per riprenderne il controllo, ma è anche una mossa che risolve meno di quanto sembri, perché con i modelli la parte difficile comincia proprio dove finisce l’elenco.

Che cos’è un AI-BOM

Un AI-BOM, o AI Bill of Materials, è l’inventario strutturato e leggibile dalle macchine dei componenti di un sistema di intelligenza artificiale. Non elenca soltanto il modello, ma la costellazione che lo circonda: i dataset di addestramento e la loro origine, i pesi e la loro versione, l’architettura e gli iperparametri, le licenze d’uso, le metriche dichiarate e i limiti noti, fino alle considerazioni etiche e ai rischi di distorsione. È l’estensione al mondo dell’AI della stessa logica di trasparenza che ha portato il software a dotarsi di distinte dei materiali, applicata però a oggetti fatti non di codice ma di dati e di numeri.

Gli standard esistono già, e non sono nuovi di zecca. CycloneDX, progetto di punta di OWASP oggi sviluppato in seno al comitato tecnico TC54 di Ecma International, ha introdotto il bill of materials per il machine learning con la versione 1.5 del 2023 e lo ha portato dentro uno standard internazionale: la versione 1.7, di ottobre 2025, è stata ratificata come ECMA-424 di seconda edizione, che copre esplicitamente la descrizione dei modelli di machine learning, nella terminologia del progetto l’AI/ML-BOM. Sul fronte parallelo, lo standard SPDX 3.0 del 2024 ha aggiunto profili dedicati all’intelligenza artificiale e ai dataset, pensati proprio per documentare un sistema di AI e i dati che lo alimentano. Come per l’SBOM, quindi, l’AI-BOM non è un formato proprietario ma una grammatica comune, con cui descrivere un modello, generarne l’inventario e scambiarlo lungo la filiera.

Che cosa cambia quando il componente è un modello

Qui però la somiglianza con l’SBOM si ferma, ed è la parte che conta. In un software tradizionale le dipendenze sono librerie di cui, in linea di principio, si può leggere il codice: se un componente è vulnerabile, lo si identifica, lo si ispeziona, lo si aggiorna. Un modello è un’altra cosa. Il suo equivalente del codice sorgente è il dato con cui è stato addestrato, che quasi mai viaggia insieme al modello e spesso non è nemmeno pubblico; e ciò che si scarica, i pesi, è una distesa di miliardi di numeri che nessun essere umano può leggere, ispezionare riga per riga o “diffare” per capire che cosa è cambiato tra due versioni.

La conseguenza è che l’AI-BOM elenca ciò che si possiede, ma non può rivelare ciò che si nasconde nel modello. Una backdoor addestrata dentro i pesi, una distorsione ereditata da un dataset avvelenato, un comportamento indesiderato che emerge solo con certi input non compaiono in nessuna distinta: restano invisibili proprio perché il modello è opaco per costruzione. A questo si aggiunge un problema che il software conosce meno, quello del formato: molti modelli viaggiano in formati di serializzazione, come il pickle di Python, che all’atto del caricamento eseguono codice, trasformando il semplice “aprire un modello” in un potenziale punto di esecuzione. Un formato più sicuro esiste già, il safetensors nato in casa Hugging Face proprio per contenere solo i dati del modello e non codice eseguibile, ma l’ecosistema non lo ha ancora sostituito, e la piattaforma segnala i modelli in pickle come non sicuri senza però bloccarli. La provenienza, poi, non si deduce dal file: un modello scaricato da un repository pubblico non porta con sé la garanzia di essere quello che dichiara di essere. L’inventario è la premessa per porsi queste domande, non la risposta.

La supply chain dei modelli e perché va inventariata

Il motivo per cui tutto questo è diventato urgente è che i modelli hanno una filiera, e quella filiera è già sotto attacco. La maggior parte delle organizzazioni non addestra i propri modelli da zero, ma parte da modelli preaddestrati scaricati da hub pubblici come Hugging Face, esattamente come si attinge a librerie open source. E come nella supply chain del software, chi distribuisce può essere malevolo. All’inizio del 2025 i ricercatori di ReversingLabs hanno documentato su Hugging Face, con una tecnica battezzata nullifAI, due modelli che sfruttavano il formato pickle per eseguire codice al caricamento, confezionati in modo da eludere lo scanner di sicurezza della piattaforma. Gli stessi ricercatori li hanno descritti più come una prova di concetto che come un attacco attivo, ma il punto che conta resta intatto: lo scanner non li aveva visti.

Il caso non è isolato, ed è la punta di un fenomeno più ampio, che va dal caricamento di modelli con nomi ingannevoli, per typosquatting o riuso di namespace, con una logica affine a quella dello slopsquatting nei registri di pacchetti, fino all’avvelenamento dei dati di addestramento e agli attacchi ai modelli veri e propri. E non è nemmeno solo un problema di formato dei pesi: nell’aprile 2026 la vulnerabilità CVE-2026-6859, di gravità elevata e assegnata da Red Hat, ha mostrato che lo script di addestramento del framework open source InstructLab, incluso in Red Hat Enterprise Linux AI, caricava i modelli da Hugging Face con l’opzione trust_remote_code cablata nel codice e non disattivabile dall’utente: bastava indurre qualcuno a lanciare l’addestramento su un modello confezionato ad arte per ottenere esecuzione di codice arbitrario, senza alcun trucco sul pickle. L’SBOM avrebbe intercettato quella falla nel framework, appena pubblicata l’advisory: è il suo mestiere. L’AI-BOM avrebbe elencato il modello, la versione, la fonte. Nessuno dei due, però, dice la cosa che conta, cioè se quel modello, al caricamento, esegue codice. Il rischio non era leggibile in nessuno dei due elenchi presi da soli: stava nell’incontro tra il framework che si fida e il modello di cui non ci si può fidare.

In questo scenario un AI-BOM non è un adempimento burocratico ma un presupposto operativo. Sapere quali modelli sono in uso, in quali prodotti, con quale versione e da quale fonte è la condizione per rispondere a un incidente quando un modello popolare si rivela compromesso, per valutare l’esposizione a una licenza incompatibile, per distinguere ciò che è stato scaricato ieri da una fonte affidabile da ciò che si è sedimentato nei progetti senza che nessuno lo tracciasse. Senza quella mappa, la reazione a un problema nella filiera dei modelli è cieca, esattamente come lo era per il software prima dell’SBOM.

Firma e provenienza: dall’inventario alla fiducia

Un inventario, però, dice che cosa si possiede, non che sia autentico. È la differenza tra avere l’elenco degli ingredienti e avere la garanzia che non siano stati manomessi lungo il tragitto. Per colmarla serve un livello ulteriore, quello della firma crittografica dei modelli, che lega un modello alla sua origine e ne certifica l’integrità. È la strada intrapresa dalla OpenSSF Model Signing, la specifica di firma dei modelli nata nel gruppo di lavoro AI/ML di OpenSSF con il team di sicurezza open source di Google, e portata alla prima versione stabile della libreria insieme a NVIDIA e HiddenLayer, riassunta in un principio elementare: firmare il modello quando lo si addestra e verificarlo ogni volta che lo si usa. La specifica è agnostica rispetto all’infrastruttura di fiducia, cioè non impone un solo metodo ma ammette chiavi diverse, dalle catene di certificati aziendali alla firma senza chiavi basata su identità con Sigstore, ed è già stata integrata in hub come l’NGC di NVIDIA e Kaggle di Google. Trasforma così la provenienza da dichiarazione a proprietà verificabile.

Firma e inventario lavorano insieme e su piani diversi: l’AI-BOM dice di che cosa è fatto un sistema, la firma dice che quel qualcosa è arrivato integro e da chi dice di provenire. L’uno rende la filiera leggibile, l’altra la rende affidabile. Nessuno dei due, da solo, basta: un inventario di componenti non firmati resta una lista di cui fidarsi sulla parola, e una firma senza inventario garantisce l’integrità di qualcosa che non si è mappato.

La spinta normativa

Come per l’SBOM, a rendere concreto l’AI-BOM non è solo la sicurezza ma la conformità. L’AI Act europeo, con gli obblighi per i fornitori di modelli di uso generale entrati in applicazione il 2 agosto 2025, chiede documentazione tecnica dettagliata, informazioni ai fornitori a valle che integrano il modello e, soprattutto, un riassunto pubblico sufficientemente dettagliato dei contenuti usati per l’addestramento, redatto secondo un modello predisposto dall’autorità europea. È la trasparenza sulla filiera dell’AI che diventa requisito, non più cortesia. Con due precisazioni che ne misurano il peso reale, oggi: l’AI Office può farli valere solo dal 2 agosto 2026, e i modelli già sul mercato prima dell’agosto 2025 hanno tempo fino al 2 agosto 2027 per adeguarsi. È un obbligo, dunque, con un lungo periodo di grazia. E nessuna norma impone il formato AI-BOM in quanto tale: impone il risultato, cioè la trasparenza, di cui l’AI-BOM è lo strumento più naturale.

Il quadro, del resto, si è appena mosso: il Digital Omnibus on AI, che emenda l’AI Act ed è stato adottato in via definitiva dal Parlamento europeo il 16 giugno e dal Consiglio il 29 giugno 2026, in vigore dal terzo giorno successivo alla pubblicazione in Gazzetta ufficiale, attesa entro fine luglio, ha rinviato diversi obblighi sui sistemi ad alto rischio, al 2 dicembre 2027 per quelli autonomi dell’Allegato III e al 2 agosto 2028 per l’AI incorporata nei prodotti dell’Allegato I, ma ha lasciato intatti proprio quelli sui modelli di uso generale, che restano sul calendario attuale. La stessa direzione si legge nella pressione che già investe il software, dove il Cyber Resilience Act imporrà dal dicembre 2027 di documentare i componenti in un SBOM leggibile dalle macchine, con l’obbligo di segnalazione delle vulnerabilità che scatta prima, l’11 settembre 2026. È ragionevole attendersi che chi compra software e servizi basati su AI inizi a chiedere l’AI-BOM come oggi chiede l’SBOM, e che la sua assenza diventi, col tempo, un segnale di immaturità più che un dettaglio tecnico.

Cosa aspettarsi, senza illusioni

L’AI-BOM è un passo necessario e, a certe condizioni, persino ovvio: non si può governare, comprare o difendere ciò di cui si ignora la composizione, e portare la disciplina delle distinte dei materiali ai modelli è la naturale estensione di un percorso che il software ha già fatto. Ma va tenuto per ciò che è, non per ciò che non può essere. Non apre la scatola nera: elenca il modello, non ne svela il comportamento nascosto. Il riassunto dei dati di addestramento può essere vago e autodichiarato, la provenienza vale quanto la firma che la sostiene, e gli standard stessi non sono del tutto allineati: la specifica CycloneDX è ormai una norma Ecma e SPDX è alla versione 3.0.1, con la 3.1 in lavorazione, ma lo standard ISO di riferimento, l’ISO/IEC 5962:2021, fotografa ancora SPDX 2.2.1, sicché i profili dedicati all’AI non sono ancora entrati nella norma internazionale. Trattare l’AI-BOM come una prova di sicurezza sarebbe un errore speculare a quello di chi lo ignora: rende la filiera dei modelli leggibile, non sicura. Ed è proprio questa leggibilità, però, il presupposto senza il quale ogni discorso su sicurezza, conformità e fiducia nell’AI resta un’affermazione senza dati a sostegno.