How to Build an AIBOM (AI Bill of Materials)
TL;DR · the short version
An AIBOM (AI Bill of Materials) is a structured inventory of everything that makes up an AI system: the models used and their provenance, the training and fine-tuning data, the software dependencies around them, and the licences attached to each. Building one is a repeatable process: inventory the models (name, version, source, licence, integrity hash), inventory the data (sources, licences, sensitivity), capture the surrounding software as an SBOM, record provenance and integrity, and express the whole thing in a machine-readable format such as CycloneDX or SPDX so it can be shared and checked automatically. This guide walks through each step and what "good" looks like.
"How do I build an AIBOM?" is the practical follow-up to understanding what one is. An AI Bill of Materials is just a structured inventory of everything your AI system is made of — models, data, software and their licences — but building a useful one means being disciplined about what you capture and expressing it in a format a machine can check. Here is the process.
Step 1 — Inventory the models
For every model in the system, record: name, version, source or publisher, licence, and an integrity hash or signature. This is the core of an AIBOM and the part a plain SBOM misses — you need to be able to answer "which model, from where, under what licence, and can we prove it hasn't been tampered with?" For a fine-tune, record the base model too; AIBOM identity, provenance and lineage shows how.
Step 2 — Inventory the data
Capture the training and fine-tuning datasets: source, licence, and sensitivity (does it contain PII or regulated data?). Data provenance is where a lot of AI legal and privacy risk lives, so even a partial record is valuable. This model-and-data core is also what an ML-BOM (machine learning bill of materials) captures in its own right. The AIBOM data section covers datasets, licensing and sensitive data in detail.
Step 3 — Capture the surrounding software (SBOM)
An AI system is still software. Generate an SBOM for the libraries and dependencies around the model so the AIBOM covers the conventional supply chain too — vulnerable dependencies are still one of the most common real-world risks.
Step 4 — Record provenance and integrity
Document where each component came from and how it was obtained, and attach hashes or signatures so integrity can be verified. This is what turns an inventory into a trust artifact. Sign a model and attach provenance works through it end to end.
Step 5 — Use a machine-readable format
Express the AIBOM in CycloneDX or SPDX — both support or are extending to AI/ML components — so it can be generated in your pipeline and validated automatically for banned licences, unknown provenance or known-vulnerable components. A static spreadsheet cannot do that. To see what a finished file looks like, read CycloneDX ML-BOM: fields and a worked example.
Step 6 — Keep it current
Generate the AIBOM in your build/release pipeline so it matches what is actually deployed, and regenerate it on any model, data or dependency change. A stale AIBOM creates false confidence.
Generate and inspect one now with the AIBOM generator →, start from a structure with the AIBOM template, and see how it differs from related inventories in SBOM vs AIBOM vs MLBOM.
Frequently asked questions
What is an AIBOM? A machine-readable inventory of an AI system's models, data, software and licences — an SBOM extended to AI-specific components.
What should it include? Models (name, version, source, licence, hash), datasets (source, licence, sensitivity), software dependencies, and provenance.
What format? CycloneDX or SPDX, so it can be generated and validated automatically.
How do I keep it current? Generate it in your pipeline and regenerate on any model/data/dependency change.
Frequently asked questions
What should an AIBOM include?
At minimum: each model (name, version, source/publisher, licence, and an integrity hash or signature); training and fine-tuning datasets (source, licence, and sensitivity/PII status); the surrounding software dependencies (effectively an SBOM); and provenance/lineage information showing where each component came from and how it was obtained. Licences and provenance are the parts that carry the most governance value.
What format should I use for an AIBOM?
Use an established, machine-readable BOM format rather than a document: CycloneDX and SPDX both support (or are extending to support) AI and ML components, so an AIBOM expressed in one of them can be generated, shared and validated with existing tooling. A machine-readable AIBOM is far more useful than a static spreadsheet because it can be checked automatically for banned licences, unknown provenance or known-vulnerable components.
How do I keep an AIBOM up to date?
Generate it as part of your build or release pipeline so it reflects the actual deployed system, and regenerate it whenever a model, dataset or dependency changes. Treat a model swap or a fine-tune as a change that produces a new AIBOM, just as a dependency bump produces a new SBOM. An out-of-date AIBOM is worse than none because it creates false confidence.