The AI Bill of Materials conversation has finally moved past the "we should have one" phase and into implementation. CycloneDX shipped ML components in version 1.5 back in 2023, SPDX 3.0 added an AI profile, and the NTIA and EU AI Act both pushed expectations that AI systems should come with machine-readable component inventories. 2026 is the year where organizations actually have to produce, consume, and verify these documents, and the gaps in the standards are becoming operationally obvious.
What does an AI-BOM actually need to describe?
An AI-BOM needs to describe components, data, and context. Components include the model weights, the model architecture, the inference runtime, the tokenizer, the frameworks, and the orchestration tooling. Data includes the training datasets, the fine-tuning datasets, the evaluation datasets, and any reference or retrieval corpora. Context includes the hardware, the quantization, the prompts or system instructions if they are part of the shipped artifact, and the behavioral guardrails.
The reason all three categories matter is that an AI system's security properties depend on all of them. A model's weights are one attack surface. Its training data is another. Its inference-time context, including retrieval sources and tool definitions, is a third. An AI-BOM that only describes weights is an SBOM wearing a new label. An AI-BOM that covers all three categories is actually useful for incident response and compliance.
In practice, the components category is the most mature, because it maps naturally onto existing SBOM tooling. Data is harder because datasets are often proprietary, large, or derived, and their provenance is frequently unclear. Context is the hardest because it changes at runtime, which means an AI-BOM is a point-in-time snapshot that may be stale the moment it is published.
How do CycloneDX ML components and SPDX 3.0 AI profile compare?
CycloneDX ML components, introduced in CycloneDX 1.5 and refined through 2024 and 2025, add model cards, training datasets, quantitative analysis, and considerations (ethical, technical, and legal) to the existing component structure. It is the most mature format for ML-BOM as of 2026 and has the broadest tooling support, including generators from Hugging Face models and converters from existing ML experiment trackers.
SPDX 3.0, released in 2024, introduced a profile-based architecture where AI is one of several domain profiles alongside Security, Build, and others. The AI profile captures model metadata, training data references, and evaluation criteria. It is more expressive than CycloneDX in some dimensions (particularly around hyperparameters and evaluation) but has narrower tool support.
In practice, most organizations producing ML-BOMs in 2026 pick CycloneDX for tooling reasons and SPDX for compliance posture when regulators specifically reference SPDX. Both formats are convergent enough that translation between them is tractable, though lossy at the edges. The right answer for a senior engineer is to emit both if your audience requires it, and to treat the generation process as the source of truth rather than the output format.
What does the EU AI Act actually require in terms of documentation?
The EU AI Act, phased in through 2025 and 2026, requires providers of high-risk AI systems to maintain technical documentation that covers system design, training and validation data, risk assessment, and performance metrics. It does not prescribe a specific format, but the required contents map cleanly onto CycloneDX ML components and SPDX AI profile fields.
The Act's general-purpose AI obligations, which apply to foundation model providers, require disclosure of training data summaries, energy consumption, and evaluations against systemic risk. These are not natural fits for existing BOM formats, and most providers are publishing them as separate model cards with BOM cross-references. The practical pattern is: BOM for components and dependencies, model card for evaluation and risk disclosure, and a cross-reference between them.
US regulation in 2026 is less prescriptive but converging. The NIST AI Risk Management Framework continues to reference BOM-style documentation, and sector-specific regulators in financial services and healthcare increasingly require model inventories. Organizations doing business across jurisdictions are standardizing on the EU format as the high-water mark.
Where do AI-BOMs still fall short in practice?
Three gaps stand out. First, dataset provenance is underspecified. Both CycloneDX and SPDX let you name a dataset, but neither requires verifiable provenance, and in practice most training datasets in 2026 are described as "CommonCrawl slice from date X" or "internal data," which is not actionable for downstream users. Second, context and prompts are not captured consistently. A model shipped with a system prompt or tool configuration behaves differently than one shipped raw, but current formats do not treat that as part of the component. Third, dynamic retrieval sources are not captured at all. RAG systems pull from live corpora, which means the BOM describes the static components but not what the model actually reads at inference.
These gaps are not format failures, they are scope decisions. BOMs were designed to describe shipped artifacts, and AI systems have runtime surfaces that do not fit that model. Some industry efforts are attempting to extend BOMs with "context declarations" and "retrieval manifests," but none have reached standardization as of early 2026.
For practitioners, the pragmatic answer is to treat the BOM as necessary but not sufficient. Pair it with runtime attestation of actual retrieval sources, runtime signing of system prompts, and continuous monitoring of the model's behavior against the declared specification.
How should organizations actually produce AI-BOMs today?
Automate generation at training and packaging time, not after the fact. Manual BOMs are always wrong. Integrate BOM generation into your model packaging pipeline, the same way you integrate SBOM generation into container builds. Tools like Hugging Face's huggingface_hub metadata, CycloneDX generators, and custom emitters from ML experiment trackers cover the common cases.
Sign the BOM with the same key you sign the model. An unsigned BOM is a claim, not evidence. Use Sigstore or equivalent to tie the BOM to an identity that produced it, and use in-toto attestations to tie the BOM to the build process. This closes the loop between "we say the model has these components" and "the components were actually what got trained."
Verify BOMs on consumption. Treat incoming third-party models the way you treat incoming third-party packages: check the signature, check the components against a policy, and refuse to deploy models whose declared components contain known-vulnerable dependencies or disallowed datasets.
What will change in 2026 and beyond?
Two changes are likely. First, dataset provenance will get stricter. Regulators are pushing for verifiable training data attestations, and research efforts on data provenance (such as the Data Provenance Initiative) are providing tooling that makes this tractable for new models. Retrofitting existing models is harder, but new releases will carry stronger provenance.
Second, BOMs will extend into runtime. The current static format will be augmented with runtime attestations that capture what the model actually loaded, what retrieval sources it actually read, and what tools it actually invoked. This moves the BOM from a packaging artifact to a continuous attestation, which is much more useful for security operations.
A third likely change is consumer-side policy. Today most AI-BOM conversations happen on the producer side, generating the document. By late 2026 and into 2027, expect consumers (enterprises deploying third-party models) to require specific BOM content as a condition of procurement, similar to how SBOM requirements have shifted software procurement. The pressure will force producers to improve dataset provenance and runtime attestation, because contracts will require it.
How Safeguard.sh Helps
Safeguard.sh implements AI-BOM as a first-class continuously-maintained inventory, not a one-time packaging artifact. We generate CycloneDX ML component BOMs automatically from model training and packaging pipelines, and we extend them with runtime attestations that capture actual retrieval sources, loaded weights, and invoked tools. Eagle model-weight scanning verifies the integrity and safety of every model artifact before it is registered in the BOM, pickle detection catches unsafe serialization formats, and model signing/attestation ties every declared component to a verifiable identity. Griffin AI applies reachability analysis at 100-level depth across the full AI supply chain, so a vulnerable dependency four layers deep in your inference runtime is surfaced, not lost. Lino compliance maps your BOMs to EU AI Act and NIST AI RMF requirements automatically, and container self-healing ensures your inference deployments roll back cleanly when a BOM-flagged issue reaches production.