An AI bill of materials (AIBOM) is an inventory of the models, datasets, code and services inside an AI system, recorded so you can answer questions later: what is in it, where did it come from, and what changed. Record enough to trace provenance and respond to a vulnerability or a regulator, without trying to capture everything.
What is an AIBOM and who defines it?
Two public efforts are worth knowing. The CycloneDX specification includes a Machine Learning Bill of Materials (ML-BOM), which its authors describe as representing datasets, models and configurations, documenting dataset provenance, and supporting risk assessment around bias, data integrity and model security. The OWASP GenAI Security Project runs an AI Bill of Materials initiative aimed at practical, open approaches to AI supply chain transparency, including an open source AIBOM generator.
CISA's 2026 Minimum Elements for an SBOM adds a relevant note: some software types, such as artificial intelligence, may require additional elements beyond the baseline. An AIBOM extends your software inventory, it does not replace it.
What to record
Work through these groups. Record what you can verify and mark the rest as unknown, so gaps are visible.
The system
- Name, owner, purpose and deployment environment.
- Which versions are in production and since when.
- Where it runs and which data it can reach.
Models
- Each model's name, version or hash, supplier and where you obtained it.
- Licence terms.
- Whether it is hosted by a provider, run by you, or fine tuned from another model.
- For fine tuned models: the base model and the fine tuning data reference.
Data
- Training, fine tuning and retrieval datasets, with source, collection method and date.
- Known restrictions on use, such as licences or personal data.
- For retrieval systems, the knowledge sources, who can write to them and how they are validated.
Software around the model
- Frameworks, inference servers, libraries and plugins, with versions. This is your ordinary SBOM.
- Tools and connectors the model can call, and the permissions of each.
- Prompt templates and system prompt versions.
Controls and evaluation
- Safety and security tests run, with dates and results.
- Guardrails and filters in place.
- Logging and monitoring in use.
Change history
- Who changed what and when, with approvals.
Why these fields?
Each answers a question you will meet. A vulnerability in an inference library needs the software list. A licence dispute needs the model and data sources. A poisoning concern needs the retrieval sources and who can write to them. A regulator asking about training data needs dataset provenance. OWASP's guidance on vector and embedding weaknesses, for example, calls for validating knowledge sources and keeping logs of retrieval activity, which only works if you know what the sources are.
What to do
- Start with an inventory of AI systems in production, including ones teams adopted informally.
- Pick a format. CycloneDX ML-BOM is an open option, and your existing SBOM tooling may already read CycloneDX.
- Fill the fields above for your highest risk system first.
- Mark unknowns explicitly and assign an owner to close each one.
- Regenerate the record on every model, data or dependency change.
- Store it where incident responders can reach it quickly.
- Review with legal for licence and data restrictions.
Quick check
Is an AIBOM the same as an SBOM?
No. An SBOM lists software components. An AIBOM adds models, datasets and configuration, and the provenance of each. In practice you keep both.
Can I get a model's training data details from a provider?
Often only in part. Record what the provider publishes, cite where you found it, and mark the rest unknown.
Sources
- CycloneDX, Machine Learning Bill of Materials (ML-BOM)
- OWASP GenAI Security Project, AI Bill of Materials initiative
- CISA, 2026 Minimum Elements for a Software Bill of Materials
- OWASP LLM08:2025 Vector and Embedding Weaknesses
Last reviewed: 18 October 2026.
