What is an AI BOM? The AI Bill of Materials, Explained

A Software Bill of Materials tells you what's inside the software you ship. Snyk, Trivy, Grype, Dependabot — they all do roughly the same thing: parse requirements.txt or package.json, match library names against a CVE database, hand you a list.

None of them know what's inside a 5 GB .safetensors file you just pulled from Hugging Face. They scan torch and transformers. They skip the model weights, they skip the training data, and they skip the license file that says the weights aren't actually allowed in your commercial product.

An AI BOM — also written as AI SBOM, short for AI Bill of Materials — is the inventory format that closes that gap. It catalogs the weights, the training data, the licenses, and the framework dependencies behind an ML system, in a structure auditors and CI pipelines can both read.

The rest of this post covers what's actually in one, how OWASP CycloneDX and SPDX represent it, where the EU AI Act fits in, and how to generate one from the command line.

1. Why traditional SBOMs miss ML

SBOM and Software Composition Analysis tools operate at the package-manager level. They parse manifest files (package.json, Cargo.toml, requirements.txt) and cross-reference library names against CVE databases. That works for the parts of an ML system written in Python. It misses the parts that aren't.

Three structural gaps:

A. Model weights are programs

A legacy PyTorch weight file (.pt or .bin) isn't a passive blob of floats. It's a ZIP archive containing a pickle stream that tells Python how to reconstruct tensor objects — and the pickle interpreter runs that stream as instructions on a stack-based virtual machine. Anything embedded in the stream that the interpreter can execute will execute, before any inference happens. We covered the bytecode mechanics in How to detect malware in a PyTorch pickle file. Standard SBOM tools treat those weight files as binary assets and walk past them.

B. Training data isn't in any manifest

A regular application is defined by its source plus its libraries. An ML model is defined by its code plus the data it saw. If a model was trained on copyrighted scrapes, on poisoned inputs, or on a private customer's data that shouldn't have been there, that risk lives in the dataset lineage — not in any Python package. Traditional SBOMs have no fields for dataset origin, licensing, or preprocessing hashes, because traditional software doesn't have a training-data step.

C. Licenses are declared in model cards, not packages

