An AI Bill of Materials (AIBOM) is a structured inventory of the components making up an AI system: models, training datasets, libraries, prompts, agents, tools, and the relationships between them. It extends the software bill of materials concept to AI-specific components and is required or recommended under several emerging regulatory frameworks.
- A structured inventory of every component inside an AI system
- Extends the SBOM concept to models, datasets, prompts, agents, and tools
- Answers the supply chain questions regulators are beginning to ask
- Converging on the SPDX and CycloneDX formats already used for SBOMs
Why is an AI Bill of Materials important?
An AIBOM matters because without one an enterprise cannot answer the supply chain questions regulators are now asking. Which models are in production. Which training datasets they came from. Which third parties touched them. Which versions are deployed where. Those are inventory questions, and an organization either has the record or it does not.
The pressure is arriving from more than one direction. The practice is converging with the SPDX and CycloneDX formats already used for software bills of materials, which means it is likely to be requested in the same way and through the same channels, and it sits alongside the wider body of federal AI security guidance CISA maintains in its AI resources.
The practical argument is narrower than the regulatory one. When a vulnerability or a licensing problem surfaces in a model or an ML library, the first question is which systems are affected. An organization with an AIBOM answers in minutes. One without it starts an investigation.
What is an AI Bill of Materials?
An AIBOM is a machine-readable record of what an AI system is made of and how those parts relate. It is the AI analog of an SBOM, extended to cover components software bills of materials were never designed to describe.
Six component classes typically appear. Models, including base models, fine-tuned derivatives, and their versions. Training and fine-tuning datasets, with provenance and licensing. Libraries and frameworks the system depends on. Prompts and system instructions, which shape behavior and are frequently undocumented. Agents built on the models. And tools those agents can invoke.
Relationships matter as much as the list. An AIBOM that records a model and a dataset without recording that the model was fine-tuned on that dataset answers fewer questions than the components alone suggest. The dependency graph is what makes impact analysis possible.
An AIBOM is a record rather than a control. It supports assessment and regulatory response, and it prevents nothing on its own.
Types of AIBOM components
Components divide by what they contribute to a system's behavior, and each carries different supply chain questions.
Model components cover base models, fine-tuned variants, embeddings models, and version identifiers. The questions are provenance and licensing, and whether a given version is still supported.
Data components cover training sets, fine-tuning sets, evaluation sets, and retrieval corpora. The questions are lineage and licensing, and whether personal or regulated data is present.
Code components cover ML frameworks, inference servers, and application dependencies. These are the components conventional SBOM tooling already handles well.
Behavioral components cover prompts, system instructions, guardrail configurations, and policy definitions. These are the least likely to be captured and often the most determinative of how a system actually behaves.
Agent components cover agents, their tool catalogs, and the MCP servers they reach, which is the newest class and the one least well served by existing formats.
AI Bill of Materials & Onyx
Onyx produces continuous AI asset inventory across agents, models, MCP servers, and AI-powered applications, with the metadata an AIBOM workflow consumes. The distinction worth drawing is that Onyx is not an AIBOM generator; it is the discovery layer an AIBOM depends on.
That matters because the hard part of an AIBOM is rarely the format. It is knowing what exists to describe. An inventory assembled by asking teams what they deployed will miss the agents nobody registered and the MCP servers installed from public registries. Continuous discovery across surfaces closes that gap, and asset tagging carries the ownership and classification metadata an AIBOM record needs.
