What is an AIBOM (AI Bill of Materials)?
An AIBOM (AI Bill of Materials) is a structured, machine-readable inventory of every AI component in a system: foundation models, fine-tuned variants, LoRA adapters, training datasets, embedding models, retrieval indexes, evaluation datasets, and the relationships between them. It is the AI-supply-chain analog of SBOM (Software Bill of Materials) — same purpose (provenance, vulnerability tracking, license compliance), different artifact (models and data, not packages and binaries).
What goes in an AIBOM
A useful AIBOM captures:
- Models — name, version, source (provider, hash), modality, capabilities
- Fine-tunes and adapters — base model, training corpus reference, owner, training timestamp
- Datasets — source, license, contents type (PII, regulated, public), preprocessing applied
- Embedding indexes — embedding model, source corpus, last refresh time, ACL
- Tools and integrations — for agentic systems, every connected tool with its authorization scope
- Evaluation results — safety scores, capability benchmarks, last red-team result
- Dependency graph — which fine-tune was trained on which base, which RAG pipeline uses which embedding model
Several emerging standards aim to formalize this:
- CycloneDX AIBOM — extends the OWASP CycloneDX SBOM standard with AI-specific component types
- SPDX 3.0 AI profile — adds AI/ML components to the SPDX standard
- Hugging Face model cards + dataset cards — structured metadata adopted as a de facto standard
Why AIBOM matters
Three concrete use cases:
-
Supply-chain incident response. When a vulnerability is disclosed in a foundation model or training dataset, the AIBOM tells you which downstream applications are affected. Without it, the question "are we exposed to this?" requires a manual hunt across the org.
-
Distillation and provenance tracking. When a model is trained on outputs from another model (knowledge distillation), the AIBOM records the lineage. If the upstream model has a safety regression, the distilled descendants inherit it — and the AIBOM tells you which.
-
Regulatory compliance. ISO 42001, the EU AI Act, and emerging US AI executive orders all require demonstrable inventory of AI systems and their components. AIBOM is the artifact that satisfies the inventory requirement.
AIBOM vs. SBOM vs. DBOM
These three are complementary, not overlapping:
| Artifact | Tracks |
|---|---|
| SBOM | Software components — packages, libraries, binaries |
| AIBOM | AI/ML components — models, datasets, adapters, evaluation results |
| DBOM (Data Bill of Materials) | Data lineage — sources, transformations, classifications |
A modern AI application typically needs all three to fully describe its supply chain.
What goes wrong when AIBOM is absent
- The DeepSeek-R1 distillation lineage problem. Many models in production are descendants of DeepSeek-R1 with unknown safety properties. Without AIBOM, downstream operators can't tell which models inherit which safety gaps.
- The LoRA marketplace problem. Adapters distributed through Hugging Face and similar platforms are easy to install, hard to provenance, and can contain backdoors. Without AIBOM, an org doesn't know which adapters are running where.
- Compliance audits become archaeology. When an auditor asks "what AI systems do you operate," reconstructing the answer from scratch takes weeks.