Che cos'è un AI-BOM? L'inventario dell'IA che l'AI Act europeo dà per scontato tu abbia già

Che cos'è un AI-BOM?

Un AI-BOM, o AI Bill of Materials, è un inventario leggibile dalle macchine di tutti i componenti di intelligenza artificiale contenuti in un sistema software, insieme ai fatti di provenienza e di governance su ciascuno di essi. Dove un SBOM elenca pacchetti, versioni e licenze, un AI-BOM elenca modelli, dataset, prompt, agenti, strumenti e guardrail, e registra da dove viene ciascuno, cosa gli è consentito fare e in quale classe di rischio normativo ricade.

L'idea discende direttamente dall'inventario del software. L'ordine esecutivo statunitense 14028 ha reso l'SBOM una condizione degli acquisti federali di software nel 2021, e la pratica è sopravvissuta alle vicissitudini politiche di quell'ordine perché si è rivelata l'unica risposta praticabile a «cosa sta realmente girando qui». I sistemi di IA pongono la stessa domanda su una superficie più ampia. Una dipendenza ha una versione e una licenza. Un modello ha una versione, una licenza, un fornitore, pesi che possono essere locali o remoti, un corpus di addestramento che potresti non controllare, una storia di fine-tuning, una configurazione di inferenza, un registro di valutazione e un perimetro di capacità. Nulla di tutto ciò sta in un package.json.

AI-BOM e SBOM: qual è la differenza?

Rispondono a domande diverse sullo stesso repository, e la differenza non è cosmetica. Un SBOM è un elenco di cose che hai installato. Un AI-BOM è un elenco di cose che prendono decisioni.

L'ultima riga è dove la maggior parte degli strumenti si ferma. Una dipendenza si dichiara in un lockfile. Un modello no. openai/gpt-4o-mini compare come stringa letterale in un file di servizio. Un modello locale compare come percorso .gguf in una configurazione. Un server MCP compare come URL in .mcp.json. Un prompt compare come file markdown che nessuno ha registrato da nessuna parte. Non c'è alcun manifest da analizzare, quindi un inventario di IA va derivato leggendo il codice stesso.

Cosa richiede davvero l'AI Act europeo?

L'articolo 11 impone ai fornitori di sistemi di IA ad alto rischio di redigere la documentazione tecnica prima che il sistema sia immesso sul mercato o messo in servizio, e di tenerla aggiornata. L'allegato IV ne fissa il contenuto minimo. L'articolo 18 impone al fornitore di conservare quella documentazione, insieme ai registri del sistema di gestione della qualità e alla dichiarazione di conformità UE, per dieci anni dopo l'immissione sul mercato.

Leggi l'allegato IV come un questionario e la sua forma diventa evidente. Sono nove sezioni, e la maggior parte di esse è fatta di domande su di cosa è fatto il sistema e da dove vengono quei pezzi.

Punto per punto, la corrispondenza è abbastanza stretta perché il compito documentale diventi un problema di esportazione per gran parte del fascicolo, e un vero lavoro di analisi per il resto.

Due sezioni di quella tabella sono contrassegnate come non coperte nativamente da alcun formato di inventario, e sono proprio le due che consumano più tempo di audit nella pratica: l'accuratezza per sottogruppo (§3) e la progettazione della supervisione umana (§2(e)). Nessuno standard di BOM ha un campo per «chi può annullare questa decisione, tramite quale interfaccia, con quale formazione». Un AI-BOM ti dà la composizione. Non ti dà la valutazione. Chi ti vende il contrario ti sta vendendo un foglio di calcolo con un nome nuovo.

Cosa è cambiato nel 2026 e cosa no

L'AI Omnibus è entrato in vigore il 27 luglio 2026, dopo l'adozione da parte del Parlamento europeo il 16 giugno e del Consiglio il 29 giugno. È una semplificazione mirata dell'AI Act più che una riscrittura, e il titolo è un rinvio.

L'Omnibus ha anche creato una categoria di «piccola impresa a media capitalizzazione», definita da meno di 750 dipendenti e un fatturato pari o inferiore a 150 milioni di euro, e le ha esteso i modelli semplificati di documentazione tecnica e i requisiti proporzionati di gestione della qualità prima riservati alle PMI. Non ha toccato il contenuto dell'allegato IV. L'elenco delle cose che devi essere in grado di dire sul tuo sistema è lo stesso del 2024.

