What Is an AI-BOM and How to Generate One

What an AI-BOM is

An AI Bill of Materials is a structured inventory of everything an AI system is built from. Not just the Python packages, but the datasets that trained it, the weight files it loads, the base model it was fine-tuned from, the prompts and guardrails wrapped around it, and the services it calls at inference time.

The reason this needs its own document is that a model's behavior is not determined by its source code. Two training runs over the same code and different data produce different systems. If a corpus contains subtle poisoning perturbations, the weights that come out will pass every build test and then behave differently on a specific trigger in production. Nothing in a traditional SBOM would record that the corpus was involved.

AI-BOM vs SBOM

An AI-BOM does not replace your SBOM. Your inference service still ships ordinary libraries with ordinary CVEs. It covers the layer underneath, where the risks are statistical rather than syntactic.

Already have an SBOM to explore? The SBOM Visualizer handles SPDX 2.3 and CycloneDX files.

What goes inside one

An enterprise-grade AI-BOM covers four areas. Skip any one of them and the document stops being useful during an incident.

CycloneDX vs SPDX 3.0.1

Two open standards cover this ground. OWASP CycloneDX added machine-learning-model and data as first-class component types in 1.5, with a detailed modelCard structure carrying model parameters, quantitative analysis, and considerations. SPDX 3.0.1 moved to an RDF graph model serialized as JSON-LD, where an AIModel element and a Dataset element are joined by explicit Relationship assertions.

Both are fine. Choose on what the document is for rather than on technical merit.

How to generate one

Hand-written AI-BOMs go stale within a sprint. The document has to come out of the pipeline that produces the model, at the four points below.

Emitting the model component

The core of it is small. Hash the weights, attach the dataset reference and the ancestor, and write the component out. Call this from your checkpoint callback so the hash always matches the file that was actually written.

import hashlib, json, datetime

def sha256(path):
    h = hashlib.sha256()
    with open(path, "rb") as f:
        for chunk in iter(lambda: f.read(1024 * 1024), b""):
            h.update(chunk)
    return h.hexdigest()

def model_component(weights_path, name, version, base_model, dataset_ref, hyperparams):
    return {
        "bom-ref": f"model-{name}-{version}",
        "type": "machine-learning-model",
        "name": name,
        "version": version,
        "hashes": [{"alg": "SHA-256", "content": sha256(weights_path)}],
        "licenses": [{"license": {"id": "Apache-2.0"}}],
        "pedigree": {"ancestors": [base_model]},
        "modelCard": {
            "modelParameters": {
                "approach": {"type": "supervised"},
                "task": "text-generation",
                "datasets": [{"ref": dataset_ref}],
            },
            "properties": [
                {"name": k, "value": str(v)} for k, v in hyperparams.items()
            ],
        },
    }

# Call this from your checkpoint callback, not from a script you run later.
bom = {
    "bomFormat": "CycloneDX",
    "specVersion": "1.7",
    "version": 1,
    "metadata": {"timestamp": datetime.datetime.utcnow().isoformat() + "Z"},
    "components": [model_component(...)],
    "dependencies": [],
}
print(json.dumps(bom, indent=2))

If you would rather not write the emitter, cdxgen and the OWASP CycloneDX tooling can produce ML-BOM documents from a project, spdx-tools and the SPDX 3 Python SDK cover the SPDX side, and OWASP Dependency-Track will ingest and track the results over time.

Minimum viable AI-BOM

If you are starting from nothing, capture these ten fields first. They are the ones an auditor asks for and the ones that make an incident traceable.

Who asks for this