An AI Bill of Materials (AI-BOM) is a structured inventory of everything an AI system is built from: models, datasets, training lineage, hosted APIs, agent frameworks, and their licenses. It extends the SBOM idea to components no package manifest records.
That's the snippet answer. The fuller one is about who's asking. In 2026 the AI-BOM stopped being a standards-body hobby and became a procurement artifact, pulled into scope once by European regulators and once by the buyer with the deepest supply chain on earth. If nobody has asked your team for one yet, odds are decent someone will before the year is out.
The standards got there before the buzzword
Two mature SBOM formats already carry AI extensions, and both predate the current wave of interest.
SPDX 3.0, released on April 16, 2024, added an AI profile and a Dataset profile that together amount to a workable AI-BOM specification. The AI profile describes a model's architecture, its size and compute requirements, energy usage, known limitations, preprocessing steps, and safety metrics. The Dataset profile covers what the model learned from: dataset type, size in bytes, whether it's publicly downloadable or gated, how it was collected and prepared, and under what license. The SPDX AI Working Group has been at this long enough to publish an academic account of the effort, "Building an Open AIBOM Standard in the Wild."
CycloneDX took the other route in. The OWASP flagship standard, since ratified as ECMA-424, added machine-learning component types in version 1.5 back in 2023 and extended them in 1.6. A model component in a 1.6 ML-BOM can capture name, version, format, parameter count, license, training context, and a hash of the weight artifact. The OWASP CycloneDX AI/ML Working Group has published a first-edition Authoritative Guide to AI/ML-BOM, and OWASP separately runs an AIBOM Initiative under its GenAI Security Project, which took in the open-source AIBOM Generator in December 2025.
So the schema question is settled. Nobody needs to invent one.
What an SBOM never held
An SBOM inventories what you compiled. An AI-BOM inventories what your system learned from and who it calls at runtime. Datasets and hosted models are supply-chain dependencies that never appear in a package manifest, and that gap is exactly where the new formats live.
Last verified: September 5, 2026.
| Component class | Classic SBOM | AI-BOM |
|---|---|---|
| Software packages, versions, licenses | Yes | Yes |
| Models: architecture, version, parameter count, license, weight hash | No | Yes |
| Datasets: provenance, collection method, licensing, availability | No | Yes |
| Training and fine-tuning lineage | No | Yes |
| Hosted model APIs (OpenAI, Anthropic, and similar endpoints) | No | Yes |
| Agent frameworks and MCP tool connections | No | Yes |
| Energy and compute characteristics | No | Yes (SPDX AI profile) |
| Limitations and safety attributes | No | Yes |
The weight-hash row deserves a pause. A model file is executable trust. Swap the weights and you've swapped the behavior, with no CVE feed to warn you. The same logic covers agent tooling, where a poisoned tool description rides into your stack through a dependency nobody audited; we walked through that failure mode in our tool poisoning breakdown. An AI-BOM is the inventory step that makes tampering detectable at all.
Who's actually asking for one
The US Army, for a start. Project Linchpin, the AI pipeline program under PEO IEW&S, issued a request for information seeking to "implement and automate an Artificial Intelligence Bill Of Materials," tracking the software supply chain, model details, and training-data lineage. When a customer that size writes the acronym into a solicitation, vendors adjust.
Europe arrived by a different door. The EU AI Act's Annex IV defines the technical documentation high-risk systems must maintain under Article 11(1), and point 2(d) reads like a dataset BOM spec: datasheets with training methodologies, descriptions of training datasets, the provenance and scope of the data, how it was obtained and selected, labelling procedures, cleaning methods. High-risk enforcement has been live since August 2, 2026. Our EU AI Act compliance guide covers the full obligations; the narrow point here is that Annex IV documentation is an AI-BOM in prose form. Build the machine-readable version first and the prose becomes a rendering job.
Now the honesty section. Vendor posts claim several US federal contracting flows already require an AI-BOM in technical submissions. We went looking for the FAR or DFARS clause behind that claim and found nothing. Treat it as directional. Also retired: Executive Order 14110, which triggered NIST's early AI-security work, was rescinded in January 2025, and current federal AI procurement policy flows from OMB's 2025 memos instead. Any compliance deck citing the EO as live policy is stale.
Where demand shows up reliably is less glamorous. Model provenance and training-data questions are now standard fixtures in vendor security questionnaires and agent procurement RFPs, and an AI-BOM answers them in one attachment instead of forty comment boxes.
Building one that doesn't rot
The failure mode is predictable. A spreadsheet gets assembled for an audit, gets praised, and is wrong within six weeks. Avoiding that takes five decisions, most of them boring.
Pick one format and stay in it: CycloneDX 1.6 ML-BOM if your SBOM pipeline already speaks CycloneDX, SPDX 3.0's AI and Dataset profiles if you're SPDX-native. Converting later is misery you can decline now. Then start with the model layer, because it's the shortest and most consequential list — every hosted-API model, downloaded checkpoint, and fine-tune, with provider, version, license, and weight hash. Datasets come second, with provenance, license, and collection method, which happens to be the exact material Annex IV 2(d) asks for.
The fourth decision is to stop treating the result as a document. Wire generation into CI so the AI-BOM rebuilds on every change; an inventory that depends on a human remembering it exists is already dead. The fifth is the one most teams miss: agent-era components count. MCP servers, tools, and agent frameworks are dependencies with real blast radius, and the newer scanners already list them.
Discovery is the honest prerequisite for all five. You can't enumerate models your teams are calling through apps you've never heard of, which is where a governance layer earns its keep; accuroai's catalog covers 1,400+ AI applications and maps what it finds to 8 compliance frameworks, so the inventory starts from observed traffic rather than a survey.
The tool list, kept honest
Three tools we could verify against primary documentation. Snyk's aibom CLI, out of Snyk Labs, scans Python, Java, JavaScript, and Go repositories for models, datasets, AI libraries, agent frameworks, and MCP connections, and emits CycloneDX 1.6 ML-BOM. The OWASP AIBOM Generator produces CycloneDX output for models hosted on Hugging Face. Manifest sells its AIBOM as "a living operational artifact" with an AI Risk module attached, though you should confirm current product naming on their site before shortlisting.
Roundup posts name more vendors. Some of those product pages describe dependency scanning and reachability analysis rather than AI-BOM generation, so ask for a sample output file before any of them makes your shortlist. A vendor that can't hand you an actual CycloneDX or SPDX document doesn't generate AI-BOMs. It generates interest.
One last placement note: if your program spans NIST AI RMF, ISO 42001, and the AI Act simultaneously, the unified compliance crosswalk shows where a single inventory feeds all three. That's the quiet payoff. One artifact, several regulators.
Questions that come up in procurement reviews
Is an AI-BOM legally required anywhere?
Not by name. The EU AI Act requires Annex IV technical documentation for high-risk systems, and its dataset demands overlap heavily with what an AI-BOM records, but the statute never says "AI-BOM." US federal law doesn't mandate one either, whatever the roundups imply. The requirement arrives through contracts: RFIs like Project Linchpin, and enterprise procurement questionnaires.
What's the difference between an AI-BOM and an ML-BOM?
Mostly vocabulary. ML-BOM is CycloneDX's name for its machine-learning bill of materials capability; AI-BOM is the vendor-neutral term, and SPDX covers the same ground with its AI and Dataset profiles. In a vendor conversation, treat them as the same request: a machine-readable inventory of models, data, and AI dependencies.
Which format should we pick?
The one your existing SBOM pipeline already emits. CycloneDX shops should use the 1.6 ML-BOM; SPDX shops should use the 3.0 profiles. Both cover the fields that matter, both are open standards with active working groups, and format debates are usually a stalling tactic.
Do MCP servers really belong in an AI-BOM?
Yes. An MCP server is a runtime dependency with its own supply chain, and scanners have started listing MCP connections right alongside models and datasets. If an agent can call it, inventory it.