Altre due modifiche dell'Omnibus contano nello specifico per il lavoro documentale. L'articolo 10(5) fornisce ora una base giuridica più chiara per trattare dati personali di categorie particolari quando ciò sia strettamente necessario per rilevare e mitigare i bias, con adeguate garanzie, il che spezza un vero circolo vizioso: i team non potevano misurare l'accuratezza per sottogruppo perché non era loro consentito raccogliere l'attributo che avrebbe permesso di misurarla. E l'articolo 40(2) obbliga la Commissione a richiedere norme unificate che coprano congiuntamente l'AI Act e la legislazione di armonizzazione esistente, in modo che un unico prodotto non debba soddisfare due regimi documentali paralleli.

Perché è proprio l'inventario a fallire?

Perché i componenti di IA entrano in un repository attraverso canali che non erano stati pensati per essere inventariati, e ora vi entrano più in fretta di qualsiasi cadenza di revisione.

La versione misurata è netta. Il Cost of a Data Breach Report 2026 di IBM, condotto dal Ponemon Institute su 602 organizzazioni violate tra marzo 2025 e febbraio 2026, ha rilevato che la quota di incidenti di sicurezza con shadow AI coinvolta è più che raddoppiata su base annua.

La shadow AI viene di solito presentata come un problema di dipendenti: qualcuno incolla dati dei clienti in un chatbot di consumo. Quell'inquadramento la sottostima gravemente. La versione più ampia e silenziosa è la shadow AI nel repository. Una stringa di modello aggiunta a un servizio. Un dataset HuggingFace tirato dentro un notebook. Un server MCP puntato su un database di produzione per una sessione di debug e mai rimosso. Un file di prompt modificato per allentare un vincolo. Ciascuno è una modifica di una riga. Ciascuno cambia ciò che il sistema è, e quindi ciò che la sua documentazione dell'allegato IV dovrebbe dire. Nessuno si annuncia.

È il terzo passaggio a essere cambiato da quando l'AI Act è stato redatto. Quando un ingegnere umano sceglieva un modello, c'era una decisione, di solito una conversazione, a volte un documento di progettazione. Quando un agente di coding scrive l'integrazione, seleziona un modello, una libreria client e una configurazione predefinita in un'unica modifica, e la traccia di quella decisione è un diff che nessuno legge riga per riga. Abbiamo descritto la forma generale di questo problema in perché la maggior parte dei risultati SAST è rumore e in falle di logica di business nel codice generato dall'IA; il caso dell'AI-BOM è la versione di governance dello stesso disallineamento di cadenza.

“

Un inventario tenuto come documento descrive il giorno in cui è stato scritto. Un inventario derivato dal codice descrive oggi. Solo uno dei due sopravvive a un audit che arriva diciotto mesi dopo l'ultima riunione di revisione.

Cosa deve intercettare un inventario di IA?

Sei categorie, e ognuna è un luogo in cui si decide la composizione del sistema. Se ne manca una, il fascicolo dell'allegato IV ha un buco che un auditor troverà leggendo il codice che tu stesso hai consegnato come prova.

Quale formato di AI-BOM conviene usare?

CycloneDX è la scelta predefinita più pragmatica. Supporta i modelli di machine learning dalla versione 1.5 del 2023, la specifica attuale è la 1.7 (pubblicata il 21 ottobre 2025) ed è normata come ECMA-424, quindi è uno standard vero e non uno schema proprietario. SPDX 3.0 offre un'alternativa allineata a ISO tramite il suo AI Profile. Entrambi sono serializzabili in JSON, entrambi si inseriscono nelle pipeline SBOM esistenti ed entrambi sono supportati da strumenti aperti.

Un componente ML-BOM CycloneDX minimo si presenta così.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "pkg:huggingface/mistralai/Mistral-7B-Instruct-v0.3",
      "name": "support-triage-v4",
      "version": "2026-06-11",
      "modelCard": {
        "modelParameters": {
          "approach": { "type": "supervised" },
          "architectureFamily": "Transformer (Mistral-7B, fine-tuned)",
          "datasets": [
            { "ref": "urn:cdx:dataset-support-tickets-2025h2", "type": "training" }
          ]
        },
        "quantitativeAnalysis": {
          "performanceMetrics": [
            { "type": "accuracy", "value": "0.881", "slice": "all locales" }
          ]
        },
        "considerations": {
          "useCases": ["tier-1 support triage"],
          "technicalLimitations": ["degrades below 0.72 on locales unseen in training"]
        }
      }
    }
  ]
}

