An AI bill of materials records what went into each AI system you build or run: the model, its version and origin, training and fine-tuning data, software dependencies, intended use and known limits. Start with a short, consistent record per model and keep it current. A complete form nobody updates is worse than a small one that is accurate.
Why keep an AIBOM at all?
When a model supplier announces a flaw, a license change or a data problem, you need to know which of your systems use that model. Without a record, the answer comes from asking around.
The same is true for audits and customer questionnaires. A buyer who asks which models touch their data expects an answer in days, not weeks.
Which standards define the format?
Two open formats are the main reference points.
CycloneDX calls its version ML-BOM. Its page describes recording models and their configurations, datasets including origin and ethical considerations, training methods, and AI framework settings and dependencies. It says the information helps assess risks around bias, data integrity and model security, and that an ML-BOM can integrate with other system inventories.
SPDX 3.0 has an AI profile. Its AI package properties include autonomy type, domain, type of model, hyperparameters, metrics and decision thresholds, model data preprocessing, model explainability, information about training and about the application, limitation, safety risk assessment, standard compliance, use of sensitive personal information, and several energy consumption fields.
You do not need to pick a winner today. Record the same facts and export to either later.
What goes in each record?
Group the fields so they are easy to fill in.
Identity:
- Name, version and a content hash of the model files, if you hold them.
- Supplier, source location and license.
- Whether you host it or call it through an API.
Provenance:
- Base model and any fine-tuning, with dates.
- Training and fine-tuning datasets, their source and license, and whether they include personal data.
- Who approved its use.
Software around it:
- Frameworks, runtimes and libraries, ideally as normal SBOM components.
- Prompts, retrieval indexes and the tools it can call.
Use and limits:
- Intended use and out of scope uses.
- Known limitations and evaluation results with the metric used.
- Safety and risk assessment status.
- Where it is deployed and what data flows to it.
For hosted models you may not know the training data. Write that down as unknown rather than leaving it blank. The honest gap is useful to an auditor.
How is it different from an SBOM?
An SBOM lists code components. An AIBOM adds things that code lists miss: weights, data, and behavior. A model can be the same file and behave differently after a fine-tune, and a dataset change can matter more than a library upgrade.
Keep both linked. The AIBOM entry should point to the SBOM of the service that runs the model.
How do you keep it from going stale?
Tie updates to events you already have. A new model version in the registry, a new fine-tune job, or a change in a prompt template should each touch the record. Assign an owner per model, and review the list quarterly for models that are no longer used.
Discovery helps too. Search code and configuration for model names and API endpoints, because teams adopt models faster than they file paperwork.
What to do
- List every model in use, including hosted APIs and models inside third party tools.
- Pick the field groups above and cut them to what you can fill honestly.
- Name an owner for each model.
- Link each entry to the service SBOM and the data flow.
- Export in CycloneDX or SPDX so partners can read it.
- Add record updates to your model release checklist.
- Review quarterly and retire stale entries.
Quick check
Do I need an AIBOM if I only call a hosted model API?
Yes, a short one. Record the provider, model name and version, the data you send, and the prompts and tools around it. You still need to know what to change when the provider changes something.
Is an AIBOM a regulatory requirement?
This post does not claim that. Regulations and customer contracts vary, so check the rules that apply to you. The formats above are voluntary open standards.
Sources
Last reviewed: 18 October 2026.
