AI Bill of Materials

Definition

AI bill of materials is an umbrella term, also written AI BOM or AI-SBOM. ML-BOM is often used for a model-and-dataset-focused implementation. The names are not governed by one universal minimum schema, so a useful record must identify its exact format, version, profiles, subject, lifecycle stage, and declared scope.

An AI BOM extends a software bill of materials beyond packages and libraries where necessary. Depending on scope, its graph may identify model weights or hosted endpoints, base models and adapters, datasets and retrieval corpora, prompts and configuration, software and containers, tools and connectors, external services, relevant hardware, licenses, and evidence records. It should reference sensitive assets by stable identifier and controlled evidence link rather than copy raw training data, prompts, credentials, or personal information into a broadly shared document.

The artifact answers what was this defined system composed of, and how were those parts related at this time? It does not explain intelligence, prove provenance, certify safety, resolve licensing, or establish legal compliance. Those require separate evidence and judgment.

Boundary Tests

• AI system inventory: an organization-wide register of systems, owners, purposes, affected groups, risk tiers, and lifecycle status. An AI BOM usually describes the internal composition of one inventory entry or release.
• Model or system card: a primarily human-readable account of intended use, performance, limitations, evaluations, and mitigations. A BOM is primarily a structured component-and-relationship record and may link to the card.
• Data provenance or build provenance: evidence about where an artifact or dataset came from and how it changed. A BOM can carry or reference provenance but a component list is not itself proof of origin.
• Attestation or signature: a statement bound to a subject, commonly by digest, plus evidence of who signed it. Signing a BOM can authenticate its bytes and issuer; it does not make omissions or supplier claims true.
• Risk record: an evaluation, vulnerability report, VEX statement, safety case, audit, impact assessment, or legal review. These answer questions that the inventory alone cannot and should remain distinguishable evidence objects.

Current Context

The software foundation remains important. NTIA's 2021 report defines an SBOM as a formal record of software components and their supply-chain relationships. CISA's August 2025 minimum-elements document adds proposed fields such as component hash, license, tool name, and generation context, but its official PDF still labels itself a Public Comment Draft. It says the software minimum elements apply to AI software while leaving AI-specific additional fields and practices out of scope.

CycloneDX v1.7 is the project's current version and the basis of ECMA-424, second edition, published in December 2025. Its object model can represent machine-learning-model components, datasets, model-card information, services, dependency graphs, composition completeness, formulation, vulnerabilities, attestations, and citations. The project's ML-BOM guidance focuses on model and dataset transparency, including training approaches, framework configuration, provenance, privacy, safety, integrity, bias, and model-security context.

SPDX 3.0.1 provides an AI Profile for AI system and model artifacts. Its Dataset, Build, Security, Software, and licensing profiles are separate compliance points; claiming conformance to the AI Profile does not imply conformance to those other profiles. SPDX 3.1-RC1, announced in January 2026, remains a pre-release on the official project release page, so production records should not silently describe 3.1 draft fields as stable 3.0.1 behavior.

These standards overlap but do not yet supply one cross-format, universally required AI BOM baseline. That is an inference from their different models and from CISA's explicit exclusion of AI-specific minimum elements. Interoperability claims should therefore name the format and version rather than say only "AI BOM compliant."

Governance frameworks create demand without prescribing a BOM format. NIST AI RMF 1.0 calls for mechanisms to inventory AI systems and to map risks across all system components, including third-party software and data; NIST also states that AI RMF 1.0 is being revised. The EU AI Act does not name an AI BOM, but Article 11 and Annex IV set technical-documentation content for high-risk systems, while Article 53 sets documentation duties for general-purpose AI model providers within its scope and exceptions. The European Commission's AI Act Service Desk says the general-purpose-model rules became enforceable on August 2, 2026. An AI BOM may support those records; it is neither the prescribed format nor sufficient compliance evidence.

How It Works

1. Define the subject. Name the exact product, model release, API-backed configuration, container image, agent, or deployment the BOM describes. Give it a stable identifier and record lifecycle stage, environment, version, and intended use of the BOM.
2. Collect from authoritative points. Combine build manifests, package locks, model registries, dataset catalogs, training and fine-tuning pipelines, deployment configuration, service catalogs, supplier BOMs, and observed runtime inventory. Preserve which source contributed each claim.
3. Normalize identity. Use immutable hashes or digests where possible. For hosted services that expose no customer-verifiable artifact, record provider, service and model identifier, region or route where material, observation time, version guarantees, and the fact that the component is opaque or mutable.
4. Express relationships. A flat list cannot show that an adapter was derived from a base model, a model was trained or evaluated on a dataset, an agent invokes a tool, or a service retrieves from an index. Use relationship types supported by the chosen schema and document any extension vocabulary.
5. Link adjacent evidence. Reference provenance, signatures, licenses, contracts, model and system cards, evaluations, vulnerabilities, VEX, privacy reviews, risk acceptances, and incident records. Keep each record's issuer, subject, date, and evidentiary status visible.
6. Validate, bind, publish, and refresh. Validate against the named schema and profiles, bind the BOM to the release or deployment subject, control its distribution, and issue a new version when composition or knowledge changes. Consumers should diff releases and use the record in admission, procurement, monitoring, and incident response.

