What Is an AIBOM (AI Bill of Materials)? A CISO’s Guide

An AIBOM (AI Bill of Materials) is a machine-readable inventory of everything an AI system is built from — every model, dataset, and software dependency, each tagged with its license, version, and provenance. It is the SBOM idea extended to the parts of the stack a traditional software bill of materials never captured: the weights and the training data. If you ship anything with a model in it, someone is going to ask you for one.

What is an AIBOM?

A Software Bill of Materials (SBOM) answers a simple question: what is in this software? It lists the packages, versions, and licenses so that when a vulnerability like Log4Shell lands, you can tell in minutes whether you are exposed. An AI Bill of Materials answers the same question for an AI product — but an AI product has components an SBOM was never designed to describe. The base model, the fine-tuning datasets, the embeddings, the inference framework, and the licenses attached to each of those are all part of the real supply chain, and none of them show up in a package.json.

So an AIBOM is best understood as an SBOM plus the AI-specific layers: models, datasets, and their licenses and lineage, sitting alongside the ordinary code dependencies. The point is the same as an SBOM — answer “what is in this thing, and can I trust each piece” — for a system where the riskiest components are no longer just code.

Why an AIBOM matters now

• Customer due diligence. Enterprise buyers and their security teams have started asking vendors, in writing, “what model, trained on what data, under what license?” Answering that in a Google Doc works until you have ten models and fifty datasets; then it breaks, and the gaps become the finding in someone else’s audit.
• License traps. This is the one that quietly costs money. A model or dataset released under a non-commercial or research-only license (many of the best open weights are) can poison a paid product if it slips into production. A copyleft dataset can create obligations you never agreed to. You cannot manage a license risk you have never inventoried.
• Regulation. The EU AI Act requires technical documentation of high-risk systems, including data and model provenance. NIST’s AI Risk Management Framework and ISO/IEC 42001 both push toward documented, auditable AI supply chains. An AIBOM is the artifact that makes those requirements answerable instead of aspirational.
• Incident response. When a model or dataset is later found to be poisoned, backdoored, or trained on leaked data, the AIBOM is what tells you — fast — which of your products inherited the problem. Without it you are grepping through memory.

What goes into an AIBOM

• Models — base models, fine-tunes, and adapters, with version/commit, source (Hugging Face, internal registry), and license.
• Datasets — training, fine-tuning, and evaluation data, with source and license, flagged for non-commercial / research-only terms.
• Software dependencies — the inference framework, orchestration libraries, and the ordinary package tree that an SBOM/package scan already covers.
• Licenses and provenance — the connective tissue: for every component above, where it came from and what you are allowed to do with it.

AIBOM vs SBOM

An AIBOM does not replace your SBOM — it extends it. The cleanest way to think about it: an SBOM inventories the code; an AIBOM inventories the code plus the models and data, because in an AI product the model and its training data are dependencies with licenses and risk, exactly like an npm package is. If you already produce SBOMs in CI, an AIBOM is the same discipline applied to two component types your existing tooling ignores.

Formats: CycloneDX

You do not need a bespoke format. CycloneDX — the OWASP-backed SBOM standard — added machine-learning support (ML-BOM: model cards, datasets, and considerations) precisely so that models and datasets can be represented as first-class components alongside code. Emitting your AIBOM as CycloneDX JSON means it drops into the same tools, registries, and vulnerability workflows your SBOMs already flow through, instead of living in a spreadsheet only one person understands.

How to generate an AIBOM

You can build one by hand, but it rots the moment a dependency changes. The practical path is to generate it from the manifests you already have. PlayCISO’s free AI Bill of Materials generator does exactly this in your browser: paste a package.json, a requirements.txt, or a small { models, datasets } manifest, and it returns a CycloneDX-flavored inventory with a per-component license-risk verdict — ok / review / conflict / unknown — and commercial-use conflict detection, downloadable as JSON. Nothing leaves the request. For the model side specifically, pair it with a behavioral model audit so the inventory sits next to evidence the model itself behaves.

A starting checklist

• Inventory once, manually, today — list every model and dataset in one product. The gaps you find are the point.
• Generate a CycloneDX AIBOM from that product’s manifests and read the license-risk column before anything else.
• Resolve the conflicts — any non-commercial or copyleft component in a paid product is a decision, not a footnote.
• Wire it into CI so the AIBOM regenerates on every build and a new license conflict fails the pipeline, the same way an SBOM does.
• Keep the provenance — when a model or dataset is later found compromised, the lineage is what makes your blast-radius answer take minutes instead of days.