What is an AIBOM? The AI Bill of Materials explained

An AI Bill of Materials records the models, datasets, software and services an AI system is built from, and how they relate. This guide covers what goes into one, which formats encode it, and why regulators and buyers now expect it.

Definition

CERT-In defines an Artificial Intelligence Bill of Materials (AIBOM) as "a comprehensive list of components used in building, training, and deploying AI models" ^[1]. In practice, an AIBOM is a machine-readable record of everything an AI system depends on: the trained model and its weights, the base model it was fine-tuned from, the datasets used to train and evaluate it, the software frameworks that load and serve it, the hardware and infrastructure it runs on, and any external model APIs it calls. It also records the relationships between those parts, so that a question about one component can be traced to every system that relies on it.

The idea extends the software bill of materials. An SBOM lists packages, versions and suppliers. An AIBOM keeps that information for the code around a model, and adds the things that make AI systems different: training data, model lineage, evaluation results, intended use and known limitations.

Why AI systems need their own bill of materials

AI systems have supply chains that a traditional SBOM does not capture well. A credit-scoring service may depend on a model trained in-house, fine-tuned from an open-weight base model, trained on several datasets, served by an ML framework, and supplemented by calls to a hosted language model. Each of these has a version, an origin, a licence and its own risks, and several can change without any change to application code: a provider updates a hosted model, a data pipeline refreshes a training set, or a team swaps an adapter.

The security community treats this as a distinct attack surface. The 2025 OWASP Top 10 for LLM Applications lists supply chain as LLM03, covering vulnerable pre-trained models, weak model provenance, malicious LoRA adapters and licensing risk ^[2]. MITRE ATLAS catalogues "AI Supply Chain Compromise" (AML.T0010) with sub-techniques for hardware, AI software, data and models ^[3]. Without an inventory, an organisation cannot tell which of its systems are exposed when one of these components is found to be compromised. See AI supply-chain risks for the detail.

What an AIBOM records

CERT-In's Table 10 sets out minimum AIBOM elements. The verified entries include Model Name, Model Version, Model Type, Model Developer, Model Licensing Information, Software Dependencies, ML Models and Algorithms, Model Performance Metrics, Data Source and Data Sets Information ^[1]. The G7 Cybersecurity Working Group's SBOM for AI: Minimum Elements, published in May 2026, groups its recommendations into seven clusters ^[4][5]:

The G7 document states that these clusters are not mandatory and that an SBOM for AI alone is not sufficient for supply-chain security without supporting tools such as vulnerability scanners and security advisories ^[5]. Organisations usually add operational fields of their own: the hash of each model artefact, the base model and fine-tuning runs, the business owner, the applications that call the model, and the approval status.

Formats: CycloneDX and SPDX

Two open standards encode AIBOMs.

• CycloneDX introduced machine-learning BOM support in version 1.5 (June 2023) ^[6]. A component can have type machine-learning-model or data, and a model component carries a modelCard with model parameters, quantitative analysis and considerations such as use cases, technical limitations and ethical considerations ^[7]. The current version is 1.7, released in October 2025 ^[8].
• SPDX 3.0, released in April 2024, added AI and Dataset profiles ^[9]. The AIPackage class includes properties such as typeOfModel, informationAboutTraining, metric, limitation, safetyRiskAssessment and energyConsumption ^[10]; DatasetPackage covers dataCollectionProcess, knownBias, hasSensitivePersonalInformation and more ^[11].

Both can be exchanged with suppliers and regulators. The field-by-field differences are covered in SPDX 3.0 AI profile vs CycloneDX ML-BOM.

AIBOMs, model cards and datasheets

Model cards (Mitchell et al., 2019) and datasheets for datasets (Gebru et al.) predate AIBOMs and remain useful. They are primarily human-readable documents about one model or one dataset. An AIBOM is machine-readable, covers the whole system and its dependencies, and is designed to be diffed, validated and correlated with vulnerability data. CycloneDX's modelCard object shows how the two fit together: the card becomes structured data inside the bill of materials ^[7]. See AIBOM vs model cards.

Who asks for an AIBOM

India. CERT-In's Version 2.0 guidelines include the AIBOM alongside SBOM, CBOM, QBOM and HBOM, and describe its benefits as security, transparency, compliance and risk management ^[1]. Commentary on the guidelines notes that government, public-sector and essential-services organisations are expected to include AIBOM requirements when procuring AI ^[12]. The RBI's FREE-AI committee report (August 2025) recommends AI inventories covering models, use cases, dependencies and risks ^[13].

European Union. The AI Act requires technical documentation for high-risk AI systems, including the versions of relevant software, pre-trained systems or tools provided by third parties, and datasheets describing training data and its provenance ^[14]. The AI Omnibus, in force since 27 July 2026, moved the application dates for high-risk rules to 2 December 2027 (Annex III) and 2 August 2028 (Annex I) ^[15].

Frameworks. The NIST AI Risk Management Framework and ISO/IEC 42001 both expect organisations to know which AI systems they run and what those systems depend on ^[16][17]. An AIBOM is the most direct way to show that. See AIBOM compliance for the mapping.

The AIBOM lifecycle

1. Discover models, datasets and AI services across code, registries, notebooks and API gateways (AIBOM generation).
2. Describe each component with the required fields, including provenance and hashes.
3. Validate the document against the schema and against a policy of required fields (AIBOM validation).
4. Approve models before production and record who approved them (AIBOM management).
5. Correlate components with vulnerabilities, licences and the business services that depend on them.
6. Update the AIBOM whenever a model is retrained, replaced or pointed at a new provider, and keep the history.

Common gaps

• Hosted models left out. External model APIs are often missing because nothing is installed locally. They are frequently the components that change most often.
• Unpinned versions. A reference to "latest" or to a model name without a revision or hash cannot be verified later.
• Dataset provenance missing. Training data is described in prose, or not at all, which makes licence and privacy questions hard to answer.
• Snapshots, not records. An AIBOM produced once for an audit goes stale as soon as the model is retrained.

How IntelliXBOM helps

IntelliXBOM generates and ingests AIBOMs in CycloneDX and SPDX, validates them against required-field policies such as the CERT-In AIBOM elements, and keeps version history with diffs as models change. It correlates models, datasets and frameworks with vulnerabilities, licences and the business services that depend on them, and maps the inventory to framework controls with timestamped evidence. It can be self-hosted, including in air-gapped environments.