Minimum Evidence Record

• BOM envelope: format and schema version, profile declarations, unique BOM identifier and version, author, generation tool and version, timestamp, generation context, lifecycle phase, distribution marking, and signature or attestation reference.
• Subject: stable system or artifact identifier, supplier and owner, version, content digest where available, deployment environment, and link to the corresponding organizational inventory entry.
• Components: software, containers, models, weights, adapters, datasets, prompts or configuration, retrieval assets, tools, connectors, external services, and relevant hardware—each with type, name, supplier or origin, version or observed revision, identifier, and status.
• Relationships: direct and transitive dependency, derivation, training, fine-tuning, evaluation, packaging, serving, retrieval, tool invocation, and data-flow relationships to the extent supported and known.
• Rights and restrictions: declared and concluded licenses where the format distinguishes them, contractual or acceptable-use restrictions, data-use basis, export or residency constraints, and the source of each conclusion.
• Linked evidence: provenance and build records, model or system cards, dataset documentation, evaluations, safety or security findings, vulnerability and exploitability records, approvals, exceptions, and retention or deletion obligations.
• Completeness: declared boundary, covered lifecycle stages, direct and transitive depth, excluded categories, supplier blind spots, unresolved identities, and known unknowns. Silence must not be interpreted as absence.

Governance and Safety

• Integrity is not truth: a valid signature can show who issued an unchanged BOM, not whether the issuer discovered every dependency or accurately described training data, licenses, evaluations, or risk.
• Scope controls meaning: state whether the record covers source, build, training, release, deployment, or observed runtime. A model BOM does not automatically cover the product, agent tools, retrieval system, or cloud route around it.
• Unknowns are evidence: opaque vendor APIs, undisclosed datasets, unpinned model aliases, and unresolved transitive dependencies should be explicit. Procurement and risk policy can then decide whether an unknown is acceptable.
• Sensitive records need tiers: component names and relationships can expose personal data, trade secrets, model architecture, internal endpoints, security controls, or prompt content. Maintain a complete controlled record and purpose-specific redacted views rather than either publishing secrets or erasing the inventory.
• Freshness is a control: hosted models, retrieval corpora, agent tools, vulnerability knowledge, and policy layers can change without a traditional software release. Set refresh triggers and service-level expectations, not just an annual review date.
• Legal fields are claims: a license identifier, data-use assertion, or supplier warranty is not a legal conclusion. Preserve who asserted it, the supporting contract or analysis, jurisdiction, review date, and unresolved dispute.
• Operational ownership matters: assign producers and consumers for the BOM, correction authority, retention, disclosure, exception approval, and incident use. A document no team is required to query is inventory theater.

Failure Modes

• Name-only inventory: "GPT model," "vector database," or "vendor API" without a stable identifier, revision, supplier, or observation time cannot support exposure analysis.
• Flat-list blindness: components are present but derivation, dependency, serving, retrieval, and tool relationships are missing, so blast radius cannot be calculated.
• Snapshot mismatch: a release BOM is presented as if it described a silently updated hosted service or current runtime.
• Confident omission: unavailable supplier information is left blank rather than marked unknown, making an incomplete record appear complete.
• Evidence laundering: provider assertions, inferred metadata, scan output, and independently verified facts are displayed without source labels and become indistinguishable.
• Over-disclosure: raw prompts, credentials, personal data, proprietary dataset details, or internal topology are copied into a document with wider distribution than the source systems.
• Compliance substitution: possession of a BOM is treated as proof that the system is secure, unbiased, lawful, or fit for purpose.
• Dead artifact: the BOM is generated for procurement or release but never diffed, reconciled to deployment, or queried during a vulnerability, rights, safety, or incident event.

Defense Pattern

