Key Takeaways
- An AI BOM (AI Bill of Materials) records what an SBOM structurally cannot: model weights, dataset snapshots, fine-tuning runs, system prompts and agent tools.
- Model weights are not packages. No semantic version, no manifest, no advisory feed—so the BOM carries a digest and a lineage record instead.
- A system prompt is executable configuration. If it changes behavior without a code review, it belongs in the BOM with a hash and an owner.
- CycloneDX and SPDX both added model types. Neither treats a fine-tuning run as a build event, and no advisory feed keys off a weights file.
- A BOM earns its keep on three questions: what is vulnerable, what breaks if this component disappears, and what do we send the customer who asked.
A customer’s security team sends a questionnaire. Question 14 asks which foundation models process their data, where those models are hosted, and whether any of it was used for training. You can answer for the two systems your team built. You cannot answer for the eleven other teams built, and nothing you own would tell you. Three weeks later you send back an answer you do not trust.
An AI Bill of Materials is a structured inventory of everything an AI system depends on to produce an output: the model and its exact revision, the data behind it, the pipeline that produced the weights, the prompts that shape behavior, the tools it can call, and the services in the request path.
What Is an AI BOM, and Why Doesn’t an SBOM Cover It?
Weights are not packages. A package has a name, a version, an ecosystem and a registry that resolves all three deterministically. A model artifact has a repository name, a branch, and often a tag someone can move. Nothing in your build fails when it does. The only stable identifier is a digest of the artifact files, and most teams never record one.
Datasets have no version pinning culture. Package ecosystems spent fifteen years learning to pin. Data engineering never did. The normal idiom is a bucket prefix and a date range, which resolves differently every time it runs. Two fine-tuning runs a week apart, both logged as the same dataset, were not on the same dataset.
A system prompt is executable configuration. It assigns the model its role, its refusal rules, often its tool inventory and endpoints. It changes behavior as decisively as a code change, and it is routinely edited by people who never touch a pull request. An SBOM has no component type for it, because in conventional software it did not exist.
What Components Belong in an AI Bill of Materials (AIBOM)?
Seven classes, each with its own fields. Forcing all seven into one name-and-version schema is what makes most AI inventories unusable.
Models
Family and identifier, source registry or endpoint, exact revision as a commit SHA or digest rather than a tag, serialization format and whether it deserializes code on load, license restrictions, the base model it descends from, and hosting mode. Derivation is the field people skip and the one recall depends on.
Datasets
Source URI, snapshot date, a content hash of the exact extract used, collection method (licensed, scraped, synthetic, customer-derived), classification, the consent or contractual basis, and any deletion obligation that travels with it. A dataset entry without a hash is a note, not a control.
Training and fine-tuning runs
The class most inventories omit, and the join between the other two. Base model plus revision, dataset references by hash, the code commit, container image, hyperparameters, the identity that launched it, and the digest of the output artifact. Without it you can say what runs, never what went into it.
Prompts and configuration
Content hash, location, last change and approver, whether it embeds credentials or internal endpoints, and whether it is static in source or fetched at runtime. The second is a supply-chain edge: whoever controls that service controls your instructions.
Retrieval sources
Index name, the embedding model and its revision, the source systems the connector reads, refresh cadence, and the entitlement model of the underlying source. A connector that reads more than any single user can is a disclosure risk.
Agent tools and MCP servers
Name, the host or API it reaches, the identity it acts as, whether it reads or writes, the schema hash, and whether the definition is local or pulled from a remote catalog. Remote definitions change with no deploy of yours.
Services and infrastructure
Inference providers and endpoints, orchestration frameworks with resolved versions, vector databases, gateways, GPU images, and data residency for each.
How CycloneDX and SPDX Handle Model Components—and What They Don’t
CycloneDX added a machine-learning-model component type and a model card section covering intended use, considerations and quantitative analysis. SPDX 3.0 introduced AI and dataset profiles with fields for training method, safety risk assessment and standards compliance. CycloneDX fits security tooling better; SPDX fits license and provenance work.
What neither handles: a fine-tuning run as a build event linking base model, dataset hashes and code commit. Prompts, which have no component type anywhere. The agent tool graph, a relationship structure rather than a list. And models have no identifier namespace with the resolving power purl and CPE give packages.
What Can You Actually Do With an AI-BOM?
Vulnerability correlation, honestly scoped. Your CVE hits land on the surrounding stack: serving framework, orchestration library, tokenizer, driver layer. Resolve every version there and match it against CVE and OSV data on a schedule. For weights and datasets there is no feed, so the BOM’s job is recall—when a model is found backdoored or a dataset withdrawn, you name every affected system in minutes. That is the problem the wider AI supply chain creates.
Blast-radius questions. These are graph queries, and the BOM is the graph. Which systems ingested this dataset between March and June. Which agents can reach the payments API, and which of those a customer-facing chat path can invoke.
Vendor and regulator answers. Question 14 stops being a three-week project. The same records serve EU AI Act transparency obligations, NIST AI RMF mapping and customer due diligence—all variants of the same question.
Generate It, Don’t Curate It
A hand-maintained AI inventory is accurate on the day of the workshop and wrong within a sprint. Produce it from repositories, pipelines and registries on every build, then diff it: a new model, a new tool, a new outbound endpoint in a system prompt, a dataset hash that moved—each is a review trigger. Two things static generation will never see are the contents of a retrieval index at a given moment and configuration fetched at runtime. That record belongs in your architecture.
Where Cranium Fits
An AI-BOM is only useful inside a loop that also watches what runs and produces evidence. The AI Trust Loop runs Discover, Observe, Govern, Secure, and Prove:
- Discover DetectAI™ identifies which repositories hold AI components; CodeSensor™ scans GitHub, GitLab, Bitbucket and Azure DevOps to auto-generate the AI-BOM—models, datasets, technologies with resolved versions, infrastructure and static system prompts; AgentSensor™ adds agentic frameworks, handoff graphs, and the agent tools and MCP servers found in source. Exports CycloneDX and SPDX.
- Observe Guardian inspects traffic between your AI application and the LLM it calls, per interaction; the Shadow AI view classifies activity from your connected SIEM into AI Provider Access, AI-Enabled SaaS, AI Web App Usage and Dev App Embedded AI.
- Govern AI System Manager holds the inventory as the system of record, with compliance scoring against the EU AI Act, NIST AI RMF and ISO/IEC 42001.
- Secure Technologies in the BOM carry CVE and CVSS detail linked to the OSV database, and the Adversarial Inputs Detector scans agent configuration files for malicious content, data-exfiltration endpoints and hidden Unicode.
- Prove The AI Card™ turns the inventory into a living, exportable transparency report per system, mapped to the EU AI Act, NIST AI RMF and ISO 42001, with a request-and-respond workflow for suppliers under My Vendors.
You already know how to run an asset inventory. This is that discipline, applied to components your current tooling cannot see.
Frequently Asked Questions
Is an AI-BOM a regulatory requirement?
Not under that name. But EU AI Act transparency obligations, NIST AI RMF mapping and customer security reviews all ask questions only a BOM answers.
How granular should model entries be?
Granular enough to reproduce. If two people cannot independently retrieve the same artifact from the entry, it is decorative. A digest does that; a family name does not.
Do we need one for models we only call by API?
Yes, with different fields: endpoint, region, provider, model identifier and version string, data-handling terms, retention commitments. You cannot hash weights you do not hold, so record the contract.
Who should own it?
Whoever owns your software asset inventory today. A separate program run by a separate team is how it drifts.
See Cranium in Action
See an AI-BOM generated from a live repository, versions resolved and vulnerabilities correlated—schedule a personalized demo: cranium.ai/get-a-demo/
