AI Bill of Materials (AI-BOM): Standards and Tooling in 2026

Software bill of materials — SBOM — became mainstream after the Executive Order 14028 on cybersecurity in 2021. It is now a standard procurement requirement for federal software and increasingly for regulated industries. AI systems extend this idea: they need a bill of materials that captures not only software components but also models, training datasets, evaluation datasets, and the relationships between them. The result is the AI Bill of Materials — AI-BOM, sometimes called ML-BOM.

This guide explains the current state of AI-BOM standards, the regulatory pressures that make AI-BOM useful in compliance work, and the small but growing tooling landscape. It is intentionally cautious about vendor recommendations: the AI-BOM tooling category is early, and most "AI-BOM" features today are extensions of SBOM tools rather than purpose-built systems. Where the buyer's-guide question is "which tool should I buy?", the honest answer in mid-2026 is "use SBOM tooling with AI extensions, and expect the category to consolidate over the next eighteen months."

Why AI-BOM matters for compliance

Three regulatory pressures push AI-BOM from a nice-to-have to a procurement requirement.

EU AI Act Article 11 and Annex IV require providers of high-risk AI systems to maintain technical documentation that includes a "general description of the AI system" along with "the provenance, scope, and main characteristics" of training, validation, and testing datasets, plus "the libraries, tools, and frameworks used." Annex IV (4) explicitly enumerates these requirements. An AI-BOM is the most mechanical way to satisfy them, because it produces a machine-readable record that maps to the Annex IV outline.

NIST AI RMF Map 4.1 in the AI RMF Playbook calls for organisations to maintain "an inventory of AI systems including their dependencies, data sources, and component versions." NIST SP 800-218A extends the Secure Software Development Framework to cover AI development practices, including model and dataset documentation.

ISO/IEC 42001:2023 Clause 8 and Annex A.6.1 require operational documentation of AI components and their lifecycle. The ISO/IEC 5259 series on data quality for analytics and machine learning is increasingly cited as the reference standard for dataset documentation within an AI-BOM.

These three obligations converge: a documented inventory of models, datasets, and dependencies is required under the EU AI Act for high-risk systems, expected under NIST AI RMF, and required under ISO/IEC 42001 certification.

CycloneDX ML-BOM v1.6

The CycloneDX project, hosted under the OWASP Foundation, has the most developed AI-BOM specification in production today. Its ML-BOM extension, formalised in CycloneDX v1.5 (2023) and refined through v1.6 (2024), supports component types specific to machine learning:

• Machine-learning model as a first-class component type, with metadata for model architecture, hyperparameters, training datasets, and performance metrics.
• Dataset as a component type, with metadata for source, governance, sensitive data classification, and consent provenance.
• Algorithm and library components for the training and inference frameworks.
• Considerations — a structured field for documenting ethical, fairness, safety, and environmental considerations.

The CycloneDX ML-BOM examples repository shows complete sample documents. CycloneDX is widely supported in SBOM tooling, and the ML-BOM extension reuses the same JSON schema and signing infrastructure (CycloneDX supports W3C VC and JWS signatures).

CycloneDX is an OWASP project. It is not an ISO or IETF standard. Its strength is breadth of tooling support; its weakness is that some compliance teams prefer formats backed by formal standards bodies.

SPDX 3.0 AI Profile

The Software Package Data Exchange (SPDX) project is hosted by the Linux Foundation and is recognised as ISO/IEC 5962:2021. SPDX 3.0, released in April 2024, introduced an AI Profile that adds AI-specific element types alongside the existing software-package descriptors:

• AIPackage — represents an AI model with attributes for model architecture, training methodology, intended use, and limitations.
• DatasetPackage — represents a dataset with attributes for data collection process, anonymisation, sensitive personal information, and data quality.
• EnergyConsumption — a structured field that aligns with EU AI Act Article 11 expectations for energy and resource use disclosure.

SPDX 3.0 also introduced a Build Profile (provenance), Security Profile (vulnerabilities), and Licensing Profile (rights). The combination produces a single document that can describe the full AI software supply chain.

The SPDX online specification documents every field. The Linux Foundation maintains a reference implementation and integrations with SPDX Online Tools.

SPDX is the more formally-standardised option. CycloneDX is the more widely-tooled option. As of 2026 most teams that need an AI-BOM today choose CycloneDX for tooling availability and revisit SPDX adoption when their main SBOM stack supports it.

Where AI-BOM tooling stands in 2026

The honest summary: AI-BOM is real as a specification, real as a regulatory expectation, and immature as a standalone tooling category. The tooling falls into four groups.

Group 1 — SBOM tools with AI extensions. Most established SBOM platforms now generate CycloneDX ML-BOM output. Anchore Enterprise, Snyk, JFrog Xray, and Sonatype Lifecycle all advertise AI-BOM features. Their AI-BOM coverage today is mostly model and library inventory; dataset coverage is thinner.

Group 2 — ML platforms with built-in BOM export. MLflow 2.x, Weights & Biases, and DVC each maintain experiment and model registries that can be exported as CycloneDX-compatible documents through community plugins. These are not standards-conformant out of the box but produce the underlying data needed.

