AI Bill of Materials: Track What Actually Runs

An AI bill of materials is useful only if it can answer two questions: what was declared before deployment, and what was actually running when a decision, incident, or audit happened. A valid JSON file that cannot answer both is inventory theater.

The practical design is a paired inventory. Generate a standards-based record during build or procurement, observe the live system at runtime, preserve evidence for each field, and diff the two. Block a release when a critical model, dataset, runtime, API, agent tool, or license is unresolved.

Reader level: Advanced. This guide is for engineers, security teams, platform owners, and technical governance leads who operate model-backed systems.

Contents

What an AI bill of materials should answer

An AI bill of materials, usually shortened to AIBOM or AI BOM, is a machine-readable inventory of the components and evidence behind an AI system. It extends a conventional software bill of materials beyond packages and libraries.

The inventory should let a reviewer answer:

CycloneDX describes its AI/ML-BOM capability as a way to represent models, datasets, configurations, provenance, and dependencies. SPDX 3.0.1 also defines an AI profile for AI-specific metadata. These are interoperable data models, not substitutes for the missing evidence itself.

A model card answers a narrower question: what is this model intended to do, how was it evaluated, and where can it fail? The original Model Cards paper proposed documentation covering intended use, evaluation conditions, and performance across relevant groups. A data card documents a dataset's origins, collection and annotation, intended use, and decisions that shape downstream performance; the Data Cards paper reports lessons from more than 20 deployments.

Keep both. A model card or data card supplies human context. An AIBOM connects those documents to a versioned system inventory.

Why valid AIBOM files can still contain weak evidence

A July 2026 study tested this distinction at scale. The authors collected a snapshot of 2,942,466 public Hugging Face model records, retained 97,940 models with more than 100 downloads, and generated CycloneDX AIBOMs with the OWASP AIBOM Generator. They checked a sample of 100 artifacts against the generator's reports and then measured field presence across the full set.

The reported mean completeness score was 54.31 out of 100. Required structural fields were present in 100% of the generated artifacts. Model-card documentation averaged 19.51%.

That gap is the important result. The file can be structurally valid while the information needed for a decision is absent.

The field-level results were sharper:

The description field appeared in almost every artifact, but only 211 of 97,940 descriptions contained information beyond placeholder text. A schema-presence check would count the other descriptions as complete.

What the authors measured: field and category coverage in AIBOMs generated from a filtered public Hugging Face snapshot.

What they inferred: model-card and external-reference documentation drive much of the difference between weak and stronger artifacts.

What they did not establish: whether any model was safe, fair, performant, legally usable, or appropriate for a particular deployment.

The authors also warn that their results depend on the Hugging Face API, generator extraction logic, and a snapshot that excludes models with 100 or fewer downloads. Private registries, gated models, other hosting platforms, and later repository changes may look different. Their result supports semantic validation. It does not set a universal score threshold.

Build-time inventory and runtime inventory solve different problems

A build-time AIBOM records intent. A runtime inventory records observation.

Build-time evidence alone misses emergency changes, shadow deployments, mutable tags, provider rerouting, and configuration drift. Runtime observation alone may see a process name or endpoint without knowing its approved purpose, license, training provenance, or evaluation boundary.

Google open-sourced k8s-aibom on July 14, 2026, to explore the runtime side. The controller watches Kubernetes workload and pod state, applies detection rules, and emits CycloneDX 1.6 ML-BOM documents. Its documented coverage includes inference runtimes, agent frameworks, vector databases, training jobs, and evaluation harnesses. It runs without a privileged DaemonSet or kernel access.

The project makes a useful architectural point: build-time and runtime AIBOMs are complementary. It is also early software. The repository labels v1.0 as alpha and suitable for non-critical observation use cases. It does not ship a hosted image or Helm repository, and its current `NoopVerifier` cannot mark an identity as cryptographically verified.

An NVIDIA AICR maintainer proposed a k8s-aibom and AICR integration that would connect k8s-aibom's runtime observations with AICR deployment intent and signed attestations. The author describes the goal as evidence that what a team deployed is what the system is running. The issue has no linked implementation, assignee, or milestone. Treat it as a practitioner proposal, not an official roadmap or completed design.

