Is an AI-BOM required by regulation?

Not as a named artifact in most jurisdictions today, but the underlying obligations increasingly assume it. Documenting system components, data provenance, and third-party dependencies is a recurring requirement in AI governance frameworks and in the EU AI Act's technical documentation duties for higher-risk systems.

Can I generate an AI-BOM from my existing SBOM tooling?

Partially. Model and dataset components have emerging support in CycloneDX and SPDX. Instruction artifacts — skills, rule files, hooks — and MCP connector scopes generally do not, because they are not packages and no manifest declares them.

Practices

AI bill of materials (AI-BOM)

definition

An AI bill of materials (AI-BOM) is a structured inventory of every component an AI system depends on, including models, datasets, prompts, instruction artifacts, and tool connectors.

In depth

An SBOM answers 'what code is in this build'. An AI-BOM extends the same idea to the components that determine an AI system's behaviour but never appear in a package manifest: which model and version, which fine-tunes and datasets, which system prompts and rule files, which skills, which hooks, and which MCP servers with which scopes.

The motivation is the one that drove SBOM adoption — incident response. When a widely-used artifact turns out to be malicious, the only question that matters is 'where is it, and who ran it'. Answering that for a compromised npm package is now routine. Answering it for a compromised MCP server or a poisoned skill is, in most organisations, a Slack thread.

Existing formats can carry some of this. CycloneDX has added machine-learning model support, and SPDX has moved in the same direction, so models and datasets have somewhere to live. Instruction artifacts and connector scopes are less settled, which in practice means teams either extend a format themselves or maintain the inventory in whatever system already holds their agent configuration.

The property that makes an AI-BOM useful rather than ceremonial is that it is generated from what is actually loaded, not from what somebody documented. An inventory assembled by hand is stale within a sprint. One derived from the same mechanism that distributes the artifacts is correct by construction.

Why it matters for governance

An AI-BOM is only worth building if it is queryable during an incident and generated automatically. The useful version answers, in one query: which machines loaded this artifact version, when, in which sessions, and under which credentials. That requires the distribution path and the inventory to be the same system — an inventory maintained beside the distribution path is a document, not a control.

Frequently asked

Is an AI-BOM required by regulation?: Not as a named artifact in most jurisdictions today, but the underlying obligations increasingly assume it. Documenting system components, data provenance, and third-party dependencies is a recurring requirement in AI governance frameworks and in the EU AI Act's technical documentation duties for higher-risk systems.
Can I generate an AI-BOM from my existing SBOM tooling?: Partially. Model and dataset components have emerging support in CycloneDX and SPDX. Instruction artifacts — skills, rule files, hooks — and MCP connector scopes generally do not, because they are not packages and no manifest declares them.

Sources

Primary sources for the claims on this page. Specifications and vendor documentation change — verify against the source if a detail is load-bearing for a decision you are making.