AI BOM vs SBOM — Scope, Fit, and Limits

01What an AI BOM is

An AI BOM is not a replacement for an SBOM. It is a superset. The software stack an AI system runs on still needs a conventional SBOM; the AI BOM adds the model, the data, and the runtime configuration — the three places where AI-specific risk actually lives.

A traditional SBOM answers one question well: which known-vulnerable components am I shipping? It works because a package identifier resolves deterministically to a version, and a version resolves to a CVE. That chain is what made SBOM operationally useful rather than merely bureaucratic.

An AI system breaks that chain. Its behaviour is not determined by its source code. It is determined by a set of weights produced from a training corpus under a training regime, then shaped at inference time by a system prompt, a retrieval corpus, a guardrail configuration, and a tool surface. None of those are packages. None of them have CVEs. An SBOM of an AI product will faithfully list PyTorch, CUDA, transformers, and vLLM — and tell you nothing about the thing that actually makes decisions.

02Scope comparison

Grey is the portion your existing SBOM programme already covers. Everything in petrol is what an AI BOM adds.

One document, four inventories. CycloneDX carries all four in a single file — the AI components are additional component types, not a parallel artifact.

03The four layers, field by field

What a defensible AI BOM actually has to contain in each layer.

Existing scope

Software BOM

Component name, version, supplier
PURL or CPE identifier
Cryptographic hashes
Declared and concluded licence
Dependency relationships
Inference stack: CUDA, PyTorch, serving runtime

Added

Model BOM

Model name, version, artifact hash
Architecture and parameter count
Serialisation format and quantisation
Base model provenance and fine-tune lineage
Adapters, merges, distillation steps
Evaluation results and known limitations
Intended and out-of-scope use

Added

Data BOM

Datasets used for pretraining, fine-tuning, evaluation
Source, collection method, date range
Licence and redistribution terms
Presence of PII, PHI, or regulated data
Curation, filtering, and deduplication applied
Consent or lawful basis where applicable

Added

Runtime BOM

System prompt and version
Guardrail and content-filter configuration
Retrieval corpus and embedding model
Tool and function-calling surface
Agent scope, autonomy level, human gates
Decoding parameters that affect behaviour

Why runtime belongs in the BOM. A pinned package at a given hash behaves identically everywhere. Identical model weights do not. Change the system prompt, the retrieval corpus, or the tool set and you have materially changed the system's behaviour without changing a single artifact hash. An inventory that stops at the weights describes an artifact, not a system.

04Key structural differences

These are the differences that change how you operate the programme, not just what you file.

Dimension	SBOM	AI BOM
Unit of composition	Code packages with linear versions	Models, datasets, prompts — artifacts that do not version linearly
Identifier to risk	PURL or CPE resolves deterministically to CVE and KEV	No equivalent registry. Nearest analogues are MITRE ATLAS (tactics, not instances) and OWASP LLM Top 10 (categories)
Composition shape	Acyclic, fully enumerable dependency tree	Lineage chain: base → fine-tune → merge → quantise → adapter, with a hard visibility wall at the base model
Immutability	Version plus hash fixes behaviour	Same weights, different behaviour under different prompt, retrieval corpus, or decoding parameters
Meaning of "vulnerable"	Boolean match against an affected version range	Distributional: poisoned training data, weight backdoors, membership inference, prompt injection surface, model extraction
Data as a component	Not represented	First-class. Licence contamination, privacy exposure, and poisoning risk all live here
Automation maturity	Mature: generation, ingestion, diffing, VEX, continuous monitoring	Generation is emerging; automated match-to-known-bad does not yet exist
Primary consumer	PSIRT and vulnerability management	Model risk governance, procurement, privacy counsel, regulatory affairs

05Where it applies — and where it does not

The honest read. An AI BOM is a transparency and governance artifact. Treating it as a vulnerability-management artifact will disappoint you.

Where an AI BOM earns its keep

Third-party model procurementThe AI equivalent of asking for a SOC 2. Establishes what you are actually buying before it is embedded in a product.
Regulatory technical documentationSupplies the inventory backbone for EU AI Act Annex IV, ISO/IEC 42001 clause evidence, and NIST AI RMF Map function outputs.
Licence and IP exposureThe only systematic way to surface training-data licence contamination and redistribution constraints before legal discovers them.
Privacy and data-residency reviewMakes PII, PHI, and cross-border training data visible to counsel rather than tacit in an ML team's notebooks.
Incident scopingWhen a base model or public dataset is reported as poisoned or backdoored, the lineage record is what lets you answer "are we affected" in hours.
Change control and driftA diffable record of prompt, guardrail, and corpus changes — the AI analogue of configuration management.
Deprecation and end-of-supportTracks which products depend on a model version the provider is about to retire.

Where it does not help — yet

Automated vulnerability matchingThere is no CVE for a biased checkpoint or a trojaned weight file. Nothing downstream of the AI BOM will page your on-call.
Closed-weight commercial modelsFor a hosted frontier API you will get a name, a version string, and a model card. Training data and pretraining regime will not be disclosed. The Data BOM is largely empty by construction.
Behavioural assuranceAn inventory does not tell you the system is safe. Red-teaming, evaluation harnesses, and runtime monitoring do that work; the AI BOM only records that they happened.
Classical ML with no external dependenciesA logistic regression trained on your own clinical data is well served by existing design controls. A full AI BOM is documentation overhead with little residual risk reduction.
Agentic runtime riskThe BOM captures the declared tool surface. It does not capture what the agent actually did at 3am. That is a telemetry and audit-log problem.
Substituting for model risk managementAn AI BOM is an input to governance, not a governance programme. It answers "what is in it", never "should we ship it".