Do not turn one new controller into a universal product recommendation. Use the pattern: pair declared state with observed state, retain evidence, and make uncertainty visible.

_A useful AI bill of materials connects build intent to runtime evidence, semantic checks, and a versioned decision._

The seven layers worth recording

The exact schema depends on your standard and deployment. The following layers form a practical minimum for a production inventory.

1. Model identity

Record the supplier, model family, immutable revision or digest, format, base model, adapters, quantization, tokenizer, and serving route. A friendly alias such as `support-model` is useful for people but insufficient for traceability.

For an external API, record the provider's stable model identifier and the gateway route that selected it. If the provider can silently update the model behind an alias, label the revision unresolved instead of inventing precision.

2. Data and retrieval dependencies

Record declared training, fine-tuning, evaluation, and calibration datasets when that information exists. For a RAG system, add the source collections, embedding model, chunking version, vector-store service, access policy, and freshness boundary.

Store dataset identifiers, versions, hashes, contracts, or controlled catalog references. Do not copy raw customer records or private training examples into the AIBOM.

3. Runtime and software

Connect the AI inventory to the ordinary SBOM. Record the container digest, inference engine, framework, relevant libraries, driver and accelerator class, and configuration that can change model behavior.

4. Tools, APIs, and agent permissions

List tools an agent can reach, not every tool installed somewhere in the company. Include model gateways, MCP servers, browser or code-execution tools, external APIs, and the policy reference that governs each action.

5. Evaluation and operating limits

Reference the exact evaluation set, evaluator version, thresholds, date, and conditions used for approval. Record known failure modes, intended and excluded uses, fallback behavior, monitoring owner, and expiry date for the decision.

Do not write “passed evaluation” without the test identity. A changed model with an unchanged result string is weak evidence.

6. Rights, policy, and provenance

Record model and dataset licenses, use restrictions, redistribution terms, source repositories, model cards, data cards, papers, approvals, and attestations. Store references and hashes when the source is access-controlled.

This layer supports review. It does not decide a legal question. Missing or conflicting rights information should route to the person accountable for that decision.

7. Ownership and lifecycle

Every record needs an owner, system purpose, environment, creation time, observation time, superseded version, and retention rule. Without ownership, an inventory becomes an archive of abandoned facts.

Include a stable system ID that survives redeployments. A versioned AIBOM should show the history of what changed, who accepted it, and which evidence supported that decision.

Label every fact as declared, inferred, verified, or unresolved

An AIBOM should carry evidence status at field level. One label for the whole document hides too much.

The first three labels describe different strengths of evidence. “Declared” is not a weaker spelling of “verified.” A supplier declaration may be the only available source for training data, while an image digest can be verified mechanically.

The k8s-aibom project currently implements `declared`, `inferred`, and `unresolved`, with evidence locators for attributes. Its README puts cryptographic `verified` status on the roadmap rather than claiming it now. Preserve that honesty in your own system.

A conceptual record could look like this:

{
  "system_id": "customer-support-prod",
  "component": {
    "type": "machine-learning-model",
    "name": "provider/model-family",
    "version": "immutable-revision",
    "hashes": ["sha256:..."]
  },
  "evidence": {
    "status": "verified",
    "source": "signed-build-attestation",
    "observed_at": "2026-07-29T08:00:00Z"
  },
  "depends_on": [
    "runtime:inference-engine@version",
    "dataset:retrieval-corpus@revision",
    "api:model-gateway@policy-version"
  ]
}

This is a design sketch, not a conforming CycloneDX or SPDX document. Use the chosen standard's schema and validator for the real artifact.

A reproducible AIBOM workflow

Step 1: define the system boundary

Name the application, environments, owners, and user-facing decisions in scope. Decide whether the inventory covers one model endpoint, an agent workflow, or a complete product.

A boundary such as “all AI” cannot be tested. “The production support agent and every service that can alter its answer or actions” can.

Step 2: collect build and procurement evidence

