AI Bill of Materials (AIBOM): The Inventory Layer Compliance Teams Keep Skipping

The Software Bill of Materials (SBOM) became a procurement requirement after the SolarWinds and Log4Shell incidents made it clear that organizations could not enumerate the software running in their environment. The 2021 Executive Order 14028 codified SBOM as a federal procurement standard. Most software vendors now ship one.

The AI Bill of Materials (AIBOM) is the same idea applied to AI systems. An AIBOM enumerates the model, the training data lineage, the inference dependencies, the policy version applied to runtime traffic, and the audit retention configuration. The artifact answers the question "what is actually in this AI deployment?" the way an SBOM answers "what is actually in this software package?"

Search volume on "AIBOM" and "AI bill of materials" is climbing month over month. The SERP is currently owned by vendors selling tooling. The explainer layer is missing, which is what this article tries to fix.

I want to walk through what goes in an AIBOM, how it differs from an SBOM, the regulatory regimes that reference it, and the architectural choices that determine whether the artifact can be produced in a useful form.

What an SBOM contains, for grounding

An SBOM typically uses the SPDX or CycloneDX schema. The document lists each component (library, binary, dependency), its version, its supplier, its license, and any known vulnerabilities. The list is structured and machine-readable. A procurement team can ingest an SBOM and run it through their vulnerability database to assess exposure to a newly disclosed CVE in a downstream dependency.

The SBOM has one important property: it is generated at build time and reflects what was packaged. It does not describe what runs at request time.

What an AIBOM contains

An AIBOM extends the SBOM idea but has to cover several layers that an SBOM does not.

The model layer

The model layer enumerates the AI models the deployment uses. Per model: the provider, the model identifier, the version, the access method (API endpoint, hosted weights, fine-tuned variant), and the model card reference. The model card is the AI-specific equivalent of a library README: it documents the model's intended use, known limitations, training data summary, and evaluation results.

A typical enterprise deployment uses several models. The AIBOM should list all of them, including the small ones used for classification and embedding, not just the headline LLM.

The training data layer

For internally fine-tuned models, the AIBOM describes the training data lineage. Source of the data, classification, consent or licensing basis, transformations applied during preprocessing, and the date range covered. For third-party models, the deployer references the provider's published training data documentation.

The training data layer is what auditors check against the EU AI Act's data quality and bias provisions in Article 10. It is also what GDPR auditors check against Article 14's right to information about automated decision-making.

The inference dependency layer

The inference dependency layer is closer to a classical SBOM: the libraries, frameworks, and runtimes the inference path depends on. LangChain version. Tool integrations. Vector database. Embedding service. Token provider. Each dependency has a version, a supplier, and a vulnerability surface.

The runtime policy layer

The runtime policy layer is where AIBOM diverges most from SBOM. An AI system's behavior is not fully specified by its packaged components. Runtime policy decides which prompts the model is allowed to receive, which tools it is allowed to invoke, which data classifications can flow through it, and which identity contexts can call it.

The AIBOM has to include the policy version active in production, the policy author, the approval chain, and the date of last revision. Without the runtime policy reference, the AIBOM describes what could happen but not what is actually enforced.

The audit configuration layer

The audit configuration layer documents what records the deployment produces, what fields are captured per record, what retention period applies, and what tamper-evidence guarantees are in place. The audit configuration is what an auditor or incident responder will check first when they need to produce evidence about a past event.

The inference-layer audit log is the AIBOM artifact most programs are missing

The model layer, training data layer, and inference dependency layer can be assembled from procurement records and build artifacts. They are static-ish. They change at release boundaries.

The runtime policy layer and the audit configuration layer require a control point that sits on the AI request path. Without that control point, the policy is documented but unenforced and the audit configuration is aspirational. The AIBOM that ships in those conditions lists a policy that nobody can demonstrate was applied to actual traffic.

The per-decision audit log produced by an inline enforcement layer is the AIBOM artifact for the runtime layer. It demonstrates that the policy version named in the AIBOM was the version actually evaluated against each request during the audit window. The audit log links the AIBOM's static description to the dynamic record of what the system actually did.

How AIBOM maps to regulatory regimes

EU AI Act Article 11 documentation

Article 11 of the EU AI Act requires providers and deployers of high-risk AI systems to maintain a technical file. The contents of the technical file are described in Annex IV: a description of the AI system, the data used to train it, the human oversight measures, the cybersecurity measures, and the post-market monitoring plan. The AIBOM is the structured form of most of this content.

An auditor responding to an Article 11 request can ingest a properly structured AIBOM as a starting point. The same auditor would have to reconstruct the equivalent from procurement records and engineering documentation if the AIBOM does not exist.

NIST AI RMF

The NIST AI RMF's MAP function asks the deployer to categorize the AI system, its intended uses, and its dependencies. The AIBOM is the categorization artifact. The MEASURE function asks for metrics and tracking. The audit configuration layer of the AIBOM feeds into MEASURE.

ISO 42001

ISO 42001's AIMS (AI Management System) requires inventory and documentation of all AI systems within scope. The AIBOM is the inventory artifact. ISO 42001 auditors look for the same kinds of structured records SBOM auditors look for in 27001 audits.

Sector-specific regimes

Fannie Mae LL-2026-04 requires lenders to maintain an inventory of AI used in origination and servicing, including AI used by subcontractors and vendors. The AIBOM is the format that inventory should take. The Lender Letter does not specify a format, but a structured AIBOM is what a GSE examiner will accept.

DORA's ICT third-party register, which goes live for EU financial institutions in January 2027, treats LLM vendors as critical third parties at scale. The AIBOM is the artifact that feeds the register's required disclosures about each AI dependency.

AIBOM file format

The current de facto choices are SPDX 3.0 (which added AI-specific fields in late 2024) and CycloneDX 1.6 (which added ML-BOM in 2023 and extended it through 2025). Both schemas are still evolving. The deployer should pick one and commit to it; the schema choice is less important than having a consistent machine-readable format.

A minimal AIBOM in CycloneDX-style JSON looks like this:

The file is small. The value comes from the discipline of producing it and keeping it current.

Compliance gap

Most enterprises today have an SBOM program at some maturity level. AIBOM is typically not yet implemented. The reason is partly schema immaturity and partly the runtime policy and audit configuration layers, which require a control point most deployments do not have.

The recommendation is to start with the static layers (model, training data, inference dependencies) using whichever schema the existing SBOM tooling can be extended to support. Then layer in the runtime policy and audit configuration as the inline enforcement layer is deployed. The artifact does not have to be complete on day one. It has to be on a path to completeness that the auditor can see.

DeepInspect

This is the gap DeepInspect closes for the runtime layer of the AIBOM. DeepInspect sits inline between authenticated users and agents and any HTTP-based LLM endpoint. The runtime policy version is what DeepInspect evaluates against each request. The audit configuration is what DeepInspect's per-decision record satisfies. When the AIBOM names a policy version, DeepInspect can produce the records demonstrating that version was actually enforced against production traffic during the window in question.

If you are building out an AIBOM for an EU AI Act Article 11 file or a Fannie Mae LL-2026-04 inventory and need the runtime evidence layer, let's talk today.