What is an AIBOM? The AI bill of materials, explained
An AIBOM is a machine-readable inventory of the AI artifacts a system contains: model files and their formats, weights, training-data references, and the ML frameworks underneath, with provenance for each. It exists because models are now shipped software components - downloaded, embedded, and trusted - and governance, security, and emerging AI regulation all start with knowing which models you actually run.
An AIBOM, an AI bill of materials, is a machine-readable inventory of the AI artifacts inside a system: the model files and their formats, the weights, references to the datasets involved, and the ML frameworks and libraries that load and run them - each with provenance. It extends the SBOM idea to a class of component that arrived fast and mostly skipped the inventory discipline software components took years to earn.
Why models became a supply chain
Modern applications embed models the way they embed libraries: downloaded from hubs, fine-tuned, copied between projects, and packed into images. That makes them supply-chain artifacts with all the familiar questions - what is this, where did it come from, what runs it - plus several of their own:
- Format risk. Some model formats are effectively executable: loading them can run code embedded in the file. Knowing which of your models use safe tensor formats versus code-executing serialization is a security property you cannot state without an inventory.
- Provenance. A model of unknown origin is an unauditable decision-maker inside your product. Where it was obtained, and which hash you actually deployed, is the minimum record.
- The stack beneath. Models run on frameworks and native libraries with their own vulnerabilities - ordinary SCA territory, but only connectable to the model risk if both inventories exist and correlate.
- License terms on weights. Model weights ship under licenses with real restrictions, including commercial-use limits; weights are intellectual property with terms attached, exactly like code dependencies.
What a real AIBOM records
Per artifact: the model’s identity and content hash, its file format, size, the framework that loads it, where it lives in the system, how it was obtained, and any accompanying metadata such as model cards or configuration. Generated - like every trustworthy BOM - from the artifacts themselves, not from a survey of what teams remember deploying, and honest about anything it could not resolve.
One generation detail matters more here than anywhere else: inventorying a model must never require loading it. A generator that deserializes pickle-based files to inspect them is executing untrusted code as a scanning step. Structural parsing - reading headers and archive contents without deserialization - gets the inventory without the exposure.
Where this is heading
The pattern is the SBOM story replaying at higher speed: internal governance teams ask first, procurement follows, regulation arrives last and makes it mandatory. BOM guidance in several jurisdictions already names AI inventories explicitly, and AI-specific regulation under construction presumes you can enumerate your models - a presumption most organizations currently cannot meet.
BOMNexa treats the AIBOM as one of its five BOM dimensions: generated from artifacts with safe structural parsing, hashed and provenanced, and managed under the same lifecycle - stored per release, monitored as data updates - as the software and cryptography inventories beside it.
Frequently asked questions
Why do model files need their own inventory - are they not just files in the SBOM?
A generic SBOM sees a large binary file; an AIBOM understands what it is: which model, which format, which framework loads it, and where it came from. Model-specific risks - unsafe serialization formats, unknown provenance, license terms on weights - only become visible when models are inventoried as models.
What is the security issue with model file formats?
Some widely used formats are serialized code, not just data: loading a pickle-based model file can execute arbitrary code embedded in it. An AIBOM that records each model's format tells you which artifacts carry that loading risk - and a careful generator determines this by parsing structure, never by actually deserializing the file.
Who asks for AIBOMs?
AI governance and risk teams internally, and increasingly regulation externally: AI-specific rules taking shape in several jurisdictions, and BOM guidance - such as CERT-In's technical guidelines in India - that names AI bills of materials explicitly alongside software and cryptography inventories.