• Start with decisions. Define the questions the BOM must answer: affected deployments after a model or package flaw, prohibited licenses, data-rights changes, supplier incidents, tool revocation, or rollback.
• Name the standard exactly. Pin CycloneDX or SPDX version, serialization, profiles, extension vocabularies, and validation rules; test producer and consumer interoperability.
• Generate near the work. Capture components from build, training, registry, and deployment systems, merge supplier records, and reconcile them with observed runtime services.
• Bind records to subjects. Prefer digests for artifacts and use signed attestations or equivalent controls so consumers can verify which release a BOM describes.
• Measure coverage. Track represented, unresolved, opaque, and excluded components; require a reason and owner for material gaps.
• Gate meaningful changes. Diff model, dataset, prompt, tool, service, permission, and dependency relationships; route risk-significant changes through AI change management.
• Separate source from enrichment. Keep supplier facts, local observations, vulnerability matches, license analysis, risk decisions, and exceptions attributable and time-stamped.
• Rehearse incident queries. Demonstrate that responders can find every deployment affected by a model, dataset, package, connector, supplier, key, license, or policy change within a defined time.

Source Discipline

Every material field should carry an evidentiary status: observed by a named tool or process, declared by a supplier or owner, derived by stated logic, verified against identified evidence, or unknown. Record issuer, collection method, timestamp, and subject. "The BOM says" is not enough when the BOM merely repeats a vendor assertion.

Claims about format capability should cite the exact normative specification or schema version. Project overview pages are useful for orientation but cannot prove that a field exists in a particular release or that a generated document conforms. Validate the artifact and name optional profiles explicitly; for example, SPDX AI Profile conformance does not imply Dataset, Build, Security, or Software Profile conformance.

Distinguish a reference from possession. A BOM that names a training dataset does not contain its records or prove their provenance, consent, license, quality, or deletion status. A model-card link does not reproduce its evaluations. A vulnerability match does not establish exploitability. A signed document does not establish completeness. Preserve these boundaries in interfaces, reports, and procurement language.

Spiralist Reading

An AI bill of materials is an inventory of the machine's borrowed parts. A single interface can conceal weights, datasets, packages, prompts, vendors, tools, permissions, and people. The BOM interrupts that false unity by making composition and uncertainty inspectable. Documentary humility begins with naming what is present, what is connected, and what is still unknown.

Open Questions

• Which AI-specific fields should become a shared minimum across CycloneDX, SPDX, procurement rules, and sector standards?
• How should a BOM identify a hosted model that changes behind a stable product or alias?
• Which prompt, memory, agent-permission, and tool relationships can be standardized without exposing exploitable detail?
• How can a complete regulator or auditor view coexist with privacy-preserving, trade-secret, and public views?
• How should lineage survive fine-tuning, quantization, merging, distillation, synthetic-data generation, and retrieval-index refresh?
• Can affected people receive useful composition facts without being asked to interpret a supply-chain schema?

Related Pages

• CycloneDX
• System Package Data Exchange (SPDX)
• AI System Inventory
• Model Cards and System Cards
• AI Data Provenance
• SLSA Provenance
• in-toto
• Graph for Understanding Artifact Composition
• AI Change Management
• AI Procurement
• Secure AI System Development
• Agentic Supply-Chain Vulnerabilities
• Model Weight Security
• AI Data Licensing
• AI Audits and Assurance

Sources

• NTIA, The Minimum Elements for a Software Bill of Materials (SBOM), July 12, 2021; reviewed August 12, 2026.
• CISA, 2025 Minimum Elements for a Software Bill of Materials (SBOM), Public Comment Draft, August 2025; reviewed August 12, 2026.
• Ecma International, ECMA-424: CycloneDX Bill of materials specification, second edition, December 2025; reviewed August 12, 2026.
• CycloneDX, Specification Overview, v1.7, and Machine Learning Bill of Materials (ML-BOM), reviewed August 12, 2026.
• CycloneDX, CycloneDX v1.7 JSON Reference, reviewed August 12, 2026.
• SPDX, SPDX 3.0.1 AI Profile and Conformance, reviewed August 12, 2026.
• SPDX, SPDX 3.1-RC1 release, January 24, 2026; reviewed August 12, 2026.
• NIST AI Resource Center, AI RMF Core, reviewed August 12, 2026.
• European Commission AI Act Service Desk, Article 11: Technical documentation, Annex IV, and Article 53: Obligations for providers of general-purpose AI models, reviewed August 12, 2026.
• European Commission AI Act Service Desk, Frequently Asked Questions, applicability and enforcement guidance, reviewed August 12, 2026.
• SLSA, Provenance v1.2, reviewed August 12, 2026.
• in-toto, Statement v1 specification, reviewed August 12, 2026.

Return to Wiki