AI Bill of Materials (AI BOM): what enterprise should disclose and track

An AI Bill of Materials in 2026 is the audit-ready inventory of every model, dataset, training source, evaluation method, and deployment dependency in a production AI system. Most enterprises do not yet ship one. The EU AI Act Article 16 deployer-documentation obligations make it mandatory in scope by 2 August 2026, and the maturity gap between what regulators and procurement teams expect and what enterprises currently produce is structural rather than technical.

The conversation we keep having with senior enterprise IT in early 2026 is whether the AI components in production deployments need their own inventory artefact, separate from the SBOM machinery already in place, and if so what that artefact should contain. The answer is that the inventory shape is distinct, the disclosure expectation is hardening, and the deployer-side preparation work is more substantial than most procurement programs have planned for. The deadline that forces the question is 2 August 2026.

Why AI BOM is a 2026 conversation

Three forces converged in the eighteen months before May 2026 to move AI BOM from optional security artefact to expected disclosure layer.

The first is regulatory. The EU AI Act enters its high-risk-system enforcement window on 2 August 2026 (artificialintelligenceact.eu, Implementation timeline). Article 11 binds providers to prepare technical documentation that meets Annex IV. Article 16 binds providers to obligations including the placement of identifying markings, the maintenance of post-market monitoring, and the supply of documentation to deployers — the documentation deployers themselves need to satisfy Article 26 deployer obligations and Article 13 transparency expectations. The closest existing artefact to that documentation set is an AI BOM.

The second is the supply-chain-disclosure precedent. Executive Order 14028, signed 12 May 2021, made SBOMs an expected artefact for software sold to US federal agencies. Five years on, SBOMs are standard procurement language across regulated industries. AI BOM is the natural extension, and the procurement teams that have already built SBOM ingestion pipelines understand the shape.

The third is the framework layer. The NIST AI Risk Management Framework v1 (published 26 January 2023) and the v2 update under public consultation through 2026 both treat component-level documentation as a core governance primitive. The CycloneDX-AI specification gives the machine-readable format, and the OWASP Foundation hosts the specification work. The pieces are in place; the procurement and disclosure habit is not yet.

What the AI BOM contains

A production AI BOM in 2026 documents six layers. None is optional for an audit-ready artefact; each is the layer most commonly missing from vendor-supplied datasheets.

Foundation model identity. Provider name, model family, exact version string, deployment region or endpoint identifier, context window, and the provider’s published model card or system card reference. For an Anthropic Claude deployment this includes the specific model version (the level of detail published on the Anthropic models page); for an OpenAI deployment the equivalent versioned identifier; for a self-hosted open-weights deployment the exact checkpoint hash.

Training-data provenance. The data sources the foundation model was trained on, to the extent the provider discloses them, and the opt-out signals respected at training time. Where the provider has not disclosed sources (the common case for closed-weights frontier models), the AI BOM records that fact rather than fabricating one. Where the deployment is self-hosted on open weights, the provenance trail is the deployer’s responsibility to capture and document.

Fine-tuning data. Any data the deployer added through fine-tuning, RAG corpus injection, or system-level retrieval. For RAG deployments this includes the document corpus, the embedding model used to index it, the chunk strategy, and the data-classification labels applied. This layer is where deployer-side liability concentrates: the foundation-model provider does not know what corpus the deployer attached.

Evaluation methodology. The benchmarks, red-team protocols, and acceptance criteria the deployment was tested against before production release. This is the layer that distinguishes a credible AI BOM from a checklist artefact: an evaluation entry that reads “tested against company-internal evaluation suite, scored 87% on accuracy” without specifying the suite, the rubric, or the comparison baseline is not audit-ready. Article 15 of the EU AI Act on accuracy and robustness expectations applies here directly.

System prompts and guardrails. The deployment-time configuration that shapes model behaviour: system-prompt content, content-filtering layers, refusal categories, safety classifiers, and input/output transformation steps. For agentic deployments this layer expands to include tool-use scopes, MCP server allow-lists, and orchestration policies. The our-estimate synthesis we hold here is that fewer than one in three production deployments today document this layer in a form that survives a tabletop incident review (our-estimate).

