The ‘AI Bill of Materials’ (AIBOM): What It Is and Why Your Procurement Team Will Ask for It

What an AIBOM actually is

Software Bills of Materials (SBOMs) are the inventory artifact that security teams have used to track software supply chains since the early 2020s. SBOMs list libraries, packages, frameworks, and versions, captured at a specific point in time. When a CVE drops in a widely used library (Log4Shell being the canonical example), the SBOM is what lets a security team answer “are we affected?” in minutes instead of weeks.

An AIBOM extends that logic to AI systems. The reason it has to be a separate artifact, and not just an extended SBOM, is that AI behavior is determined as much by data and model weights as by code. A traditional SBOM captures none of that.

Per the consensus emerging from CycloneDX, SPDX, OWASP, IBM Research, and the Linux Foundation, an AIBOM covers six main areas:

• Models. Architecture, version, provenance, base model lineage (if fine-tuned), weights identifiers, licenses, and acceptable-use restrictions.
• Datasets. Sources, collection methods, preprocessing steps, licenses, training/validation/test splits, and known limitations.
• Code. Frameworks, libraries, dependencies, and version pins (this is the SBOM overlap).
• Hardware. The compute the model was trained on; the compute required to run it; accelerator types and configurations.
• Data processing pipelines. Training pipelines, validation pipelines, retrieval pipelines (for RAG), and the orchestration layer.
• Governance. Approval history, change log, evaluation results, known failure modes, compliance attestations (SOC 2, ISO 42001, etc.), and human oversight requirements.

Unlike a static SBOM, an AIBOM is a living document. AI systems are not static; they are retrained, fine-tuned, fed new retrieval sources, and updated with new model versions on a continuous basis. A useful AIBOM updates as the system changes, with the change log itself part of the artifact.

The naming varies. You will see AIBOM, AI-BOM, AI SBOM, ML-BOM, and MBOM (Model Bill of Materials) all in use in vendor documentation. They refer to substantially the same artifact with minor scope differences. For the rest of this post, we use AIBOM.

Why this is happening in 2026 (and not 2024)

AIBOM is not a new idea. The concept has been floating in security research circles since at least 2022. What changed in 2026 is that procurement teams stopped being able to ignore it.

Forcing function 1: EU AI Act Article 11 and Annex IV

The EU AI Act’s technical documentation requirement for high-risk AI systems, codified in Article 11 with the field-level requirements in Annex IV, took effect August 2, 2026 under current law. The proposed Digital Omnibus on AI (published November 2025, still in trilogue) may extend Annex III high-risk deadlines to December 2027 if harmonized standards are not yet available. Either way, the documentation requirement is real, and it maps almost directly onto AIBOM fields.

For high-risk deployments under Annex III (employment screening, credit scoring, law enforcement use, critical infrastructure operation), Article 11 documentation is enforceable. Providers without an AIBOM-shaped inventory will need to produce one or fail their conformity assessment. Deployers (the enterprises using the system) inherit downstream obligations, including the right to receive Article 13 transparency information that maps onto the same artifact.

Additionally, EU AI Act Article 53(1d) imposes a Training Data Summary requirement on general-purpose AI (GPAI) model providers, which took effect August 2, 2025. GPAI documentation that tracks with model versions has to be produced through automated CI/CD generation in practice; manual updates do not scale at GPAI release cadence.

Forcing function 2: Mature open standards

Two formats reached production maturity in 2025–2026:

• CycloneDX ML-BOM v1.7, maintained by OWASP, is the practical format for CI/CD automation. The OWASP AIBOM Generator outputs CycloneDX directly from Hugging Face model metadata.
• SPDX 3.0 AI Profile has ISO/IEC 5962 lineage that gives it regulatory weight in procurement contexts and aligns with the NIST AI Risk Management Framework.

Procurement teams who tried to require AIBOM in 2024 ran into a chicken-and-egg problem: there was no standard format to specify in contracts. That problem is now solved.

Forcing function 3: Multiple governance frameworks converging

In a six-month window in 2025–2026, the following frameworks all converged on AIBOM-adjacent documentation requirements:

• CISA published “Software Bill of Materials for AI: Minimum Elements”
• NIST AI Risk Management Framework referenced AIBOM principles in its 2025 updates
• ISO/IEC 42001 (the AI management system standard) requires inventory, supplier governance, and change control that AIBOM directly supports
• COSO’s February 2026 guidance on generative AI internal controls requires documentation of model and configuration versions, mapping cleanly to AIBOM fields
• OWASP AIBOM Project launched in 2025 with open-source tooling
• Singapore Model AI Governance Framework added GenAI disclosure requirements that map to CycloneDX entries

