What Is an AI BOM? The AI Bill of Materials Explained
An AI BOM lists every model, dataset, prompt, tool and policy behind an AI system. Learn what goes in one, who asks for it, and how to produce it.
Contents · 15 sections
- Why AI BOMs exist
- What goes in an AI BOM
- AI BOM vs SBOM
- Static vs per-run AI BOMs
- Who asks for an AI BOM
- Standards to know
- How to produce an AI BOM without manual work
- Common mistakes
- How an AI BOM fits into governance
- Where AISquare fits
- FAQ
- What is an AI BOM?
- What is the difference between an SBOM and an AI BOM?
- Is an AI BOM legally required?
- Next step
An AI BOM, short for AI Bill of Materials, is an inventory of everything an AI system is built from: models, versions, datasets, prompts, tools, dependencies and the policies that govern it. It does for AI what a software bill of materials (SBOM) does for code. It lets a buyer, auditor or security team see what is inside.
Why AI BOMs exist
Software teams adopted SBOMs so they could answer one question quickly when a vulnerability appeared: are we affected? You cannot answer that if you do not know what is in your product.
AI systems have the same problem with more moving parts. An agent may call several models, pull from knowledge sources that change weekly, and use tools owned by other teams. When something goes wrong, the first question is what exactly was running.
What goes in an AI BOM
| Component | What to record |
|---|---|
| Models | Name, provider, exact version, and for self-hosted models a hash of the weights |
| Data and knowledge | Sources the system draws on, with versions and owners |
| Prompts | System prompts and templates, versioned |
| Tools and APIs | Every tool the agent can call and its permissions |
| Frameworks | Agent framework and library versions |
| Policies | The rules in force and their versions |
| Evaluations | Tests run and their results |
AI BOM vs SBOM
An SBOM lists software packages and their versions. That is still needed for an AI system, because the agent runs on code.
An AI BOM adds the parts an SBOM has no place for. A model is not a library. A prompt is closer to configuration than code. A knowledge base changes without a release. Policies decide what the system is allowed to do. Each of these affects behavior, so each belongs in the inventory.
Static vs per-run AI BOMs
Most AI BOMs describe a system at release. That is useful, and it is the minimum.
Agents change more often than releases. A prompt is edited on Tuesday, a policy is tightened on Thursday, and the model provider ships an update in between. A static document is out of date within days.
A per-run AI BOM records what was used on a specific run. Months later you can answer “which model, prompt and policy version made this decision?” without guessing. That makes it a natural partner to an AI audit trail.
Who asks for an AI BOM
- Security teams reviewing third-party and internal AI for supply chain risk
- Compliance and legal preparing evidence for audits
- Procurement at regulated buyers, as part of vendor due diligence
- Defense and government buyers, where supply chain documentation is standard practice
If you sell AI to a regulated enterprise, expect this request in the security questionnaire.
Standards to know
Two open standards already cover AI components. CycloneDX added a machine learning bill of materials. SPDX 3.0 added AI and dataset profiles. Building on one of them keeps your AI BOM readable by the tools your customers already use.
How to produce an AI BOM without manual work
- Capture at runtime. Record components as the agent runs, so the inventory matches what was used.
- Version everything. Prompts, policies and knowledge sources need version IDs just like models.
- Sign it. A signed AI BOM proves the inventory was not edited afterward.
- Attach it to the decision record. It is most useful next to the reasoning and policy results for the same run.
- Export in a standard format. Make it easy for an auditor’s tools to read.
A spreadsheet maintained by hand will work for one agent for about a month. After that it drifts from what is deployed.
Common mistakes
- Listing the model and stopping there. Prompts, tools and policies change behavior just as much.
- Recording “latest” as a version. Pin the exact version or the record cannot be checked.
- Leaving out permissions. What a tool is allowed to do matters as much as which tool it is.
- Treating it as a one-time document. An AI BOM that is not updated gives false comfort.
How an AI BOM fits into governance
An AI BOM answers “what was running?” It does not answer “why did it decide that?” or “did it follow the rules?” Those come from reasoning records and runtime policy checks. Together they give an auditor the full picture. See how the pieces fit in our AI governance framework guide.
Where AISquare fits
AISquare produces an AI BOM alongside the signed decision record for your agents. Records export in standard formats including in-toto statements and DSSE envelopes. The AI BOM exports as CycloneDX. Read more in our AI agent governance guide.
FAQ
What is an AI BOM?
An AI BOM, or AI Bill of Materials, is a structured inventory of the models, data, prompts, tools and policies that make up an AI system.
What is the difference between an SBOM and an AI BOM?
An SBOM lists software components. An AI BOM adds AI-specific parts such as models, datasets, prompts and policies.
Is an AI BOM legally required?
Requirements vary by sector and region. Many regulated buyers already ask for one in vendor reviews, so check with your counsel and your customers.
Next step
See an AI BOM and signed decision record from a live agent. Book a demo.
Related reading: AI agent governance · AI agent guardrails · Agent observability · AI governance tools · AI hallucination examples · AI governance framework · Human in the loop · AI audit trail
Get your agents into production
AISquare captures the reasoning behind every agent decision, enforces your rules on every run, and keeps a record your risk team can check.