Runtime dependencies. Vector databases, RAG document stores, Model Context Protocol servers, agent orchestration frameworks, observability layers, and any service the deployment calls during inference. Each entry includes vendor, version, region, data-residency posture, and whether the dependency stores prompts or outputs. This is the layer that overlaps cleanly with the existing SBOM mental model and that benefits most from existing procurement machinery.

The CycloneDX-AI specification provides field definitions for all six layers and the JSON schema that tooling can target. SPDX 3.0 covers a subset of the same surface. PDF datasheets do not. The format question is downstream of the contents question, and the contents question is where most enterprises stall.

Who is asking for it

Four distinct buyer categories are now requesting AI BOM artefacts at procurement, renewal, or audit, and the requests come with different vocabularies attached.

Regulators ask under the EU AI Act and the NIST AI RMF banner. Article 16 of the EU AI Act binds high-risk-system providers to supply documentation to deployers; Article 26 binds the deployers themselves to maintain documentation of their use of the system and the data flowing through it. The market-surveillance authorities that begin enforcement on 2 August 2026 will request this artefact. The Datenschutzkonferenz Muss-Liste guidance that German data-protection authorities published in 2024 already names AI-component documentation as a deployment-readiness trigger.

Enterprise customers ask through procurement and renewal cycles. The procurement teams writing 2026 enterprise RFPs are adding AI BOM delivery clauses next to the SBOM clauses already standard in 2024 and 2025 contracts. The clause typically requires initial AI BOM at contract signature, refresh on material change, and audit-right delivery on request. Enterprises that have not added this language are not receiving the artefact by default.

Trust-and-safety auditors ask under third-party assessment frameworks. SOC 2 Type II audits, ISO 42001 AI management system certifications, and supplier risk assessments now include AI-component questions that map onto AI BOM fields. The auditor-facing artefact does not need to be the same machine-readable file the procurement team ingests; it does need to answer the same questions consistently.

Model risk managers in financial services ask under SR 11-7, the Federal Reserve’s 2011 supervisory guidance on model risk management, extended in practice to AI components. The MRM team does not call the artefact an AI BOM; they call it model documentation. The fields are functionally identical: model identity, data lineage, evaluation evidence, deployment configuration, monitoring discipline.

Why most enterprises don’t ship one yet

The maturity gap is structural, not a tooling deficit. Three structural reasons explain why AI BOM is the documented exception rather than the norm in 2026.

Vendor data-sheets are marketing artefacts, not BOM-grade documentation. The model card a frontier-model vendor publishes describes capabilities and intended uses at a level appropriate for developer communication; it does not describe the deployer-specific configuration, the fine-tuning layer the deployer added, the RAG corpus the deployer attached, or the evaluation evidence the deployer produced before release. The deployer-specific layers are the ones an auditor or regulator will request, and they are precisely the layers no vendor data-sheet can provide.

Multi-vendor stacks fragment provenance. A typical 2026 enterprise agentic deployment combines a frontier-model API (Anthropic, OpenAI, Google), an embedding model from a different provider, a vector database from a third, an orchestration framework from a fourth, and observability tooling from a fifth. Each component carries its own documentation in its own format on its own refresh cadence. Composing these into a single AI BOM requires either tooling that does not yet exist at maturity, or a manual integration discipline that most enterprises have not staffed.

Legacy AI deployments predate the BOM expectation. Production AI systems shipped in 2023 and 2024 were built before AI BOM became a procurement question. Retroactively constructing the artefact for a deployment that has already drifted across multiple model-version updates, fine-tuning rounds, and data-source additions is forensic work. The our-estimate cost we hold for a complete retroactive AI BOM build on a mature multi-vendor agentic deployment is six to ten weeks of cross-functional engineering and compliance time (our-estimate).

The combined effect is that AI BOM in 2026 is uncommon, the demand for it is increasing on multiple regulatory and procurement fronts simultaneously, and the enterprises that move first will set the disclosure norm for the segment.