When five global governance frameworks ask for substantially the same documentation, procurement teams stop arguing and start requiring it. For broader strategic context, see our piece on AI governance as architecture.

What goes in an AIBOM: the field-level view

Below is the consensus minimum-elements list for an AIBOM in 2026, synthesized from CycloneDX ML-BOM v1.7, SPDX 3.0 AI Profile, CISA’s minimum elements guidance, and EU AI Act Annex IV.

Models

• Model name and version
• Architecture (transformer, mixture-of-experts, encoder-decoder, etc.)
• Base model lineage (e.g., “fine-tuned from Llama 3.1 70B at checkpoint X”)
• Weights identifier (hash or URI)
• License (with explicit acceptable-use restrictions called out, not just SPDX identifier)
• Provider and provenance chain
• Approval status in your organization
• Known failure modes and limitations

Datasets

• Dataset name and version
• Source (URL, vendor, internal system)
• Collection method (scraped, licensed, synthetic, human-labeled)
• License and consent basis (especially for personal data under GDPR)
• Preprocessing steps applied
• Train/validation/test split methodology
• Known biases or quality issues
• Retention period and disposal plan

Code

• Frameworks (PyTorch, TensorFlow, JAX, etc.) with versions
• Inference libraries and runtimes
• Dependency tree (this is your existing SBOM material)
• Container images and versions
• Hashes for binary artifacts

Hardware

• Training hardware specification (GPU/TPU model, count, interconnect)
• Inference hardware requirements
• Memory and storage requirements
• Cloud provider and region (if applicable)

Data processing pipelines

• Training pipeline definition and version
• Validation and evaluation pipeline
• Retrieval pipeline for RAG systems (vector database, embedding model, retrieval logic)
• Orchestration layer (LangChain, custom, etc.)
• External APIs the system depends on

Governance

• Approval history (who approved, when, for what use case)
• Change log with timestamps and approvers
• Evaluation results (benchmark scores, fairness audits, safety evaluations)
• Compliance attestations (SOC 2, ISO 42001, HIPAA, etc.)
• Human oversight requirements
• Incident history (if any)
• Decommissioning plan

If a vendor cannot produce most of these fields when asked, that is your answer about the maturity of the AI system you are about to buy. For how this evidence base intersects with the audit trail you keep in production, see our field-level checklist for AI audit trails.

Why procurement teams are now asking

Five reasons enterprise procurement teams in 2026 are requiring AIBOM, in roughly the order they appear in procurement reviews.

1. Regulatory exposure. If your organization is subject to the EU AI Act, ISO/IEC 42001, NIST AI RMF, or similar frameworks, the vendor’s AIBOM is the evidence base your compliance team needs. Procurement teams have learned that signing a contract without this evidence creates downstream regulatory exposure that the finance and legal functions then have to manage.
2. Vulnerability response. When a vulnerability surfaces in PyTorch, in a popular base model, in a widely used embedding model, or in an inference framework, your security team needs to know in minutes which production AI systems are affected. Without AIBOMs, that question takes weeks to answer and the answer is often “we think so.”
3. License clarity. A model card that says “MIT license” or “Apache 2.0” can hide acceptable-use restrictions, training data license conflicts, or weight access limitations that directly contradict the headline label. This pattern, sometimes called “permissive-washing,” is a real procurement risk. AIBOM requires explicit license disclosure beyond what model cards show.
4. Vendor change governance. AI systems update silently. Models get fine-tuned. Retrieval sources get added. Orchestration layers get refactored. Procurement teams want a contractual commitment from the vendor to deliver an updated AIBOM on every material change, so the buyer’s risk and compliance posture stays current.
5. Auditor pressure. External auditors in 2026 are asking about AI inventory completeness. The auditor’s first question is whether the inventory exists; the second is whether it is current; the third is whether the components are traceable to their sources. AIBOM is the answer to all three. (For the deeper auditor playbook, see what your SOX auditor will ask about your AI automation.)

CycloneDX vs SPDX: which format should you require?

The two dominant open-source AIBOM formats serve different purposes. The procurement-side answer in 2026 is to require both, with different uses for each.

The practical 2026 approach: require SPDX 3.0 AI Profile from external vendors for its regulatory weight, and use CycloneDX ML-BOM internally for CI/CD-generated AIBOMs. Tools like Protobom and BomCTL translate between the two formats, so mandating SPDX from vendors does not prevent you from working with CycloneDX internally.

