An AI Bill of Materials (AIBOM) is a machine-readable inventory of every component an AI system depends on — models and their revisions, training and fine-tuning datasets, packages, prompts, and external services — extending the SBOM concept to the parts of the stack that a package manifest never sees. The reason to build one is the same reason SBOMs went from nice-to-have to procurement requirement after Log4Shell: when the next poisoned model or dataset disclosure lands, "are we affected?" must be answerable by query. Right now, most teams would answer it by Slack archaeology.
What an AIBOM contains that an SBOM does not
A conventional SBOM enumerates resolved packages. An AI system's behavior is determined by at least five more component classes:
| Component class | Example entry | Why it must be tracked |
|---|---|---|
| Model | meta-llama/Llama-3.1-8B, revision 0e9e39f2, sha256 of weights | Weight swaps and silent revision drift |
| Fine-tune lineage | Base model + adapter + training run ID | Poisoned-base blast radius queries |
| Dataset | Corpus name, version, content hash, license | Data poisoning, copyright exposure |
| Prompts | System prompt file + git commit | Behavior changes with no code diff |
| External AI services | API provider, model ID, endpoint, data-retention terms | Vendor risk, residency, deprecations |
| Tools/MCP servers | Server package, version, tool-manifest hash | Runtime supply chain (rug pulls) |
The lesson from SBOM adoption applies directly: if generation is manual, the document is stale by the second sprint. Every one of these fields must be extractable from CI or from configuration, or it should not be in scope for v1.
The format question: CycloneDX 1.6 is the pragmatic answer
CycloneDX 1.6 (April 2024) added first-class ML support and remains the workhorse in 2026: a machine-learning-model component type, modelCard objects (task, architecture, ethical considerations, quantitative metrics), and data components for datasets. SPDX 3.0 defines an AI profile as well, and it is the right choice if your organization is already SPDX-committed, but tool support for the CycloneDX ML fields is currently broader.
A minimal model component looks like:
{
"type": "machine-learning-model",
"name": "llama-3.1-8b-instruct",
"version": "0e9e39f2",
"hashes": [{ "alg": "SHA-256", "content": "9f2c..." }],
"modelCard": { "modelParameters": { "task": "text-generation" } },
"externalReferences": [
{ "type": "distribution", "url": "https://huggingface.co/meta-llama/Llama-3.1-8B" }
]
}
Datasets attach as data components with classification (training, fine-tuning, validation) and hashes where the corpus is hashable. Prompts, pragmatically, ride along as file components pointing at a git path and commit — the spec police will survive it, and it makes prompt changes diffable in the same artifact as everything else.
Generating it in CI, not in a spreadsheet
The pipeline shape that works:
- Package layer: your existing SBOM generator (
syft,cdxgen, or the scanner built into your SCA platform) emits the code-level CycloneDX document per build. Nothing new here. - Model layer: a small script reads the serving config or model registry (MLflow, Weights and Biases, SageMaker Model Registry all expose APIs) and emits model components with revision and hash. If you follow the pinning discipline from model weight signing and provenance, the hashes already exist in the repo.
- Service and tool layer: parse the app config for provider model IDs and MCP server entries; emit each with version and manifest hash.
- Merge:
cyclonedx merge --input-files sbom-code.json sbom-ml.json --output-file aibom.json, sign the result, and store it per release next to the container digest it describes.
Total new code for steps 2–3 is typically 200–400 lines. Storing and querying the merged output is where a platform earns its keep — SBOM Studio treats model and dataset components as first-class searchable inventory, so "every service fine-tuned from base model X" or "everything still calling a deprecated provider model" is a saved query rather than a script someone re-writes each quarter.
The queries that justify the effort
An AIBOM is only as valuable as the questions it answers fast. The ones that come up in real incidents and audits:
- Which deployed services embed weights derived from a given base model revision? (Poisoned-base disclosure.)
- Which products trained or fine-tuned on dataset D? (License revocation, poisoning, GDPR erasure claims.)
- Which systems call provider model M being deprecated in 90 days? (The mundane one — and the most frequent.)
- What changed in the AI stack between release 41 and 42? (Diff two AIBOMs; this is your change-review artifact.)
- Which MCP servers in production have manifest hashes that drifted from approval? (Rug-pull sweep.)
If your AIBOM cannot answer these mechanically, it is documentation, not infrastructure.
Regulatory pull: why 2026 is the year this stops being optional
The EU AI Act's technical documentation duties for general-purpose and high-risk systems phase in through 2026–2027, and Annex IV's requirements — training data description, model specification, versioning, lifecycle traceability — map almost one-to-one onto AIBOM fields. US federal procurement language increasingly references AI supply chain transparency, and sector regulators (finance first, as usual) have begun asking for model inventories in exams. Teams that wired AIBOM generation into CI report audit-prep dropping from weeks to days; the artifact already exists, signed, per release. The compliance driver is real, but the operational driver — incident response speed — is the one engineers end up caring about.
Frequently asked questions
What is the difference between an SBOM and an AIBOM?
An SBOM inventories software packages. An AIBOM extends the same inventory to models, datasets, prompts, external AI services, and runtime tools — the components that determine an AI system's behavior but never appear in a package manifest. In practice an AIBOM contains an SBOM as a subset.
Which standard should I use for an AIBOM in 2026?
CycloneDX 1.6 or later for most teams: its ML model card and data components are the most widely tooled. SPDX 3.0's AI profile is credible if your compliance program is SPDX-based. Either beats an internal spreadsheet, which is the actual competing standard.
How do I handle third-party API models where I can't see weights or data?
Record what is knowable and contractual: provider, exact model identifier, endpoint region, data-retention and training-use terms, and the date verified. The AIBOM's job is to show your dependency and its terms, not to reproduce the provider's internals — auditors under the AI Act expect exactly this distinction.
Who should own the AIBOM?
The same pipeline that owns the SBOM — platform or DevSecOps — with ML engineering owning the accuracy of model and dataset entries. Ownership split by document instead of by field is how AIBOMs go stale.