AI-BOM Explained: Why Your SBOM Stops Where Your AI System Starts

You already know what is inside your container image. You can list every package, every version, every licence, every CVE. Then your team ships a feature that calls a large language model, pulls in a fine-tuned adapter from a public hub, feeds it a retrieval index built from internal documents, and wraps the whole thing in an agent with tool access.

Now ask the same question again: what is inside this product?

Your SBOM has an answer for maybe half of it. The other half, the half that decides what the system actually says and does, is invisible. That gap is what an AI-BOM fills.

What is an AI-BOM?

An AI-BOM (AI Bill of Materials) is a machine-readable inventory of every component an AI system depends on. That includes models, training and fine-tuning datasets, AI frameworks, prompts, agents and provenance records, each described in enough detail to identify and audit it later.

Think of it as the AI equivalent of an SBOM. Same idea, same discipline, wider scope.

The word "machine-readable" is doing real work in that definition. A wiki page listing your models is documentation. An AI-BOM is a structured document that a scanner, a policy engine or an auditor can parse without a human in the loop.

How is an AI-BOM different from an SBOM?

An SBOM lists software components: libraries, packages, container layers, their versions and their licences. It was designed for a world where the risky unknowns were code you did not write.

An AI-BOM covers a different class of dependency. Foundation models, datasets, embeddings and model lineage are not packages. They do not have a version pinned in a lockfile. They do not show up in a dependency graph. A conventional SBOM was never built to describe them, so it does not.

Here is the split, side by side.

Notice the last row. In classic software, a component changes when someone bumps a version. In AI systems, behaviour can change because a prompt was edited or a model was swapped behind an API you do not control. An inventory that only tracks packages will miss both.

Is an AI-BOM a replacement for an SBOM?

No. This is the question that trips up most teams, so it deserves a direct answer.

SBOMs have spent years earning their place. They power vulnerability management, licence compliance and supply chain transparency, and none of that goes away because you added a model to your stack. Your AI product still runs on Python packages, still sits on a base image, still inherits every CVE in that image.

What changed is that the software layer is no longer the whole story. Modern AI systems depend on:

• Foundation models and large language models
• Training and fine-tuning datasets, with data provenance
• AI frameworks and libraries
• Agents, prompts and embeddings
• Evaluation and testing artifacts
• Model provenance and lineage
• Licensing, copyright and governance information

Every item on that list can carry risk. None of them fit cleanly into an SBOM. So the practical shape of a mature inventory is one document that carries both: the software components you always tracked, plus the AI components you now have to.

AI-BOM architecture: how the pieces fit together

The diagram below shows the full path, from raw supply chain inputs through to the governance decisions the inventory is supposed to support.

Layer 1: Supply chain inputs

Everything your AI system pulls in. Models and adapters, datasets used for training and evaluation, the prompts and agent definitions that shape behaviour, the AI frameworks, and the ordinary packages and base images underneath it all. Most teams can name the first item on that list and struggle with the rest.

Layer 2: Generation

The AI-BOM should be produced by your pipeline, not by a person filling in a spreadsheet before an audit. The inputs come from systems you probably already run: a model registry that knows the checkpoint hash, a data catalogue that knows where a dataset came from, CI/CD scanners that build and sign, and an evaluation harness that knows how the model scored.

Timing matters here. Generate the AI-BOM after the artifacts are immutable and before the deployment is approved. Generate it too early and it describes something you did not ship.

Layer 3: The AI-BOM document

One signed inventory, not two competing ones. The left half is your familiar SBOM content. The right half is the AI extension: models, datasets with provenance, prompts and agents, evaluation results, lineage, and the licensing picture.

The single most useful discipline at this layer is identity. Record immutable hashes, not display names. A model tagged latest tells a future investigator nothing about what actually ran in production last Tuesday.

Layer 4: Governance and consumption

An inventory nobody queries is a filing exercise. The AI-BOM earns its keep when it feeds:

