Definition
An AI bill of materials (AI-BOM) is a structured record of components and relationships for a defined AI system. The term is used across formats and does not mean every AI-BOM has the same schema. Define the system boundary first, then record what is known about models, datasets, software dependencies, tools and relevant configuration revisions. Keep the accountable business-system inventory linked to the component record: one explains the service and owner; the other helps trace dependencies.
CycloneDX describes an ML-BOM for model, compositional-asset and lifecycle information. SPDX 3.0.1 defines an AI Profile for AI application and model artifacts, while its Dataset Profile separately describes dataset information. These are different machine-readable models; a generic spreadsheet is not automatically compliant with either.
AI-BOM vs SBOM
A software bill of materials (SBOM) records software components and their relationships. An AI-BOM or ML-BOM may add model identifiers, datasets, training or evaluation references, prompt/configuration versions, and other AI-specific information when the chosen format supports it. Scope varies by implementation. Preserve links between the records rather than assuming one replaces the other: a software library change, model revision or data-source change can affect the same deployed AI workflow.
NIST AI RMF 1.0 MAP 4.1–4.2 discusses mapping risks and internal controls for AI-system components, including third-party software and data. That is risk-management guidance, not a BOM schema or a claim that a component list is complete. NIST marks AI RMF 1.0 voluntary and says it is being revised.
Fields
For a practical, manually maintained component map, begin with:
- System link: stable system ID, deployment/environment, accountable owner and defined boundary.
- Component: type (model, dataset, software/framework, tool/service or configuration), name, supplier/source and stable identifier where available.
- Version and relationship: pinned version, revision or provider identifier; how the component is used by the system; parent/dependency links.
- Data and model provenance: dataset source and known lineage; model source and known base/fine-tuning relationship. Mark unavailable facts as unknown rather than guessing.
- Governance references: evidence location, license or contract reference, reviewer, review date and change trigger. Keep secrets and restricted source data out of the BOM.
Choose one format and version before exchanging machine-readable files. Consult the CycloneDX ML-BOM overview and authoritative guide, or the SPDX 3.0.1 AI Profile and Dataset Profile. Check the selected release's schema and profile rules before claiming conformance.
Example
The following is a hypothetical CRM summarisation workflow, not a discovered system or a generated BOM:
| Component | Illustrative record | Relationship / evidence to verify |
|---|---|---|
| Business system | crm-summary-prod, production | Owned by sales operations; confirm system boundary and intended use |
| Model service | Provider model alias; immutable revision unknown | Processes draft requests; obtain provider/version evidence if available |
| Runtime | Orchestration package, version not verified | Connects the model to the CRM reader; check the deployed lockfile |
| Data source | CRM customer notes, confidential category | Read-only access is claimed; verify effective permission and approved data scope |
| Prompt/configuration | Summary instruction revision not verified | Owner keeps a controlled revision reference; do not copy customer text into this record |
If the CRM connector later gains write permission, record the changed component/configuration and review the system's permitted actions. Do not infer a model's training data, provider controls, evaluation result or regulatory category from an inventory row.
Tools
Collect component data from authorised package manifests, model/deployment records, data-owner documentation and change tickets, then have the relevant owners verify the entries. Mark each source and observation date; a manifest describes recorded dependencies, not necessarily every runtime behavior. Select a BOM tool only after checking support for the exact format/version and whether it preserves required relationships and provenance.
The Agent Inventory Tool on this site is a manual starter inventory. It does not discover dependencies, create CycloneDX or SPDX documents, validate a BOM schema, or certify AI-BOM completeness. Its CSV is not a standards-conformant AI-BOM. The public ISO/IEC 42001 overview describes an AI management-system standard, but licensed normative clauses were not available in the reviewed sources, so this page makes no Annex A mapping. The EU AI Act reference in the content plan is not interpreted here; an inventory does not decide legal classification or registration duties.
Continue with the AI agent inventory builder, the AI inventory template, or the AI agent inventory template.
Sources: CycloneDX ML-BOM; CycloneDX authoritative guide to AI/ML-BOM; SPDX 3.0.1 AI Profile; SPDX 3.0.1 Dataset Profile; NIST AI RMF 1.0; NIST AI RMF status; ISO/IEC 42001 public overview; EU AI Act official text.