Model licensing is its own mess. Some weights are Apache 2.0 or MIT. Others are open-weights with non-commercial restrictions (Creative Commons CC-BY-NC), custom community licenses (Meta's Llama 3 and Llama 4 Community License Agreements), or field-of-use clauses that ban specific industries. The license text lives in the model card on Hugging Face or in a LICENSE file inside the model repo — not in requirements.txt — so an SCA scanner has nothing to cross-reference. The first time most teams notice is when legal reviews the deployed app.

2. SBOM, ML-BOM, AI-BOM: what the terms actually mean

Four names get used interchangeably across vendor docs and standards bodies for what's largely the same artifact: SBOM, AI BOM, AI SBOM, and ML-BOM. They overlap heavily, the boundaries are still being drawn, and which one shows up depends mostly on which tooling you start from. The short version:

• SBOM (Software Bill of Materials) is the original term, defined for traditional software dependencies. NTIA's 2021 minimum elements memo is the canonical reference. SBOMs don't cover model weights, datasets, or model licenses.
• ML-BOM (Machine Learning Bill of Materials) is the term CycloneDX used historically for its ML extensions. It still appears in older spec documents and tooling. Scope: model weights, training data, model card metadata.
• AI BOM / AI SBOM (AI Bill of Materials) is the umbrella that's now winning out across CycloneDX, SPDX, and most vendor documentation. In some literature it's strictly synonymous with ML-BOM; in other literature (Manifest, FOSSA, MITRE) it's drawn wider — ML-BOM plus the LLM-system surfaces: prompt templates, retrieval corpora, agent tool manifests.

This post treats AI BOM as the umbrella. ML-BOM is a subset that focuses on the model-weights and training-data scope; AI BOM also covers the system surfaces wrapped around a model in production. The terms are converging — most tooling now ships under "AI BOM" branding regardless of the underlying schema.

3. What goes in an AI BOM

At the model level, an AI BOM covers six surfaces. Some overlap with traditional SBOM fields (frameworks, hashes, licenses); the rest are ML-specific and don't have an obvious analog in the older standards.

4. Beyond model weights: the broader AI surface

The six surfaces above are the model-centric scope — the ML-BOM core. Production AI systems sit inside wrappers that an honest AI BOM should also account for. We won't go deep on each here; each warrants its own post. The high-level map:

• LLM application stack. System prompts, prompt templates, and few-shot examples are effectively configuration that shapes model behavior. Versioning and hashing them belongs in an AI BOM the same way framework versions belong in an SBOM. Fine-tuning datasets and adapter weights (LoRA, QLoRA) are first-class components that need their own lineage entries.
• Retrieval-Augmented Generation (RAG). A RAG system is the model plus its corpus. The corpus matters for licensing (you can't ship a product that retrieves from copyrighted text you don't have rights to), for security (poisoned documents can steer outputs), and for compliance (the EU AI Act's "training content summary" arguably extends to retrieval content for some deployments). Vector store contents, embedding model identity, chunking strategy, and document-source manifests are all in scope.
• Agent toolchains. When a model is wired to external tools — function calls, MCP servers, browser automation, code execution sandboxes — the tool definitions become part of the system's effective capability surface. Cataloging which tools are exposed, with which permissions, against which model is the agent-era equivalent of cataloging library dependencies.
• Training pipeline and data lineage. For organizations training or fine-tuning their own models, an AI BOM that stops at the weight file misses the upstream story: the raw data sources, preprocessing steps, augmentation, deduplication, and human feedback (RLHF / DPO) datasets. This is where the dataset-card discipline from Hugging Face's dataset_info.json and the data-card work from Google Research start to feed into BOM standards.
• MLOps registry adjacency. If you already run MLflow, Weights & Biases, or a managed registry (Vertex AI Model Registry, SageMaker Model Registry), much of this metadata is already captured — just in registry-specific formats. An AI BOM doesn't replace those tools; it gives you a portable, standards-based export that lawyers, auditors, and downstream consumers can read without API access to your stack.
• Supply-chain provenance. SLSA, sigstore, and in-toto attestations cover the "was this artifact built the way it claims to be built" question. AI BOM and provenance metadata are complementary — the BOM tells you what's inside, the attestation tells you the build chain is trustworthy.

5. CycloneDX and SPDX

Two standards carry AI BOM data today: OWASP CycloneDX and SPDX. Both extended their schemas to handle ML; the practical difference is which one your downstream consumer already accepts.

CycloneDX (v1.5 / v1.6)

CycloneDX added ML support in v1.5 and refined it in v1.6 (released April 2024). Three things it does:

• A machine-learning-model component type — distinct from framework or library, so model weights aren't lumped in with the pip packages loading them.
• Model Card fields — task, training state (pretrained / fine-tuned), input/output specs, evaluation datasets, and quantitative performance metrics live in a structured modelCard block rather than free-form text.
• Datasets as components — training and evaluation datasets get their own component entries with hashes, licenses, and classification tags, then link back to the model via the standard dependency graph.

Abbreviated CycloneDX v1.6 representation of a model weight file:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e07892b-8a8b-4a52-b883-70f2de445100",
  "version": 1,
  "components": [
    {
      "type": "machine-learning-model",
      "name": "bert-base-uncased",
      "purl": "pkg:huggingface/google-bert/bert-base-uncased@86b5e0934494bd15c9632b12f734a8a67f723594",
      "description": "Bidirectional Encoder Representations from Transformers",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "097417381d6c7230bd9e3557456d726de6e83245ec8b24f529f60198a67b203a"
        }
      ],
      "licenses": [
        {
          "license": { "id": "Apache-2.0" }
        }
      ],
      "modelCard": {
        "modelParameters": {
          "approach": { "type": "supervised" },
          "task": "Masked Language Modeling"
        },
        "quantitativeAnalysis": {
          "performanceMetrics": [
            { "type": "SQuAD-v1.1-F1", "value": "88.5" }
          ]
        }
      }
    }
  ]
}

Two things to note. The model's identity uses a Hugging Face purl pinned to a commit hash — cleaner than a fabricated semver, because HF artifacts don't have one. And the performance metric is named by benchmark (SQuAD 1.1 F1), not a bare score, because "F1 = 88.5" with no eval context is meaningless.

SPDX 3.0

SPDX shipped a modular rewrite in version 3.0 (April 2024). The base schema covers traditional software cataloging; an optional AI Profile layers on top with elements for training parameters, hardware requirements, model architecture, and dataset lineage. The relationship vocabulary added trainedOn and fineTunedOn so weights can be linked back to data without inventing custom fields.

Both formats work. CycloneDX tends to win in CI pipelines because the JSON is compact and the tooling is lightweight; SPDX shows up more in enterprise procurement and government supply-chain contracts where it's already the default ask.

6. Where regulation pushes on this