Group 3 — Compliance platforms with AI-BOM features. A small number of AI governance and compliance platforms include AI-BOM generation as part of their model inventory. In our directory, Lasso Security is the vendor that explicitly documents ai-bom capability. Other governance vendors collect similar data but do not yet emit standards-conformant AI-BOM documents — see the /best/ai-governance-platforms collection.

Group 4 — Open-source CLI tools. CycloneDX CLI, cyclonedx-python, and SPDX online tools generate documents from manifests, lockfiles, and registry exports. These are the building blocks most ML platforms ultimately call.

This is why we have not published a /best/ai-bom-tools ranking: a category with one purpose-built vendor and three groups of adjacent tooling does not yet have a defensible top-N comparison. We will publish one when at least four vendors document AI-BOM capability with public output examples.

What an AI-BOM should contain

Whether produced as CycloneDX ML-BOM or SPDX 3.0 AI Profile, a useful AI-BOM contains the same essential elements. The following list is derived from the union of EU AI Act Annex IV, NIST AI RMF Map 4.x, and ISO/IEC 42001 Clause 8 expectations.

Identification. A unique identifier for the AI system, version, and the producer organisation. CycloneDX uses PURL for components.

Models. For each model: architecture family, base or fine-tuned status, training framework, hyperparameters, evaluation metrics, intended use, known limitations.

Datasets. For each dataset: provenance, licence, collection methodology, demographic composition where relevant, anonymisation methods, dataset version hash.

Software components. All libraries, frameworks, and runtimes used in training and inference, with versions and licences.

Build provenance. How the model was built — commits, build environment, training run identifiers, SLSA attestations where available.

Considerations. Ethical, fairness, safety, environmental and energy use disclosures.

Risk and mitigation links. References to risk-management records and mitigations — the link from the AI-BOM into the rest of the governance system.

Cryptographic integrity. Document signing so the AI-BOM itself is tamper-evident.

The CycloneDX AI-BOM authoritative guide and the SPDX AI Profile model are the operative references.

Practical recommendations for compliance teams

Choose the format your existing stack supports. If your SBOM tooling is on CycloneDX, extend with ML-BOM. If you operate in a Linux Foundation ecosystem already on SPDX, adopt the AI Profile. The decision matters less than consistency.

Generate AI-BOM at build time, not at audit time. Like SBOM, AI-BOM is most useful when generated automatically as part of the model build pipeline. Storing AI-BOM documents alongside model artefacts in your registry creates a defensible historical record.

Sign the AI-BOM. Both CycloneDX and SPDX support signing; unsigned AI-BOM documents have limited evidentiary value. Sigstore Cosign is the most common signing tool for both.

Mirror to long-term storage. AI-BOM documents are evidence under EU AI Act Article 12. Mirror them to your governance platform, your evidence repository, and an immutable archive (S3 Object Lock or equivalent).

Re-generate when models update. Each fine-tune, each evaluation run, each dependency update should produce a new AI-BOM version. The history is the audit trail.

Coordinate with vendor due diligence. When you procure an AI system from a third party, request the supplier's AI-BOM. The /guides/ai-compliance-vendor-due-diligence framework and the /guides/ai-vendor-independence guide describe how to make AI-BOM production a contractual requirement.

Why we did not publish a /best/ai-bom-tools ranking

This is the honest answer to a frequently-asked question. Of the 55 vendors we track in our directory as of April 2026, only one — Lasso Security — publicly documents ai-bom capability as a primary feature. Several SBOM tools have credible AI-BOM extensions, but they are SBOM-first products. Producing a "Top 5 AI-BOM Tools" ranking from this material would require either (a) including SBOM tools that are not AI-specific, or (b) inventing distinctions that do not exist in the public record.

Neither serves buyers. We will publish an /best/ai-bom-tools collection when there are at least four vendors with verifiable AI-BOM-as-primary-product positioning. Until then this guide is the procurement reference.

Recommended supporting reading

• CycloneDX ML-BOM specification — authoritative source.
• SPDX 3.0 AI Profile — ISO-aligned alternative.
• NIST SP 800-218A — secure AI development practices.
• EU AI Act Annex IV — technical documentation requirements.
• /frameworks/eu-ai-act, /frameworks/iso-iec-42001, /frameworks/nist-ai-rmf — framework reference pages.
• /guides/ai-impact-assessment-template — how AI-BOM data feeds impact assessments.

Bottom line

AI-BOM is settled as a specification (CycloneDX ML-BOM and SPDX 3.0 AI Profile) and as a regulatory expectation (EU AI Act Annex IV, NIST AI RMF Map 4.x, ISO/IEC 42001 Clause 8). It is unsettled as a tooling category, with one purpose-built vendor and three groups of adjacent tooling. The right move for compliance teams in 2026 is to generate AI-BOM at build time using existing SBOM tooling extended with AI components, sign it, and mirror it to long-term storage. Revisit the dedicated tooling category in twelve to eighteen months.