06Standards status

Two formats matter. Both are viable; the choice is driven by tooling and by who reads the file.

	CycloneDX	SPDX
Steward	OWASP; Ecma International standard (ECMA-424)	Linux Foundation; ISO/IEC 5962
Origin bias	Application security and supply-chain risk	Licence compliance and legal review
AI support	ML-BOM as a native component type	AI Profile and Dataset Profile in the 3.0 line
Current versions	1.7 is the latest and last release of the 1.x line; 1.6 remains the stable production target with the broadest tooling. An API-first 2.0 has been signalled.	3.0.1, with a 3.1 release candidate underway. The 3.0 line shipped April 2024 with an element-based model.
Notable 2026 additions	1.7 added data provenance and citations, patent and patent-family metadata, TLP distribution markers, and an expanded cryptography registry	3.0 restructured into profiles — Core, Software, Build, AI, Dataset, Security — on a JSON-LD foundation
Tooling	Dependency-Track, Grype, OWASP AIBOM Generator, most commercial SBOM platforms consume it natively	Strong in licence-compliance toolchains; AI-profile tooling is thinner
Practical call	Lower-friction default for a programme starting AI BOM work now	Correct extension if you already run SPDX deeply for licence reasons, and carries more weight in some regulatory filings

Do not maintain both. The recurring failure mode is a programme that emits CycloneDX and SPDX in parallel and keeps neither current. Pick one canonical internal format, convert on egress if a counterparty insists.

07Regulatory drivers

The framing that works with a regulated-industry board: an AI BOM is to the EU AI Act and ISO 42001 what an SBOM is to FD&C §524B and the Cyber Resilience Act — the machine-readable evidence artifact that makes downstream controls auditable.

Regime	What it wants	Which layer answers it
EU AI Act, Art. 11 and Annex IV	Technical documentation for high-risk systems, including design, training methodology, and datasets	Model BOM, Data BOM
EU AI Act, Art. 53 (GPAI)	Sufficiently detailed summary of training content	Data BOM
ISO/IEC 42001	AI system inventory, lifecycle and impact assessment evidence	All four layers
NIST AI RMF	Map function: establish context and catalogue AI system components	All four layers
FD&C §524B / FDA Feb 2026 guidance	Machine-readable SBOM, SPDF, security risk management, CVD	Software BOM today; Model and Data BOM where AI/ML is part of the device function
EU Cyber Resilience Act	SBOM for products with digital elements	Software BOM
Enterprise procurement	Vendor qualification evidence for AI components	Model BOM, Data BOM, Runtime BOM

Verify the AI Act date before citing it. Article 11 and Annex IV obligations for high-risk systems took effect 2 August 2026 under current law, but the proposed Digital Omnibus would defer them to December 2027 and was still in trilogue as of mid-2026. Confirm the position at time of use.

08Adoption path

A pragmatic sequence for an organisation that already runs an SBOM programme.

Inventory the AI systems first, not the componentsYou cannot produce an AI BOM for a system you have not acknowledged exists. Shadow AI in business units is the usual first finding.
Pick one canonical formatCycloneDX unless you have an existing SPDX licence-compliance investment. Document the decision so it is not relitigated quarterly.
Extend the existing SBOM pipeline rather than building a second oneSame generation step, same repository, same ingestion. AI components are additional component types in the same document.
Set a completeness floor, not a completeness targetDefine the minimum fields you will accept from an internal team and from a vendor. Expect the Data BOM to be sparse for closed-weight models and record that gap explicitly rather than leaving it blank.
Write it into procurement before you write it into engineeringThe vendor requirement drives the internal capability, not the reverse. Specify format, cadence, and completeness in the contract.
Trigger regeneration on material changeNew base model, new fine-tune, changed system prompt, changed retrieval corpus, changed tool surface. Not on a calendar.
Mark confirmed versus inferredFields derived from a model card are asserted by the supplier, not verified by you. Distinguish them in the record; an auditor will ask.
Connect it to a decisionAn AI BOM that no gate consumes is documentation theatre. Wire it to a procurement approval, a release gate, or a risk-acceptance record.

09References

Primary sources. Verify version numbers and effective dates at time of use — this space is moving quickly.

OWASP CycloneDX specification and Tool Center. Format specification, ML-BOM component types, and the tool ecosystem. cyclonedx.org
SPDX 3.0 specification, AI Profile and Dataset Profile. Linux Foundation. spdx.dev
OWASP GenAI Security Project — AI BOM guidance and AIBOM Generator. Field definitions and completeness scoring against Hugging Face model metadata.
MITRE ATLAS. Adversarial threat landscape for AI systems; the closest available taxonomy for AI-specific attack techniques. atlas.mitre.org
OWASP Top 10 for LLM Applications. Risk categories referenced throughout AI BOM tooling.
NIST AI 100-1, Artificial Intelligence Risk Management Framework. Map, Measure, Manage, Govern functions. nist.gov
ISO/IEC 42001:2023. Artificial intelligence management system requirements.
Regulation (EU) 2024/1689 (Artificial Intelligence Act). Article 11 and Annex IV technical documentation; Article 53 GPAI training-content summary. Check current status of the Digital Omnibus amendment.
FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, 3 February 2026 — supersedes the September 2023 and June 2025 versions and aligns to QMSR. fda.gov
CISA and NSA joint guidance on AI data security. Practices for securing data used to train and operate AI systems.