What an audit-ready AI BOM looks like in practice

An AI BOM that survives an external audit shares four properties.

The format is machine-readable. CycloneDX-AI (the OWASP-hosted specification at cyclonedx.org/capabilities/mlbom) is the leading 2026 format and the one most likely to be referenced in procurement language. SPDX 3.0 is the alternative. A PDF datasheet may accompany the BOM as a human-readable summary; it does not replace it.

The distribution is contractual. The artefact moves between provider and deployer through the procurement contract, with refresh-cadence clauses and audit-right clauses making the obligation enforceable. An AI BOM that exists internally but never crosses to the deployer is not a disclosure artefact; it is documentation hygiene.

The refresh cadence is event-driven, not calendar-driven. Material changes — model-version bumps, fine-tuning rounds, RAG-source additions, guardrail-policy changes, evaluation-methodology revisions — trigger an updated AI BOM within a contractually specified window. For frontier-model deployments where the provider versions weekly, the contract specifies the notification and update mechanism. Calendar-driven quarterly refreshes lag material change and produce stale artefacts.

The verification path is named. The AI BOM identifies which fields the deployer can verify directly (vendor identity, version string, deployment region) and which fields rest on provider attestation (training-data provenance, evaluation methodology). The verification path matters because the deployer-side liability under Article 26 of the EU AI Act applies regardless of where in the chain the documentation gap originated.

For enterprise IT teams asking what to request from each AI vendor in 2026 renewals, the deliverable list is short and consistent: a CycloneDX-AI or SPDX 3.0 artefact covering all six layers above, an event-driven refresh clause, an audit-right clause, and a named contact for documentation requests. The vendors that meet the request are signalling AI-procurement maturity; the vendors that resist the request are signalling that the deployer will be carrying disclosure-layer risk on their behalf.

Procurement actions for the next 90 days

For an enterprise IT or procurement leader looking at 2 August 2026 from May 2026, the 90-day track is direct.

Request. Add AI BOM delivery clauses to every active AI-vendor renewal and every new RFP. The clause specifies format (CycloneDX-AI 1.6+ or SPDX 3.0+), initial delivery (at contract signature or production release), refresh cadence (event-driven on material change), and audit right (on request, with reasonable notice). The clause language can mirror the SBOM clause already in most 2025 contracts.

Log. Inventory every production AI deployment and record, for each, the AI components present and the documentation currently held. This is the gap-analysis baseline. Cross-reference the inventory with the agent-incident-response playbook to identify deployments where an incident today would expose the documentation gap immediately.

Gap-analyze. For high-risk-classified deployments under EU AI Act Annex III scope, produce the full AI BOM in the next 60 days regardless of vendor cooperation. The deployer-side fields (fine-tuning data, RAG corpus, system prompts, guardrails, runtime dependencies, non-human-identity surface) are within deployer control; the vendor-supplied fields can be filled with disclosure status and outstanding requests where the vendor has not yet responded.

Plan. For deployments outside high-risk scope, add AI BOM completion to the 12-month procurement roadmap with a clear ownership assignment. The discretion window is narrowing; deployments that ship without AI BOM in 2027 will face procurement friction in 2028 RFPs.

This Holding-up entry tracks at /holding/?claim=AM-143. The retest cadence is 60 days because the EU AI Act enforcement timeline, the CycloneDX-AI specification updates, and the procurement-clause language all move on multi-quarter horizons. The signals that would change the verdict: first-wave EU AI Act enforcement actions in late 2026 producing concrete signal on what regulators consider acceptable Article 16 documentation; major frontier-model vendors (Anthropic, OpenAI, Google) shipping AI BOM as standard contract delivery; or NIST AI RMF v2 publishing a formal component-documentation reference that procurement teams can cite directly. For the procurement-side artefact pattern, the sibling piece on AI BOM as procurement requirement covers the contracting-process question; for the regulatory mapping, the EU AI Act compliance walkthrough and the Article 12 audit-evidence piece cover the upstream framework.