What is the AI BOM (AI Bill of Materials)?

The AI BOM (AI Bill of Materials) is the structured, machine readable inventory of every component that makes up an AI system before it goes into production: which models were used, which datasets they were trained on, which weights were shipped, under what license, and which software dependencies come with them. It is the natural extension of the SBOM already required by the Cyber Resilience Act for traditional software, applied to an artifact of a different nature: a machine learning model is not a library you can open and read line by line to see what it does. It is the product of a training process run on data that, in most cases, stays opaque to whoever adopts the model later. Two technical standards are shaping the format today: CycloneDX, which from version 1.5 describes machine learning models with training datasets and model cards, and SPDX 3.0, which introduced formal profiles for AI and dataset components.

What it contains and why a model is not ordinary software

A complete AI BOM lists the base model used (with version and provenance), the training datasets declared by the vendor, the distributed weights and their license, any fine-tuning parameters applied internally, and the dependencies of the inference libraries. The real difference from a software SBOM lies in inspectability: a library's source code can be read, a training dataset cannot. A vendor can declare the composition of the data used, but rarely allows an independent line-by-line check the way a software package does. That makes the declared documentation, the model card, the real starting point of due diligence, not a secondary detail.

An enterprise example

A company evaluating whether to integrate an open-weight model into production, say for text generation or classifying internal documents, needs to answer a few precise questions before adopting it. Under what license are the weights distributed, and does that license allow commercial use in this context? Which training datasets were declared, and do they include copyrighted content or personal data? Which software dependencies ship with the model, and do any of them carry known vulnerabilities? Without a structured AI BOM, these answers stay scattered across vendor documentation pages, repositories and changelogs, with the real risk of discovering a licensing problem after the model is already in production, not before.

The AI BOM is complementary to, not overlapping with, the traceability that data lineage provides: lineage follows how a piece of data moves and transforms inside internal pipelines, the AI BOM captures the composition of a model at the moment it is adopted as an external artifact.

Why it matters for decision makers

For whoever decides whether to integrate a third-party model, the AI BOM turns a vague question, what is actually inside this model, into a checklist that can be verified before signing a contract or shipping the first production deploy. It is not today a distinct regulatory obligation the way the Cyber Resilience Act's SBOM is, but an emerging technical practice backed by concrete standards: a company that adopts it early reduces the legal and operational risk of finding out, downstream, that the model it integrated was not what it seemed.