• Vulnerability management, including VEX statements about what is actually exploitable in your context
• Licence and copyright compliance, which is a sharper problem for models and datasets than it ever was for MIT-licensed libraries
• Release gates and admission policy, so a build without an approved model or a recorded evaluation does not ship
• Audit trails, which is what regulators will ask for
• Incident response, so that when a model or dataset is found to be compromised, you can answer "which deployments are affected" in minutes rather than weeks

What formats are used for AI-BOMs?

Two standards lead the field, and both can already carry AI components alongside traditional software dependencies.

CycloneDX covers AI through its ML-BOM support. It tends to suit teams already oriented around product security and existing BOM operations.

SPDX covers AI through the AI Profile introduced in SPDX 3.0, which describes the characteristics and capabilities of the AI component of a software application. It fits teams focused on detailed provenance, licensing and the relationships between artifacts.

Which one you choose matters less than a rule that applies to both: keep one authoritative internal inventory. A sensible pattern is to define a format-neutral internal schema for identity, provenance, relationships, licences, evaluations and deployments, then generate the standard format from it. Two hand-maintained inventories will drift apart, and the day they disagree is the day you need them.

Treat AI as another supply chain input

This is the mindset shift, and it is simpler than it sounds.

Organizations have maintained inventories of software libraries and third-party components for years. The same visibility is now needed one level up. Which AI models are in use. Which datasets contributed to those models. Where AI-generated code is entering the codebase. What licensing obligations apply. What human review was performed, and by whom.

That moves the goal from dependency scanning alone to something broader: AI supply chain security and governance. The scanner still runs. It just no longer covers the parts of the system most likely to surprise you.

How to start an AI-BOM without boiling the ocean

You do not need a governance programme to make progress this quarter.

1. Pick one production AI service. Not the whole estate.
2. Write down every model, dataset, prompt and agent it touches. Doing this by hand once is the fastest way to find out what your tooling cannot see.
3. Replace names with hashes. Every entry gets an immutable identifier.
4. Record the relationships, not just the list. There is a real difference between a dataset a model was trained on, fine-tuned with, evaluated on and retrieved from at runtime.
5. Attach licences and evaluation results. These are the two fields people wish they had captured after the fact.
6. Emit CycloneDX or SPDX from your pipeline and sign it.
7. Add one gate. Block the release when identity, licence approval or evaluation is missing. One enforced rule beats ten documented ones.

Common mistakes worth avoiding

• Treating the AI-BOM as a compliance badge. It is evidence infrastructure. If it cannot answer which model influenced a given release, it is decoration.
• Generating it by hand. Manual inventories are stale the moment the next build runs.
• Ignoring prompts and agent tools. A system prompt change can alter behaviour more than a model upgrade. If it changes behaviour, it belongs in the inventory.
• Forgetting the software half. The AI extension gets the attention, but the base image is still where most of your CVEs live.
• Putting sensitive dataset details in a widely shared document. Reference them from controlled evidence instead.

Frequently asked questions

What does AI-BOM stand for? AI Bill of Materials. It is a machine-readable inventory of the models, datasets, frameworks, prompts, agents and provenance information an AI system depends on.

Is an AI-BOM legally required? Requirements are still forming and vary by jurisdiction and sector, but the direction is clear. Procurement teams and regulators are already asking for model and dataset transparency, and organizations that can produce this evidence on request are in a much better position than those starting from zero.

Can I use my existing SBOM tooling? Partly. If you already generate CycloneDX or SPDX, you are working in the right formats and can extend them. The gap is usually in the sources feeding those tools, since a package scanner has no view into your model registry or data catalogue.

How often should an AI-BOM be regenerated? On every release, and on any change to a model, adapter, behaviour-shaping prompt or dataset. Tie each production deployment to the exact revision of its AI-BOM.

Does an AI-BOM cover AI-generated code? It should. Knowing where AI-generated code entered the codebase, and what human review it received, is part of the same visibility problem.

The bottom line

The AI-BOM is not a new bureaucracy layered on top of the SBOM. It is the same question your SBOM already answers, asked about the parts of your system that SBOM was never designed to see.

If you can list every package in your image but cannot say which model version, which dataset and which prompt produced yesterday's output, you have an inventory with a hole in the middle. Closing it starts with one service, one honest list, and a pipeline that keeps that list true.