Questo copre l'allegato IV §1, §2(b), §2(c), §2(d) e parte del §2(g) in un solo oggetto. Ciò che non copre, e che quindi porterai come proprietà personalizzate o come documenti separati, si raggruppa in tre blocchi.

Accanto al formato c'è il livello di reporting. Il NIST AI Risk Management Framework (AI 100-1) organizza il lavoro sul rischio IA in Govern, Map, Measure e Manage, e la sua funzione Map è vicina a una definizione del compito di inventario: documentare contesto, componenti, capacità e limiti del sistema. La ISO/IEC 42001 richiede un sistema di gestione dell'IA che ha al centro un inventario di IA e una valutazione dei rischi. Nessuno dei due è un formato. Entrambi consumano gli stessi fatti sottostanti, il che è l'argomento pratico per produrre quei fatti una volta sola, meccanicamente, e proiettarli poi nel quadro che parla ciascun auditor o ciascun questionario di sicurezza cliente.

Come si costruisce un AI-BOM che resti veritiero?

La modalità di fallimento di ogni inventario di governance è identica, e non ha nulla a che vedere con lo sforzo iniziale. Qualcuno avvia un esercizio di discovery, intervista i team, riempie un foglio di calcolo, e l'artefatto è accurato per circa una settimana. Ciò che segue non è pigrizia; è aritmetica. I componenti cambiano più in fretta dei cicli di revisione.

Quindi il vincolo di progettazione viene per primo, e i passi ne discendono.

1. Deriva l'inventario dal codice, mai da un questionario. Un questionario cattura ciò che le persone ricordano. Una scansione cattura ciò che è stato rilasciato. I due divergono immediatamente, e solo uno dei due è ciò che un auditor leggerà.

2. Ancora ogni componente a un file e a una riga. Una voce di inventario senza posizione sorgente è un'affermazione. Una voce con accanto src/lib/triage.ts:23 è una prova, ed è anche ciò che rende la remediation assegnabile a un team invece che a un comitato.

3. Classifica a livello di componente, non di sistema. Gli articoli 5, 6 e 50 si applicano a ciò che fa un componente. Uno stesso repository contiene abitualmente un assistente di chat a rischio minimo, un assistente rivolto al cliente a rischio limitato e un modello di scoring genuinamente ad alto rischio. Un'unica etichetta a livello di sistema nasconde proprio il componente che conta.

4. Segnala lo stato, non solo la presenza. Governato, shadow, derivato, mancante. Un componente con model card e licenza è un oggetto diverso dallo stesso componente senza né l'una né l'altra, e tutto il valore di una prima scansione sta nel rapporto tra queste due pile.

5. Rigenera a ogni push e fanne il diff. L'allegato IV §6 chiede le modifiche apportate al sistema nel corso della sua vita. Se l'inventario è rigenerato a ogni commit, quella sezione si scrive da sola; il diff è il registro delle modifiche. Se è rigenerato ogni trimestre, qualcuno dovrà ricostruirlo a memoria.

6. Blocca la pipeline su ogni nuovo componente non governato. Una build che fallisce quando atterra un componente vietato o ad alto rischio senza documentazione è l'unico controllo che impedisce al rapporto del punto 4 di derivare. Tutto ciò che è più morbido di un blocco degenera in una dashboard che nessuno apre.

7. Metti a contratto ciò che non puoi scansionare. La tua scansione vede ciò che contiene il tuo repository. Non vede il corpus di addestramento di un fornitore. Gli articoli 25(2) e 25(4) pongono l'obbligo di cooperazione in capo al fornitore a monte, quindi mettilo anche nel contratto: model card, sintesi dei dati di addestramento e notifica quando una versione di modello cambia sotto i tuoi piedi.

8. Conservalo dieci anni. L'articolo 18 è esplicito, e dieci anni sono più della maggior parte delle politiche di conservazione degli artefatti, più della conservazione predefinita della maggior parte dei provider di CI, e parecchio più della permanenza media dell'ingegnere che ha costruito il sistema. Esporta il fascicolo su un supporto duraturo.

Come CybeDefend genera l'AI-BOM

Tutto quanto precede è il caso generale. Ecco come lo implementiamo, perché il vincolo di progettazione della sezione precedente è esattamente quello per cui abbiamo costruito.

Lo scanner AI-BOM di CybeDefend attraversa un repository e cataloga le sei categorie direttamente dal codice: modelli (stringhe ospitate, identificatori HuggingFace, pesi locali .gguf e .onnx), dataset richiamati nel codice o nelle configurazioni, prompt versionati, framework di agenti e orchestrazione, i server MCP che i tuoi agenti consumano e le librerie di guardrail in uso. Ogni elemento atterra con il suo file sorgente e la sua riga, la sua versione fissata e uno stato: governato, shadow, deriva o mancante. Nessun questionario, nessun giro di interviste.

