AIBOM: The AI Component Disclosure
The one-paragraph answer
An AIBOM (AI Bill of Materials) is the AI-specific analog to SBOM. It discloses the AI components inside a product: model architecture, training data characteristics, foundation model provenance, fine-tuning data, evaluation results, and known limitations. Unlike SBOM, AIBOM is not yet standardized, but formats are emerging. Buyers of AI products should require AIBOMs; AI vendors should be prepared to produce them.
Buyers of AI products face a black-box problem. What model is inside? Trained on what data? With what known biases? Under what license? Vendors often will not or cannot answer. When the AI produces a problematic output, buyers cannot trace it back to root cause. AIBOM is the emerging answer: standardized disclosure of AI component provenance and characteristics.
Model name, version, architecture family, base model (if fine-tuned), parameter count.
Sources, size, key characteristics, personal data content, copyrighted content status, quality processes.
Benchmarks, bias testing outcomes, safety evaluations, known limitations.
Model license, training data licenses, permitted uses, restrictions.
When the model was last updated, retraining cadence, change history.
AI buyers cannot manage risk without disclosure. AI vendors cannot serve enterprise buyers without disclosure infrastructure. EU AI Act obligations, NIST AI RMF documentation expectations, and enterprise procurement questionnaires all drive toward standardized AIBOM adoption.
The academic literature on AIBOM is ahead of most corporate practice, and it is unusually blunt. Two findings are worth putting in front of any executive who thinks this is a compliance formality.
“Only 3.6% of approvals reported race/ethnicity, 99.1% provided no socioeconomic data.”
That is the gap between having AI and governing it. The second finding is the one that tends to change the room.
“it remains challenging for practitioners to identify the harmful repercussions of their own systems prior to deployment”
Neither of these is a fringe position. Both come from peer-reviewed work, and both describe the condition most organisations are actually in when the question about AIBOM arrives from the board, the buyer, or the regulator.
This is the sequence that works, and it is not the sequence most organisations choose. They start with the framework and work backwards toward reality. Start with reality.
Done in this order, AIBOM becomes tractable. Done out of order, it becomes a document nobody uses and a control nobody exercises.
Not yet universally standardized. Extensions to SBOM formats (SPDX-AI, CycloneDX ML-BOM) are emerging. The READ AI Models Act, marked up by the House Science Committee on June 25, 2026, would direct NIST to develop standardized model documentation templates, which would establish a federal reference for what an AIBOM should contain. Enterprise buyers often accept vendor-specific formats today if content is complete.
Model cards are narrative documentation for a specific model. AIBOM is structured, machine-readable disclosure that can integrate with buyer risk management tooling. Complementary artifacts.
The AI Vendor Risk Inventory™ includes AIBOM requirements as part of vendor diligence.
The questions that matter are not exotic. What model is inside this product? If it is fine-tuned, from what base? What was it trained on, and does that training data include personal information or copyrighted material? What evaluations were run, and what did they show, including the unflattering results? What is it known to be bad at? Under what licence is it supplied, and what does that licence let us do? An AIBOM that answers those six questions is more useful than one that conforms to a standard but says nothing.
Some vendors will decline to answer on the grounds of trade secrecy. Occasionally that is legitimate. Frequently it means they do not know, because they built on a foundation model whose provenance they never interrogated. A vendor who cannot describe their own training data has not done the diligence you are being asked to rely on, and their inability to produce an AIBOM is itself the finding.
Formats are converging. SPDX and CycloneDX both have AI and machine learning extensions in progress. The READ AI Models Act would direct NIST to publish standardised model documentation templates, which would give the market a federal reference point. Until that lands, buyers should specify the content they need rather than waiting for a format to be blessed, because the content requirement is not going to get smaller.
An AIBOM is an input, not an outcome. What it feeds is vendor risk management: the disclosure lets you assess whether a third-party model creates exposure under the EU AI Act, whether its training data raises questions under GDPR, and whether its documented evaluations satisfy the measurement expectations of NIST AI RMF. Collected and never read, an AIBOM is paperwork. Read against your obligations, it is the diligence record.
The authoritative texts and agency pages behind this summary. We keep this page current, but where a compliance decision turns on exact wording, read the source. Anything concerning AIBOM that carries legal consequence should be confirmed against the enrolled text or the issuing body, not against a secondary summary, including this one.
The AI Business Enablement Audit™ measures your organization against every framework in this library, including AI Bill of Materials, and delivers a defensible governance dossier. Start or finish your audit below.
Start or finish your AI Audit →