An AI bill of materials lists the models, datasets and configurations an AI system depends on, the way an SBOM lists code libraries. The practical version is a file generated in your build that names each model with its source and version, each dataset with provenance, and the framework that runs them.
What belongs in the file?
The CycloneDX ML-BOM description is a useful scope guide. It covers models, datasets and AI framework configuration, plus dataset provenance and ethical considerations. In engineering terms, record:
- Model: name, version or hash, where it was obtained, license, and whether you fine-tuned it.
- Dataset: source, collection method, date, and any known restrictions on use.
- Runtime and framework: the libraries that load and serve the model, as normal components.
- Configuration: prompts, tool lists and guardrail settings that change behavior.
- Owners: a human responsible for each entry.
Keep the AI entries in the same document as your software components so one inventory answers both questions.
Where does it go stale?
Models change underneath you. A hosted model alias can point to a new version without a deploy. A fine-tune produces a new artifact that nobody registers. A prompt edited in a config store alters behavior with no commit. Each of these breaks the claim that the file describes what is running.
Treat the three as release events. A new model hash, a new dataset snapshot and a changed system prompt should each produce a new version of the bill.
How do you generate it?
Do not write it by hand. Emit it from the pipeline step that already knows what is deployed: the build that pulls model files, the training job that reads datasets, and the deploy step that sets configuration. Store the output with the release artifact and sign it if your process supports signing.
For vendor-hosted models you cannot hash the weights. Record the provider, the model identifier you requested and the date, and note that provider-side changes are outside your control.
How to check or apply this
- Inventory every place a model is called, including scripts and notebooks.
- For each, record source, version or hash, and license.
- Record dataset provenance for anything you train or fine-tune on.
- Add prompts and tool lists as configuration entries.
- Generate the file in CI and attach it to each release.
- Review diffs between releases and ask who approved each model change.
- Name an owner per entry and re-check quarterly.
A dependency scan of the code side feeds the same inventory. Safeguard's SBOM and dependency scanning covers the component side, and Gold's free scan at gold.safeguard.sh/scan checks up to 100 dependencies in the browser.
How does this relate to other frameworks?
If your organization also tracks other frameworks, the AIBOM is a shared input. The NIST AI RMF asks you to map and measure AI risk, and you cannot map what you have not inventoried. The EU AI Act expects technical documentation and data governance for high-risk systems, which dataset provenance helps support. Neither framework prescribes the CycloneDX format, so treat the format as a convenience, not a requirement.
A small constructed example
Suppose a support assistant uses a hosted model, a retrieval index built from help articles, and a system prompt with three tools. The bill lists the provider and requested model identifier, the index as a dataset with its build date and source folders, the vector library as a normal component, and the prompt and tool list as configuration entries. When someone adds a fourth tool, the configuration version changes and the diff shows who approved it. That single diff answers the question an incident reviewer asks first: what could the assistant do on the day it misbehaved?
Quick check
Is an AIBOM the same as an SBOM?
No. An SBOM covers software components. An AIBOM adds models, datasets and AI configuration, ideally in the same document.
What if the model is hosted by a provider?
Record the provider, requested model identifier and date, and note that you cannot verify the weights yourself.
Sources
Last reviewed: 18 October 2026.