Una scansione emette poi tre artefatti in ./.ai-bom/, ed è questa la parte che conta per il lavoro descritto sopra.

Il primo è un rapporto di conformità all'AI Act mappato sul regolamento (UE) 2024/1689, con ogni componente ordinato in rischio vietato, alto, limitato o minimo ai sensi degli articoli 5, 6 e 50, i componenti GPAI contati a parte e i componenti a rischio sistemico segnalati. Il secondo è una mappatura di copertura NIST AI RMF su Govern, Map, Measure e Manage, con le lacune nominate anziché annegate in una media. Il terzo è l'AI-BOM CycloneDX leggibile dalle macchine, perché l'inventario si inserisca negli strumenti SBOM che già usi.

Gira dove rilasci. Aggiungi la cybedefend-action a un workflow GitHub, oppure richiama la CLI CybeDefend da GitLab CI, da un Jenkinsfile o da Tekton, e la scansione viene eseguita a ogni push con il rapporto pubblicato come artefatto di build.

- name: CybeDefend Security Scan
  uses: CybeDefend/cybedefend-action@v2
  with:
    pat: ${{ secrets.CYBEDEFEND_PAT }}
    project_id: ${{ secrets.CYBEDEFEND_PROJECT_ID }}
    branch: ${{ github.ref_name }}
    break_on_severity: high

Sono i punti 5 e 6 dell'elenco qui sopra, implementati: l'inventario si rigenera a ogni commit, quindi l'allegato IV §6 diventa un diff, e la build esce con errore quando un nuovo componente vietato o ad alto rischio atterra senza documentazione di governance. La scansione legge il tuo repository e produce un inventario strutturato; il codice sorgente non lascia il tuo ambiente, e la dashboard riceve soltanto metadati sui componenti, mai codice grezzo né contenuto dei prompt.

L'AI-BOM sta accanto al resto della piattaforma e non dentro il ciclo dell'agente. È uno scanner di repository e di pipeline, che è il posto giusto per un inventario: gli serve l'intero albero, non la modifica in corso. Ciò che gira dentro il ciclo dell'agente è VibeDefend, che carica le tue regole di business e di sicurezza nell'agente prima che scriva, intercetta le azioni non sicure e mantiene vivi nel contesto dell'agente i risultati di SAST, SCA, segreti, IaC e CI/CD. I due sono complementari. VibeDefend governa ciò che l'agente fa mentre scrive; l'AI-BOM registra ciò che il repository è diventato.

Domande frequenti

Che cos'è un AI-BOM?

Un AI-BOM, o AI Bill of Materials, è un inventario leggibile dalle macchine di tutti i componenti di IA di un sistema: modelli, dataset, prompt, agenti e framework di orchestrazione, gli strumenti e i server MCP che quegli agenti richiamano e i guardrail applicati loro. Ogni voce porta con sé fatti di provenienza e governance: fornitore, versione, licenza, origine dei dati, ampiezza delle capacità e classificazione di rischio. Estende il concetto di SBOM dai pacchetti software agli asset di IA, ed è la prova sottostante della documentazione tecnica dell'articolo 11 e dell'allegato IV dell'AI Act, del reporting NIST AI RMF e degli inventari di IA della ISO/IEC 42001.

Qual è la differenza tra un AI-BOM e un SBOM?

Un SBOM elenca componenti software (pacchetti, versioni, licenze) e serve soprattutto a trovare vulnerabilità note. Un AI-BOM elenca componenti di IA e le loro dimensioni di governance specifiche dell'IA: origine dei dati di addestramento, lignaggio del fine-tuning, versioni dei prompt, ampiezza delle capacità degli agenti, copertura dei guardrail e rischio residuo. Sono complementari più che concorrenti, e CycloneDX sa esprimere entrambi, quindi un AI-BOM può essere prodotto nello stesso formato e nella stessa pipeline del tuo SBOM attuale.

L'AI Act europeo impone un AI-BOM?

