Ask a security team which open-source packages ship in their flagship application and, in 2026, most can produce a software bill of materials in minutes. Ask the same team which models, datasets, adapters, and prompt sources their AI features depend on — and where each came from — and you will usually get a pause. That pause is the entire reason the AIBOM exists.
The definition
An AIBOM (AI Bill of Materials) is a structured, machine-readable inventory of the components that make up an AI system. It extends the SBOM concept — which catalogs software components and their relationships — to the artifacts unique to AI: trained models and their versions, the datasets used to train and fine-tune them, adapters and fine-tunes layered on base models, prompt templates and their sources, and the frameworks and libraries that tie it together. Where an SBOM answers "what code is in this build," an AIBOM answers "what does this AI system actually consist of, and where did each piece originate."
You will also see the terms ML-BOM (machine-learning bill of materials) and model card used nearby. A model card is documentation for a single model. An ML-BOM or AIBOM is the system-level inventory across all of them. They complement each other.
Why it matters now
Three forces made the AIBOM go from nice-to-have to necessary.
Incident response. When a malicious model is disclosed on a public hub, or a widely used dataset is found to be poisoned, the only question that matters is "are we exposed, and where." Without an inventory, that is a multi-day scramble across teams. With one, it is a query that returns a list of affected systems in minutes. This is the same value an SBOM delivered during the wave of open-source supply-chain incidents — applied to a new class of artifact.
Provenance and trust. AI artifacts arrive from outside your organization and can be tampered with — malicious weights, rug-pulled models, poisoned corpora. An AIBOM records where each artifact came from and which version you are running, turning "we think this model is fine" into "here is its source and hash." You cannot verify provenance you never recorded.
Regulation and procurement. Frameworks and regulations increasingly expect organizations to know and document the AI components in their systems, and enterprise buyers increasingly ask vendors for one. The EU AI Act's transparency expectations and the general direction of AI governance in 2026 all push toward documented, auditable AI supply chains. An AIBOM is how you produce that documentation without a fire drill.
What goes in one
A useful AIBOM captures, for every AI component:
- Models — name, version or commit hash, publisher, source location, serialization format, and license.
- Datasets — training and fine-tuning sources, versions, and origin, so a poisoning disclosure is traceable.
- Adapters and fine-tunes — what base model they modify and who produced them.
- Prompts and templates — the system prompts and prompt sources the application depends on, since these shape behavior as much as code.
- Supporting software — the frameworks, inference servers, and libraries, which is where it overlaps with a traditional SBOM.
- Provenance metadata — hashes, signatures, and responsible owners for each entry.
The standards to know
You do not need a bespoke format. Two mature standards already cover AI components in 2026:
- CycloneDX supports machine-learning components, letting you describe models and datasets alongside ordinary software dependencies in the same document — practical if you already produce CycloneDX SBOMs.
- SPDX 3.0 introduced an AI profile (and a related dataset profile) specifically for describing AI systems, models, and training data within the SPDX ecosystem.
Both are open and tool-supported. The right choice is usually whichever your existing SBOM tooling already speaks, so your AI inventory lives beside your software inventory rather than in a silo.
Getting started without boiling the ocean
You do not need a perfect AIBOM on day one. Start with the highest-risk artifacts — the base models and datasets in production — and record source, version, and hash for each. Automate generation as part of your build and model-deployment pipelines so the inventory stays current instead of decaying into a stale spreadsheet. Then expand to adapters, prompts, and the long tail. An 80-percent-complete AIBOM that updates automatically beats a perfect one that was accurate for a week.
How Safeguard helps
Safeguard builds the AIBOM into how it maps your software supply chain rather than treating it as a separate artifact. Software composition analysis enumerates the models, datasets, adapters, and supporting libraries your AI systems depend on — with their sources, versions, and hashes — and keeps that inventory current as your stack evolves, so exposure is legible: which model, which dataset, which reachable path. When an upstream incident lands, the inventory is what makes "are we exposed?" answerable in minutes instead of days.
That inventory is not a dead document. The Griffin AI detection engine reconciles it against vulnerability and reputation data and flags where an unsafe or unverified artifact enters your code, and auto-fix remediation proposes the correction. As a builder of its own Griffin model family, Safeguard applies the same provenance-first discipline to its own artifacts that its AIBOM helps you enforce across the models and data you consume. To see how this supply-chain-first approach compares to alternatives, browse the comparisons.
You cannot secure what you have not enumerated. An AIBOM is the foundation every other AI security control rests on — start building it. Create a free account or read the documentation.