The conversation around AI bills of materials has matured past the initial enthusiasm and into the harder work of specification, tooling, and adoption. As of mid-2026, two formats have credible traction and a third is gaining ground, while the regulatory pressure under the EU AI Act and NIST AI RMF has given organizations an actual reason to care beyond marketing. This post covers where the standards stand and what to capture today.
Which formats are actually being used?
CycloneDX added ML-BOM support in version 1.5 and matured it through 1.6 and 1.7, and that specification now has the most production usage. It captures model metadata, training datasets, hyperparameters, framework dependencies, and a card-like description of intended use and limitations. SPDX 3.0 added an AI profile in late 2025 that covers similar ground from a different conceptual model, with stronger licensing semantics and weaker tooling. The MITRE-led AI-BOM effort produced a useful taxonomy but no widely-adopted serialization, and most of its concepts have flowed into the other two.
The practical answer in 2026 is CycloneDX ML-BOM if you need tooling and adoption, SPDX AI if you have strong SPDX existing infrastructure or licensing-heavy requirements, and a converter between them if you must satisfy multiple downstream consumers. The schemas have converged enough that mechanical conversion is viable for the common case.
What should an AI-BOM actually contain?
A useful AI-BOM captures three layers. The first is the model itself: identifier, version, weights hash, format, and the framework it runs in. The second is the supply chain: training datasets with provenance, base models if fine-tuned, the frameworks and runtime libraries, and the inference server. The third is the operational context: intended use, evaluation results, known limitations, and the cards that describe safety properties.
The minimal version that pays off immediately is the supply chain layer. Just knowing which version of which model is deployed against which inference server, with hashes, lets you answer the post-incident question of "are we affected" when an upstream vulnerability hits. The operational layer matters more for compliance and customer disclosure than for security response.
What about training data provenance?
Training data provenance is the part of the AI-BOM story that is genuinely unsolved. The spec slots exist, dataset identifiers, hashes, license terms, but the upstream ecosystem of dataset producers does not consistently provide them. Hugging Face has improved its dataset cards substantially, and the major foundation model providers now publish high-level training data summaries, but reproducible per-record provenance remains rare outside specific research projects.
The pragmatic posture is to capture what you have, mark what you do not, and treat dataset gaps as a risk indicator rather than a blocker. A model with full dataset provenance is a meaningfully lower-risk choice for regulated workloads than one without, and that signal alone is worth recording even when the records are incomplete. The CRA and AI Act consultation drafts both treat absence of provenance as a soft red flag, and that posture is likely to harden into hard requirements over the next two years.
How does AI-BOM intersect with regular SBOM?
The intersection is messier than the marketing diagrams suggest. An AI system has both classical software dependencies, the inference server, the framework, the operating system, the GPU drivers, and AI-specific artifacts, the model weights, the training data, and the evaluation harness. You need both kinds of BOM to describe the system completely, and most production tooling treats them as separate documents linked by reference.
This separation is correct conceptually but operationally painful, because the consumers of these documents typically want a single answer to "what is in this system." Most teams we work with maintain the two BOMs separately and stitch them together at report time. The CycloneDX 1.7 spec supports embedding ML-BOM content inside a regular SBOM, which is the cleanest way to ship a single artifact when downstream tooling supports it.
What should you start capturing in 2026?
If you ship AI features, start with model identifier, version, weights hash, framework, and inference runtime. That five-field minimum closes most of the immediate gap and is mechanizable from your deployment pipeline. Add training data references and evaluation results next, accepting that the data fields will be incomplete for non-internal models. Treat the document as a CI-generated artifact, signed and stored alongside your regular SBOMs, and surface it in your customer-facing transparency materials.
Do not wait for the standards to fully settle. The formats are stable enough that conversion is feasible, and the cost of starting late is higher than the cost of starting on the wrong schema.
How Safeguard Helps
Safeguard ingests CycloneDX ML-BOM and SPDX AI documents alongside regular SBOMs, and Griffin AI correlates AI-specific CVEs and zero-day disclosures against your deployed models and inference stacks. The reachability engine works the same way on AI infrastructure as on classical software, so an AI framework CVE in an unreachable code path gets deprioritized automatically. TPRM scores model providers on disclosure hygiene and CVE response time, including the major foundation model and inference-as-a-service vendors. Policy gates enforce AI-BOM completeness at deploy time, blocking model rollouts that lack required provenance fields, and zero-CVE base images for popular inference runtimes give you a clean foundation that survives audit scrutiny.