Non con quel nome. L'AI Act non usa mai il termine. L'articolo 11 impone ai fornitori di sistemi di IA ad alto rischio di redigere la documentazione tecnica prima dell'immissione sul mercato e di tenerla aggiornata, e l'allegato IV ne fissa il contenuto minimo: descrizione generale, specifiche di progettazione, architettura, requisiti e provenienza dei dati, supervisione umana, validazione e test, cibersicurezza, capacità e limiti, gestione dei rischi, modifiche del ciclo di vita e monitoraggio post-commercializzazione. Un AI-BOM è il modo pratico per produrre meccanicamente gran parte di quel fascicolo. L'articolo 18 impone poi di conservare la documentazione per dieci anni dopo l'immissione sul mercato.

L'AI Omnibus ha eliminato l'obbligo di documentazione tecnica?

No. L'AI Omnibus è entrato in vigore il 27 luglio 2026 e ha rinviato gli obblighi ad alto rischio dei sistemi autonomi dell'allegato III dal 2 agosto 2026 al 2 dicembre 2027, e quelli dell'IA ad alto rischio integrata in prodotti regolamentati dal 2 agosto 2027 al 2 agosto 2028. Ha inoltre creato una categoria di «piccola impresa a media capitalizzazione» (meno di 750 dipendenti, fatturato pari o inferiore a 150 milioni di euro) che può usare modelli semplificati di documentazione tecnica. Il contenuto dell'allegato IV non è cambiato, gli obblighi di trasparenza dell'articolo 50 sono rimasti alla data originaria, e gli obblighi GPAI si applicano dal 2 agosto 2025, con i poteri di esecuzione della Commissione attivi dal 2 agosto 2026.

Quale formato dovrebbe usare un AI-BOM, CycloneDX o SPDX?

CycloneDX è la scelta pragmatica predefinita. Supporta i modelli di machine learning dalla versione 1.5 (2023), la specifica attuale è la 1.7 (ottobre 2025) ed è normata come ECMA-424, con i campi modelCard, modelParameters, i riferimenti ai dataset e quantitativeAnalysis che coprono gran parte dei fatti di composizione. L'AI Profile di SPDX 3.0 è l'alternativa allineata a ISO ed è una scelta ragionevole se la tua organizzazione già standardizza su SPDX. Nessuno dei due ha campi nativi per la metodologia di valutazione dei bias né per la progettazione della supervisione umana, quindi in entrambi i casi quelli vengono portati come proprietà personalizzate o documenti collegati.

Sono io il fornitore se ho solo messo a punto il modello di qualcun altro?

Di norma sì. L'articolo 25(1) considera fornitore di un sistema di IA ad alto rischio chi lo immette sul mercato con il proprio nome o marchio, chi lo modifica sostanzialmente o chi ne cambia la finalità prevista in modo che diventi ad alto rischio. Mettere a punto un modello esistente sui propri dati e distribuirlo con il nome del proprio prodotto attiva tipicamente tutte e tre le condizioni. La model card del laboratorio d'origine documenta soltanto il modello di base; l'obbligo documentale dell'articolo 11 per il tuo sistema ricade su di te, e gli articoli 25(2) e 25(4) obbligano il fornitore a monte a cooperare e a fornire informazioni, non a redigere il tuo fascicolo.

Come si trova la shadow AI in un repository?

Scansionando il codice invece di intervistare i team. I componenti di IA raramente si dichiarano in un manifest: un modello ospitato compare come stringa letterale, un modello locale come percorso dei pesi in una configurazione, un dataset come URI in un notebook, un server MCP come URL nella configurazione di un agente, un prompt come file markdown non tracciato. Una scansione del repository risolve ciascuno di essi in un componente con file e riga, poi segnala quelli privi di model card, licenza, versione fissata e responsabile registrato. Il Cost of a Data Breach Report 2026 di IBM ha rilevato shadow AI coinvolta nel 43% degli incidenti di sicurezza e più di due terzi delle organizzazioni senza processo di governance per limitarla, quindi l'aspettativa ragionevole per una prima scansione è che la pila shadow sia più grande di quella governata.

Ogni quanto va rigenerato un AI-BOM?

A ogni push. L'allegato IV §6 chiede le modifiche apportate al sistema nel corso della sua vita, e un inventario per commit trasforma quella sezione in un diff invece che in un esercizio di ricostruzione. Un inventario trimestrale è obsoleto nel giro di giorni in qualsiasi repository in cui gli agenti di coding scrivono le integrazioni, perché un cambio di modello, un nuovo permesso su uno strumento o una modifica di prompt è un commit di una riga. Rigenerare in CI e far fallire la build quando atterra un nuovo componente ad alto rischio o vietato senza documentazione è ciò che tiene l'artefatto e il repository allineati.