An AI BOM is useful on its own merits; what makes it urgent is that the regulatory regimes coming online ask for the same data points the BOM already structures. A few worth knowing:

EU AI Act

The Act is the binding framework here — it entered into force in August 2024 and phases in obligations through 2027. Two parts of it map cleanly onto an AI BOM:

• General Purpose AI (GPAI) providers must publish a "sufficiently detailed summary" of the training content and maintain technical documentation covering model architecture, training and testing processes, and evaluation results.
• High-risk system providers (healthcare, employment, critical infrastructure, biometrics) must keep technical documentation covering the data used, the risk management process, and the system's accuracy and robustness characteristics — produced on request to regulators.

An AI BOM isn't named in the Act, but it's one of the cleanest ways to assemble the evidence the Act asks for. Treat it as a substrate the legal team can sit on top of, not as the compliance artifact itself.

NIST AI Risk Management Framework

NIST released AI RMF 1.0 in January 2023 and added the Generative AI Profile in July 2024. It's voluntary, but federal procurement increasingly cites it, and it has a long shelf life precisely because it's not tied to any single administration. The "Map" function calls for cataloging AI components, dependencies, and data provenance — the same surfaces an AI BOM covers.

US federal and state

The federal posture in the US has shifted more than once. At the federal level, the current memo is OMB M-25-21 (April 2025, "Accelerating Federal Use of AI through Innovation, Governance, and Public Trust"), which rescinded and replaced the Biden-era M-24-10. It still requires federal agencies to maintain AI use-case inventories, though with looser definitions than the prior memo. State-level laws are where the sharper documentation obligations live today — most notably the Colorado AI Act (effective mid-2026) covering high-risk AI in employment, lending, and healthcare, and New York City Local Law 144 (in force since July 2023) requiring bias audits and notice for automated employment-decision tools.

7. Generating one from the command line

You don't write an AI BOM by hand any more than you write an SBOM by hand. AIsbom is an Apache 2.0 CLI that disassembles pickle bytecode, parses SafeTensors and GGUF binary headers, and emits a BOM in either CycloneDX or SPDX format.

Install

pipx keeps it isolated from your system Python:

pipx install aisbom-cli

Scan a Hugging Face model

The CLI reads binary headers over the wire using HTTP Range requests, so you don't pay the bandwidth cost of pulling a multi-gigabyte weight file just to inspect it:

aisbom scan hf://google-bert/bert-base-uncased

Export

Default output is a terminal-readable risk summary. To get a CycloneDX v1.6 JSON file:

aisbom scan hf://google-bert/bert-base-uncased --format cyclonedx --output sbom.json

Or an SPDX 2.3 JSON-LD document for procurement workflows:

aisbom scan hf://google-bert/bert-base-uncased --format spdx --output sbom.spdx.json

Wire it into CI

The GitHub Action runs the scan on every PR that touches a model file and posts the results as a single, idempotent PR comment:

name: Model Compliance Scan
on: [pull_request]

permissions:
  contents: read
  pull-requests: write

jobs:
  scan-models:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: Lab700xOrg/aisbom@v1
        with:
          directory: models/

8. Frequently asked questions

What is an AI BOM (AI Bill of Materials)?

An AI BOM is a structured inventory of an ML system's components: model weights, training and evaluation datasets, licenses, framework dependencies, and security audit results. It serves the same role as a Software Bill of Materials, extended to the surfaces that traditional SBOMs don't cover.

Is "AI BOM" the same thing as "AI SBOM"?

In practice, yes. Both terms describe the same artifact and are used interchangeably across CycloneDX, SPDX, and vendor documentation. "AI BOM" is the shorter form; "AI SBOM" reads as an explicit extension of SBOM.

Why doesn't a regular SBOM cover ML systems?

Regular SBOM tools work at the package-manager level. They catalog Python and JavaScript libraries by cross-referencing manifest files against CVE databases. They don't read model weight files, they don't represent training datasets, and they can't surface license terms that live in model cards rather than package metadata.

Does the EU AI Act require an AI BOM?

The Act does not require an AI BOM by name. It requires technical documentation covering training data summaries, model architecture, evaluation results, and risk management — the data points an AI BOM structures. Producing one is among the cleanest ways to satisfy those obligations.

9. Try it

Skip the bytecode walking — AIsbom does it for you. One command, no signup:

pipx run --spec aisbom-cli aisbom scan hf://google-bert/bert-base-uncased

For the underlying mechanics of how the scanner reads a pickle stream without executing it, see How to detect malware in a PyTorch pickle file.