What to put in your next AI RFP and contract

If you are updating procurement templates in 2026, the following clauses are now baseline. None of these existed in 2024 RFP templates. All of them should be in 2026 templates.

AIBOM delivery

Vendor shall deliver an AI Bill of Materials (AIBOM) for the AI System in [SPDX 3.0 AI Profile format / CycloneDX ML-BOM v1.7 format / both]. Initial delivery shall occur no later than [X] days prior to production deployment.

Update cadence

Vendor shall deliver an updated AIBOM upon each Material Change to the AI System, including but not limited to: model version upgrades, fine-tuning events, changes to training or retrieval data sources, changes to inference frameworks, changes to orchestration layers, or changes that materially affect the System’s behavior. Updates shall be delivered no later than [X] business days after the Material Change.

Field completeness

The AIBOM shall include, at minimum, the fields specified in [CISA Minimum Elements for SBOM for AI / EU AI Act Annex IV / Buyer’s Schedule X]. Vendor warrants that the AIBOM is accurate and complete as of the date of delivery.

Audit right

Buyer shall have the right to receive the most recent AIBOM upon request, no more frequently than [X] times per quarter, throughout the term of the Agreement and for [X] years thereafter. Buyer shall have the right to validate AIBOM accuracy through reasonable audit procedures, subject to Vendor’s confidentiality protections.

License transparency

Vendor shall disclose in the AIBOM all licenses applicable to each AI component, including any acceptable-use restrictions, training data license terms, weight access limitations, or downstream use restrictions that may apply beyond the headline license identifier.

Vulnerability and incident notification

Vendor shall notify Buyer within [X] business days of becoming aware of any vulnerability, license issue, or material incident affecting components disclosed in the AIBOM.

Enterprises adding this language in 2026 RFPs are seeing vendors meet the requirement. Enterprises that have not added it are not receiving the artifact by default. For broader procurement context, related reading: AI for compliance automation and compliance automation.

The three pipeline gates: how mature programs operationalize AIBOM

In organizations with mature AI procurement programs, AIBOM operates at three pipeline gates:

1. Model intake gate. Before any model enters the internal model registry, the vendor’s AIBOM is evaluated against the procurement checklist. Models without adequate provenance are blocked here. This is the highest-leverage gate; it is also the easiest to enforce because the model is not yet in production.
2. Build gate. During CI/CD, the AIBOM is generated or refreshed for any AI component being built or integrated. Tools like the OWASP AIBOM Generator (CycloneDX-formatted) can run as a pipeline step. Snippet scanning (e.g., FOSSA) catches license obligations introduced by AI coding assistants that show up as copied text rather than declared dependencies.
3. Deployment gate. Before production deployment, AIBOM compliance metadata is verified against policy. Outdated models, expired licenses, or incomplete documentation block deployment. This gate is where the EU AI Act Article 53(1d) GPAI Training Data Summary requirement is enforced for deployments into EU markets.

If your organization is starting from scratch, the model intake gate is where to begin. It blocks the most risk for the least effort.

How Kognitos approaches AIBOM

Kognitos is a neurosymbolic AI platform, and AIBOM-friendliness was a design constraint from the start.

• Model versions are pinned per automation. We do not silently upgrade the underlying model. Every model upgrade is an explicit, logged event with an associated change record. This is what makes the AIBOM update cadence requirement enforceable in practice.
• Components are inventoried by default. Every Kognitos automation declares the models, libraries, frameworks, and external integrations it depends on. The inventory is part of the automation’s metadata, not a separate document that drifts out of date.
• The “code” is English. Because Kognitos automations are written in English-as-code, the system’s logic is itself part of the AIBOM in human-readable form. There is no opaque model behavior to document separately from the rules the system follows.
• Governance metadata is captured natively. Approval history, change log, evaluation results, and compliance attestations are first-class fields in the platform, not bolted-on documentation.
• Kognitos is SOC 2 Type II, HIPAA, GDPR, and ISO 27001 aligned, with ISO/IEC 42001 alignment work underway (see our Trust portal).

If you are evaluating Kognitos and your procurement team requires AIBOM, we can deliver it in SPDX 3.0 AI Profile or CycloneDX ML-BOM v1.7 format as part of the contract package.

Book a working session with a Kognitos solutions engineer →

Last updated: May 2026. This article is intended for informational purposes and does not constitute legal, audit, or compliance advice. Specific requirements vary by jurisdiction, industry, and the structure of your AI program. Engage qualified counsel and your compliance and procurement teams for guidance specific to your situation.