Generate the ordinary SBOM, resolve model and dataset identifiers, capture immutable digests, and link model cards, data cards, licenses, evaluations, and approvals.

The OWASP AIBOM Generator can extract Hugging Face metadata into CycloneDX 1.6 and report missing fields. Treat its output as a starting inventory. The large-scale study shows why an automatically populated field still needs a content check.

Step 3: emit a standard document

Choose a format your consumers can parse. CycloneDX provides an AI/ML-BOM capability and an implementation guide. SPDX 3 provides AI and dataset profiles.

Format selection should follow the receiving systems, policy engine, attestation pipeline, and customer requirements. Avoid maintaining two formats unless a real consumer needs both.

Step 4: enrich what automation cannot know

Assign owners to fill intended use, limitations, dataset provenance, evaluation conditions, rights, and risk decisions. Reject placeholders such as “N/A,” “standard model,” or copied marketing text when the field is decision-critical.

Require an explicit reason for unknown values. “Supplier does not disclose training data” is better evidence than an empty array because it distinguishes missing work from unavailable information.

Step 5: observe the live deployment

Collect runtime model IDs, image digests, endpoints, connected stores, agent tools, and configuration through the least-privileged mechanism available. In Kubernetes, that may be an API-watching controller. In a managed API stack, it may be gateway configuration, deployment manifests, provider responses, and audit logs.

Do not claim runtime verification when the scanner only matched a string. Mark it inferred and retain the matching evidence.

Step 6: validate syntax, semantics, and drift

Run three separate checks:

The first check is automated. The second needs domain rules and, for some fields, human review. The third needs versioned records and a stable comparison boundary.

Step 7: sign, store, diff, and expire

Hash the artifact, bind it to the build or deployment, store it in an append-only or controlled evidence system, and produce a human-readable diff. AIBoMGen is one research prototype that combines model and environment capture with hashes, signatures, and in-toto attestations during training.

Signatures protect integrity after creation. They do not make an incomplete or false declaration true.

Set an expiry or review date. A perfect inventory from last quarter does not describe a mutable production system today.

Turn the inventory into a release gate

An inventory becomes useful when it changes a decision. Define policy before the release window.

Tune severity to the system. A writing assistant and a medical decision tool should not share one universal threshold.

Track four operational measures:

Do not optimize for the number of fields populated. That recreates the exact failure the completeness study exposed.

Keep secrets and personal data out

An AIBOM is likely to circulate among engineering, security, auditors, customers, and automated systems. Treat it as an inventory, not a secret store.

Do not include:

Reference secrets by secret-manager path or logical identifier without including the value. Reference sensitive datasets through a governed catalog ID, version, classification, owner, and integrity hash. Apply access control to the complete artifact when even its metadata is sensitive.

What an AIBOM cannot prove

An AI bill of materials improves traceability. It does not prove:

The July completeness study measures documentation coverage, not model quality. The k8s-aibom repository explicitly says its output does not certify compliance. Both limitations matter.

Use the AIBOM as a map from a decision to inspectable evidence. Pair it with evaluation, authorization, monitoring, incident response, privacy controls, and accountable review. The map makes those processes faster because it tells each reviewer what system they are assessing.

Frequently asked questions

What is an AI bill of materials?

An AI bill of materials is a machine-readable inventory of the models, datasets, software, runtimes, tools, provenance, restrictions, and evidence behind an AI system. A useful AIBOM identifies immutable versions, owners, unresolved facts, and changes between approved and live state.

Is an AI BOM the same as an SBOM?

No. An SBOM inventories software components and dependencies. An AI BOM connects that software inventory to AI-specific components such as models, datasets, adapters, evaluations, intended uses, limitations, and runtime routes. A production AI system usually needs both.

Should I use CycloneDX or SPDX for an AIBOM?

Use the format your downstream tools and evidence consumers support. CycloneDX has a documented AI/ML-BOM capability; SPDX 3 has AI and dataset profiles. Validate one canonical format first. Add a second only when a policy, customer, or integration requires it.

Claim checks

Sources