# The AI Bill of Materials Is an Operational Record

## What an inventory must show before it can support security, change, and incident response

Author: Jason Doyle

First published: 8 September 2026

> Disclosure: These views are my own and do not represent my current or any former employers. This paper uses only public sources and does not describe non-public product information.

## Executive summary

An AI system can change without its application code changing.

A model provider can retire a version or move a deployment to a replacement.
An embedding model can change. A retrieval index can be rebuilt. A prompt can be
edited. A fine-tuning dataset can be withdrawn. An agent can gain a new tool. A
model file can bring an unsafe deserialisation path into an otherwise familiar
software stack.

A conventional software bill of materials can identify libraries, packages,
containers, and some of their dependency relationships. It may say little about
the model, training and evaluation data, prompt configuration, retrieval
artifacts, hosted services, agent authority, or evidence used to approve the
deployed system.

The G7 Cybersecurity Working Group addressed this gap in 2026 with *Software
Bill of Materials for AI - Minimum Elements*. The guidance says that AI systems
remain software systems, so the AI-specific information supplements rather
than replaces an ordinary SBOM. It proposes 50 elements across seven clusters:
metadata, system-level properties, models, datasets, infrastructure, security
properties, and key performance indicators.\[1\]\[2\]

The guidance is deliberately limited. The elements are non-mandatory,
non-exhaustive, and expected to evolve. The document also states that an SBOM
for AI is insufficient by itself. It has to connect to vulnerability
management, advisories, and other security tools before the inventory can
support protection of the supply chain.\[1\]\[2\]

That is useful progress. It also exposes a category problem.

A model hash is a component identifier. A supplier's description of known
limitations is a declaration. An internal evaluation result is an assessment.
The model endpoint active for one production request is a runtime observation.
System uptime is a time-bound operational measure. These records have different
owners, evidence, freshness, and confidence. Placing them in one inventory
without preserving those differences can make weak claims look verified and
old observations look current.

This paper proposes an operational model for an AI Bill of Materials:

1. Record the AI system as a dependency graph rather than a flat component
   list.
2. Bind that graph to a specific build, release, deployment, and operating
   environment.
3. Classify each entry as a verifiable component fact, supplier declaration,
   organisational assessment, deployment observation, runtime observation, or
   explicit unknown.
4. Keep stable composition records separate from dynamic assurance and
   operational evidence, while linking them through durable identifiers.
5. Connect the record to vulnerability response, model migration, evaluation,
   incident investigation, and recovery workflows.
6. Protect sensitive versions of the record rather than assuming every detail
   should be public.

An operational AI BOM should answer practical questions:

- Which production systems use the affected model, dataset, library, or hosted
  service?
- Which prompts, retrieval indexes, tools, and policies were active in the
  affected release?
- Which supplier statements were independently tested?
- Which outputs or actions were produced under that composition?
- What must be reevaluated when a model, embedding service, or dataset changes?
- Can the affected component be isolated or replaced?
- What remains unknown?

The public record shows why these questions matter. A compromised
`torchtriton` package entered PyTorch nightly installations through dependency
confusion and attempted to exfiltrate system and user files.\[16\] A later
PyTorch advisory described remote code execution through a bypass of
`torch.load(weights_only=True)`.\[17\] Hugging Face created and independently
audited the `safetensors` format because pickle-based model loading can execute
malicious code.\[18\] LAION temporarily withdrew its datasets after researchers
reported links to suspected illegal material.\[24\]\[25\] Major hosted model
providers publish retirement and migration policies because model versions and
service interfaces do not remain available indefinitely.\[20\]\[21\]\[22\]\[23\]

These cases do not prove that an AI BOM would have prevented the underlying
event. An inventory does not establish that a component is safe, accurate,
fair, lawful, or suitable for a particular use. A hash proves equality with a
known digest, not trustworthiness. A signed declaration identifies the signer
and protects integrity, but it does not make the claim true.

The value of an AI BOM is narrower and operational. It reduces the time required
to identify what is present, where it came from, how it is connected, what
changed, which evidence applies, and which systems require action.

Treat the AI BOM as a map. Assurance comes from the evidence, controls, and
operating processes connected to that map.

## 1. The model is one component

Production AI is assembled from more than a model.

Consider a document assistant that answers questions and can create a support
case. Its behaviour may depend on:

- the application and ordinary software packages;
- the hosted or self-managed model;
- model weights, architecture, tokeniser, and inference configuration;
- system and developer prompts;
- safety and policy instructions;
- source documents and their access controls;
- an embedding model;
- chunking and metadata rules;
- a vector index and its build time;
- a reranker;
- tool definitions and argument schemas;
- the identity used for retrieval and actions;
- memory retained from earlier interactions;
- output validation and post-processing;
- a case-management API;
- infrastructure, hardware, and regional deployment choices.

Each component can change independently. Some are immutable files. Some are
database state. Some are configuration. Some are external services whose
internal implementation is unavailable to the deployer.

An ordinary SBOM remains necessary. The assistant still depends on an operating
system, language runtime, client libraries, parsers, web frameworks, container
images, and cryptographic packages. Those components create familiar
vulnerability and licensing obligations.

The ordinary SBOM cannot always identify:

- which hosted model deployment served a request;
- which model artifact a provider name referred to at that time;
- which prompt or policy version governed the response;
- which corpus snapshot and embedding model produced the active index;
- which tools the agent could call;
- which permission set the tool used;
- which evaluation result justified promotion;
- which supplier claims were accepted without independent verification.

This is why AI-specific inventory work cannot begin and end with the package
manager.

The missing information is also why "model inventory" is too narrow. A model
may be unchanged while the system behaves differently because retrieval,
prompting, tool access, or policy changed. A deployment can fail after an
embedding model retirement even when its generation model remains available.
A vulnerable model loader can matter even if the model weights themselves are
benign.

The operational unit is the assembled AI system.

## 2. What an AI Bill of Materials means

The terminology is not settled.

The G7 guidance uses "SBOM for AI". CISA describes it as supplemental
information for an AI system on top of the general SBOM minimum
elements.\[1\]\[3\]

SPDX 3 defines an `AIPackage` with properties including model type, training
information, limitations, hyperparameters, metrics, safety risk assessment, and
use of sensitive personal information. Its `DatasetPackage` records properties
such as collection, preprocessing, availability, known bias, sensitivity, and
intended use.\[5\]\[6\]

CycloneDX uses "AI/ML-BOM" and represents models, datasets, configurations,
training methods, provenance, and risk-related information within its broader
BOM model.\[7\]\[8\]

Other records serve related purposes:

| Record | Main purpose | Typical limitation |
| --- | --- | --- |
| Ordinary SBOM | Software component identity and relationships | Does not describe the full AI system |
| ML-BOM | Models, datasets, training, and related dependencies | May stop at model development |
| AI system BOM | Composition of the deployed AI system | Scope and terminology still vary |
| Model card | Intended use, performance, limitations, and evaluation context | Usually human-readable and model-focused |
| System card | Safety work and residual risk for an assembled system | Not a dependency graph |
| Attestation | Authenticated claim about an artifact or process | Validates the statement's origin, not its truth |
| Runtime trace | What happened during one execution | Expensive, sensitive, and too detailed for inventory |

The model-card proposal described model cards as short records accompanying
released models, including intended uses, evaluation results, and
limitations.\[9\] SLSA defines an attestation as an authenticated statement
about one or more software artifacts.\[10\] Those records can be linked to a
BOM, but they should not be collapsed into the same concept.

This paper uses "AI Bill of Materials", or "AI BOM", to mean:

> A machine-processable record of the components, relationships, evidence, and
> deployment identity required to understand the composition of an AI system.

That definition is intentionally system-focused. It includes ordinary software
and AI-specific components. It also requires links to evidence and deployment
state because a generic list of possible ingredients cannot explain what was
actually running.

## 3. What the G7 baseline adds

The G7 minimum-elements document is one of the more complete international
attempts so far to describe the additional information an AI supply-chain
record should contain.

It divides the record into seven clusters:

| Cluster | Elements | What it records |
| --- | --- | --- |
| Metadata | 10 | BOM author, version, format, signature, generation tool, context, timestamp, and relationships |
| System-level properties | 9 | System identity, version, producer, components, data flow, data use, inputs, outputs, and intended application |
| Models | 13 | Model identity, version, producer, hash, architecture, inputs, outputs, training, licence, limitations, and references |
| Dataset properties | 10 | Dataset identity, content, hash, provenance, statistics, sensitivity, relationships, and licence |
| Infrastructure | 2 | Software and hardware required to run the system |
| Security properties | 4 | Controls, compliance, published security information, and vulnerability references |
| Key performance indicators | 2 | Security metrics and operational measures |

The count matters less than the shape of the proposal. It recognises that a
useful record needs:

- a version and author of its own;
- machine-processable relationships;
- system-level data flow;
- model lineage;
- training and post-training information;
- dataset provenance and sensitivity;
- infrastructure beyond the model;
- security and operational context.

The document also contains several important boundaries.

First, it states that the elements are non-mandatory and non-exhaustive. The
guidance does not create a standard, legislation, or a complete implementation
model.\[1\]\[2\]

Second, it says AI systems are software systems. The AI-specific elements are
additional to the ordinary SBOM rather than a substitute for it.\[1\]\[2\]

Third, it warns that the record is insufficient without operational security
tooling. The document calls for connections to vulnerability scanning,
vulnerability management, security advisories, and bulletins.\[2\]

Fourth, the discussion considered the decision-making or autonomy level of an
AI system but did not make it a separate element. The authors note that
autonomy may become more relevant as agentic systems develop.\[2\]

The baseline therefore establishes a useful starting point while leaving open
questions about prompts, retrieval indexes, memory, tool authority, approval
boundaries, and request-level runtime evidence. Some can fit inside
system-level properties or dependency relationships. They do not yet have
consistent first-class treatment across the main BOM formats.

Other guidance fills part of that gap. The UK National Cyber Security Centre
asks AI providers to document the creation, operation, and lifecycle management
of models, datasets, and meta- or system prompts. Its examples include training
data sources, intended scope, limitations, guardrails, hashes or signatures,
retention, review frequency, and failure modes. It lists model cards, data
cards, and SBOMs as useful structures rather than treating any one of them as a
complete answer.\[4\]

NIST takes a similarly broad lifecycle view. The AI Risk Management Framework
organises work through Govern, Map, Measure, and Manage. Its Generative AI
Profile includes risks created by value chains and component integration, while
SP 800-218A adds AI-specific practices to the Secure Software Development
Framework for model producers, system producers, and acquirers.\[11\]\[12\]\[13\]

There is another unresolved issue. Some G7 elements describe stable
composition. Others describe changing state.

A model hash may remain valid for the life of an artifact. Uptime, latency,
incident resolution time, security controls, and vulnerability status can
change after the BOM is generated. Recording all of them is useful only when
the record also preserves their source and observation time.

## 4. Composition is a graph

A component list answers "what exists?" A dependency graph also answers "what
depends on it?"

That difference determines whether an inventory can support incident response.

Suppose an advisory affects a model-loading library. A flat list can show that
the package exists somewhere in the estate. A graph can show:

- which model artifacts are loaded through it;
- which builds include the affected version;
- which deployments run those builds;
- which customer workflows call those deployments;
- which replacement path has already been tested.

The same applies to datasets. A model may be fine-tuned from another model
whose training lineage includes a dataset that is later withdrawn. The
relationship needs to show derivation, not merely that both names appear in an
inventory.

Useful relationship types include:

- contains;
- depends on;
- trained on;
- fine-tuned from;
- distilled from;
- evaluated with;
- indexes;
- embeds with;
- retrieves from;
- governed by;
- can invoke;
- deployed as;
- replaced by;
- observed in.

Not every relationship belongs in every exchange format. The internal record
can still preserve a richer graph and export the subset required by a
particular consumer.

The graph should also distinguish direct and transitive dependencies. A team
may choose a hosted agent platform without directly selecting its model,
embedding service, content filter, or orchestration library. Those dependencies
still affect the service, even when the deployer cannot inspect them.

Opacity should be represented as opacity. It should not disappear from the
graph.

## 5. Different entries carry different evidence

An AI BOM can create false confidence when every field appears equally
authoritative.

Consider six entries:

| Entry | Evidence class | What it establishes |
| --- | --- | --- |
| SHA-256 digest of a model file | Verifiable component fact | The observed file matches a known digest |
| "Designed for customer support" | Supplier declaration | The supplier states an intended use |
| Internal regression pass rate | Organisational assessment | A defined test produced a result at a stated time |
| Active deployment model ID | Deployment observation | The platform reported a configured model reference |
| Model ID recorded for one request | Runtime observation | That request was associated with the recorded reference |
| Training dataset unavailable | Explicit unknown | The deployer cannot verify the upstream dataset |

These entries should not share an unqualified "verified" label.

### Verifiable component facts

Examples include cryptographic hashes, signed artifact references, immutable
package identifiers, and source commit identifiers.

Verification still has limits. A hash proves that two byte sequences are the
same. It says nothing about whether the content is safe or suitable. A
signature can establish integrity and signer identity when the key is trusted.
It does not validate every claim inside the signed record.

### Supplier declarations

Model descriptions, intended uses, known limitations, training methods,
licences, and compliance statements often come from the producer. They remain
valuable. They should retain the supplier, source document, version, and date.

The deployer should be able to distinguish "the supplier states this" from "we
tested this".

### Organisational assessments

These include evaluations, threat models, red-team results, privacy reviews,
compatibility tests, and release decisions. They need a method, scope, result,
owner, and observation time.

An evaluation score without the dataset, configuration, and model reference
cannot be applied safely to a later release.

### Deployment observations

Cloud and platform APIs can report deployment identifiers, regions, model
references, runtime versions, and configuration. This evidence describes the
configured system at an observed time.

It may still differ from request-level behaviour if the provider performs
rolling upgrades, routing, failover, or dynamic policy changes.

### Runtime observations

Request-level records can bind an output or action to a model reference, prompt
version, retrieved sources, tool calls, and policy result.

These records are valuable during investigation. They can also contain
sensitive input, output, and identity data. The BOM should link to the
appropriate trace or replay package rather than copying unrestricted runtime
content into a broadly distributed inventory.

### Explicit unknowns

The G7 guidance allows unknown values where an author cannot obtain a model
version or hash.\[2\]

Unknown is a useful state. It should include:

- what is unknown;
- why it is unavailable;
- who owns the dependency;
- the consequence of not knowing;
- whether another control compensates;
- the next review or supplier request.

An empty field hides uncertainty. An explicit unknown makes it reviewable.

## 6. Bind the record to a deployed release

A correct inventory of possible components can still be operationally useless.

The record needs to identify a specific system release and deployment:

- system name and version;
- source revision;
- build identifier;
- ordinary SBOM identifier;
- AI BOM identifier;
- deployment identifier;
- environment and region;
- promotion time;
- configuration revision;
- rollback target;
- owner.

This becomes difficult with hosted models.

The deployer may receive a model name without access to the weights or a
cryptographic digest. The same model can have different lifecycle dates across
provider-operated and partner-operated platforms. Anthropic's documentation
states that retirement schedules can differ between its own platform, Amazon
Bedrock, and Google Cloud.\[21\]

Microsoft Foundry documents another operational distinction. Preview
deployments may be force-upgraded or retired, standard deployments can be
upgraded automatically, and provisioned deployments require manual migration.
The current model lifecycle also depends on deployment type and region.\[20\]

OpenAI and Google publish separate retirement schedules and notice policies.
Google's schedule includes embedding models as well as generation models,
which matters because retrieval behaviour can change when an embedding
dependency moves.\[22\]\[23\]

The AI BOM should record what the deployer can observe:

- provider;
- platform;
- model or endpoint identifier;
- model version or snapshot where available;
- deployment type;
- region or data zone;
- lifecycle status;
- observed retirement date;
- observation source and time;
- automatic upgrade policy;
- replacement candidate;
- evidence that the replacement passed product-specific evaluation.

If the provider does not expose an immutable model identity, the record should
say so. A provider model name should not be presented as a verified artifact
digest.

The same release binding applies to other AI components:

| Component | Release identity to capture |
| --- | --- |
| Prompt | Repository revision, prompt ID, content hash, and policy version |
| Retrieval corpus | Source snapshot, access-policy revision, and observation time |
| Vector index | Index build ID, embedding model, chunking configuration, and build time |
| Reranker | Model and configuration version |
| Agent | Definition revision, tool set, authority profile, and approval policy |
| Memory | Store, schema, scope policy, retention policy, and migration version |
| Evaluation | Dataset version, harness revision, thresholds, and result |

The goal is not to copy every configuration value into one file. The goal is to
create stable references that let an operator reconstruct the applicable
composition.

## 7. Four connected records

The G7 baseline places composition, security controls, and performance
indicators in one broad structure. An implementation can preserve those
elements while separating records according to how they change.

### 1. Component graph

This is the durable inventory:

- software packages;
- model artifacts and hosted model references;
- datasets;
- prompt and policy artifacts;
- retrieval components;
- tools and external services;
- infrastructure;
- dependency and derivation relationships.

Update it when composition changes.

### 2. Release manifest

This binds selected components to a build and deployment:

- system and release identifiers;
- environment and region;
- exact component references;
- deployment configuration;
- authority profile;
- promotion and rollback information.

Update it for every promoted release or material configuration change.

### 3. Assurance record

This links claims and assessments:

- model and system cards;
- security reviews;
- evaluation results;
- licences;
- threat models;
- privacy assessments;
- exceptions and accepted risks;
- supplier declarations;
- attestations and signatures.

Update it when evidence changes, expires, or is superseded.

### 4. Runtime binding

This connects consequential outputs and actions to the release manifest:

- request or task identifier;
- deployment and AI BOM version;
- model reference returned by the platform;
- prompt and policy references;
- retrieval source identifiers;
- tool calls and action results;
- relevant human approvals.

Retain it according to consequence, privacy, legal, and incident-response
requirements.

The records can use one underlying graph. Their lifecycle and distribution do
not have to be identical.

## 8. What the record should support

An AI BOM earns its cost by shortening real work.

### Vulnerability response

The PyTorch `torchtriton` incident shows an ordinary software supply-chain
failure inside an AI stack. Between 25 and 30 December 2022, a malicious
package on the public Python Package Index could be installed instead of the
package from PyTorch's nightly index. The malicious binary collected system
information and files, then attempted to upload them through encrypted DNS
queries.\[16\]

An ordinary SBOM should identify the package and version. The AI system graph
adds the affected models, training or inference jobs, deployments, and
credentials exposed through those paths.

The 2025 PyTorch advisory for
`torch.load(weights_only=True)` provides a different example. A model-loading
path believed to reduce risk could still allow remote code execution.\[17\]
The relevant inventory question is not only "Do we use PyTorch?" It is "Which
systems load which model formats through the affected path?"

Hugging Face's work on `safetensors` illustrates how a component property can
change the risk decision. The format was created because pickle-based model
loading can execute code. An external audit found no critical flaw leading to
arbitrary code execution in the reviewed version, while also identifying
specification and validation improvements.\[18\]

The BOM should record the model format, loader, version, digest, and audit
reference. It should not translate one audit into a permanent claim that every
future version or use is safe.

### Model and service migration

Model retirement is a normal operational event. Providers publish schedules,
replacement recommendations, and notice periods because applications must
migrate.\[20\]\[21\]\[22\]\[23\]

The AI BOM should let a team identify:

- every deployment using the retiring model;
- every prompt and evaluation tied to it;
- regional and deployment-type differences;
- fine-tuned derivatives;
- embedding and reranking dependencies;
- replacement test status;
- rollback and fallback options.

A repository search for a model string may miss configuration in managed
platforms, no-code workflows, environment variables, or downstream services.
The deployment graph should be the more reliable query surface.

### Dataset withdrawal and correction

LAION temporarily took down its datasets in December 2023 after a Stanford
Internet Observatory report identified links to suspected illegal material.
LAION stated that the relevant data had to be deleted and that the datasets
would be reviewed before republication.\[24\]\[25\]

The event does not establish that every model trained on LAION data inherited
the reported material or produced harmful output. It shows why dataset
identity, provenance, derivation, and observation time matter.

A downstream organisation should be able to ask:

- Which models declare this dataset in their lineage?
- Which internal fine-tunes derive from those models?
- Which dataset revision or filtered replacement was used?
- Which supplier declaration supports the answer?
- Which risks remain impossible to verify because upstream training data is
  unavailable?

### Incident investigation

An incident team needs to reconstruct the relevant system, not every possible
component the organisation has ever used.

The release manifest and runtime binding should show:

- what was deployed;
- what changed before the incident;
- which requests or actions used the affected release;
- which model and data references were observed;
- which evidence justified promotion;
- which rollback target restores a known composition.

Hugging Face's 2024 Spaces security notice reported unauthorised access related
to stored secrets, token revocation, external forensic support, and changes
intended to improve traceability and audit.\[19\] A BOM would not replace
credential inventory or access logs. It could show which AI applications,
external services, and deployments depended on the affected secret boundary.

### Procurement and supplier review

A supplier may provide a detailed model card but no immutable version, no
dataset provenance, no incident contact, and no way to identify automatic
upgrades. Another supplier may expose strong artifact identity but little
information about intended use.

The AI BOM gives procurement, security, engineering, and legal teams a common
set of gaps to assess. Unknown values should remain visible rather than being
converted into generic risk language.

### Regulation and technical documentation

The EU AI Act requires technical documentation for high-risk AI systems under
Article 11 and Annex IV, including information about system design, third-party
components, data, validation, monitoring, and changes. Article 53 and Annex XI
also require general-purpose AI model documentation and information about
training data provenance within their defined scope.\[14\]

The Cyber Resilience Act defines an SBOM and, for products within scope,
requires a machine-readable record covering at least top-level software
dependencies. Its recitals connect the record to tracking newly emerged
vulnerabilities and also state that manufacturers should not be required to
make the SBOM public.\[15\]

An AI BOM may support those obligations. It does not establish compliance by
itself. Applicability, required detail, retention, disclosure, and conformity
assessment depend on the product and legal role.

## 9. Failure modes

An inventory can become another source of false confidence.

### Generated once at procurement

A supplier questionnaire records the initial model and data description. The
production system later changes prompts, indexes, tools, and model versions.
The document remains accurate only for a system that no longer exists.

Control: define update triggers and measure update lag.

### Accurate components, missing relationships

The record lists a model, three datasets, two indexes, and several services
without showing which release uses which component.

Control: require dependency, derivation, deployment, and replacement
relationships.

### Stable name, changing implementation

A hosted model alias or managed platform deployment remains the same while the
underlying service is upgraded.

Control: record the strongest available provider identity, deployment policy,
observation time, and request-level reference. Mark immutable identity as
unavailable where necessary.

### Supplier claim presented as verification

A model card states that a system is suitable for a use. The BOM copies the
statement into a field labelled "approved".

Control: preserve evidence class, source, assessor, and assessment scope.

### Dynamic evidence copied into a static file

The BOM contains uptime, vulnerability status, evaluation scores, and security
controls without timestamps or expiry.

Control: keep stable identifiers in the BOM and link to versioned, time-bound
evidence.

### Hidden unknowns

Unavailable training data or model versions are omitted to make the record look
complete.

Control: require explicit unknown entries with owner, consequence, and review
date.

### Excessive disclosure

A public BOM reveals internal architecture, model weaknesses, security
controls, data sensitivity, tool permissions, or incident paths.

Control: maintain distribution profiles. A public transparency view, supplier
exchange view, internal operations view, and restricted incident view can share
identifiers without exposing the same detail.

### Inventory without response tooling

The organisation produces machine-readable files but cannot query which
deployments are affected by an advisory.

Control: connect the graph to vulnerability management, deployment inventory,
model lifecycle notices, evaluation systems, and incident workflows. This is
also the boundary stated in the G7 guidance.\[2\]

## 10. A practical operating model

The implementation should begin with decisions, not fields.

### Step 1: Define the questions

Select the questions the record must answer:

- What is deployed?
- What changed?
- What depends on this component?
- Which evidence applies?
- Which systems are affected?
- Can we replace or roll back?
- What is unknown?

Do not collect fields that have no owner or use.

### Step 2: Set the system boundary

Choose one product or workflow. Include:

- application software;
- models;
- data and retrieval;
- prompts and policies;
- tools and services;
- identities and authority profiles;
- infrastructure;
- assurance evidence.

Record excluded areas explicitly.

### Step 3: Start with the ordinary SBOM

Generate the normal software inventory using an established machine-readable
format. Preserve package identifiers, versions, hashes, suppliers, licences,
and relationships.

The AI-specific record should reference this SBOM rather than reproduce it
poorly.

### Step 4: Add AI-specific components

Use SPDX, CycloneDX, or another supported schema for models and datasets where
possible.\[5\]\[6\]\[7\]\[8\]

Use extensions or linked records for components the current schema does not
represent adequately, including prompt artifacts, retrieval indexes, agent
definitions, authority profiles, and memory stores.

Document the extension rather than placing unstructured values into unrelated
fields.

### Step 5: Add relationships

Record how components connect:

- model trained on dataset;
- model fine-tuned from predecessor;
- index built from corpus;
- index embedded with model;
- agent governed by policy;
- agent can invoke tool;
- release deployed as endpoint;
- evaluation assesses release.

Test that dependency queries return expected results.

### Step 6: Classify evidence

For each material field, record:

- evidence class;
- source;
- producer or assessor;
- observation time;
- applicable version;
- freshness or expiry;
- confidence or unknown status.

Avoid a generic "verified" boolean.

### Step 7: Bind every production release

Promotion should produce or update a release manifest. Material configuration
changes should create a new revision even when application code does not
change.

The release process should fail visibly if required component identity is
missing. Exceptions need an owner and expiry.

### Step 8: Sign and distribute

Sign machine-readable records or wrap them in an attestation where the trust
model requires it.\[10\]

Create distribution profiles:

- public;
- customer or supplier exchange;
- internal operations;
- restricted security and incident response.

Do not place secrets, raw personal data, or unrestricted prompts into the BOM.

### Step 9: Connect operational systems

Link the graph to:

- deployment inventory;
- vulnerability advisories;
- model-provider lifecycle notices;
- evaluation results;
- security findings;
- data governance records;
- incident management;
- change and release systems.

The integration should support impact analysis rather than merely storing
files.

### Step 10: Exercise the record

Run a scenario:

1. A model loader receives a critical advisory.
2. A dataset is withdrawn.
3. A hosted model announces retirement.
4. A prompt policy is found to allow an unsafe tool path.

Measure whether the team can identify affected deployments, owners, evidence,
and replacement actions.

The test will expose missing relationships faster than a completeness
percentage.

## 11. What to measure

Metrics should test operational usefulness.

### Deployment binding coverage

Percentage of production AI deployments linked to a current release manifest
and AI BOM version.

### Resolvable component identity

Percentage of material components with an immutable identifier, version, or
explicitly documented provider limitation.

### Relationship coverage

Percentage of critical dependency and derivation paths represented in the
graph.

### Evidence classification

Percentage of material claims labelled by evidence class, source, owner, and
observation time.

### Freshness compliance

Percentage of time-bound entries reviewed or refreshed before their declared
expiry.

### Unknown ageing

Age and consequence of unresolved unknowns. Old low-consequence unknowns and
new high-consequence unknowns should not be averaged into one reassuring
score.

### Impact-analysis time

Time required to identify affected production deployments after a component
advisory, dataset withdrawal, or model retirement.

### Reconstruction coverage

Percentage of sampled consequential outputs or actions that can be linked to
the applicable deployment, model, prompt, retrieval, policy, and tool records.

### Replacement readiness

Percentage of critical external model and service dependencies with a tested
migration or fallback path.

These measures do not prove system safety. They show whether the organisation
can understand and act on its dependency state.

## 12. Counterarguments

### Model and system cards already provide this information

Cards are useful human-readable records. They can explain intended use,
limitations, evaluation, and safety work more effectively than a component
manifest.

They usually do not provide the complete machine-processable dependency graph
for one deployed release. The AI BOM should link to cards rather than replace
them.

### Hosted models make complete inventory impossible

This is often true. A deployer may never receive model weights, training data,
or a stable digest.

The response should be explicit opacity. Record the provider, platform,
contracted model identifier, deployment type, region, lifecycle state,
observation time, and unavailable facts. Supplier opacity is a risk property of
the dependency.

### The system changes too quickly

Prompts, indexes, policies, and models can change frequently. A manually
maintained document will become stale.

That argues for generated manifests, durable identifiers, and event-driven
updates. It also argues for limiting the record to information that supports a
decision. High change rate does not remove the need to know what changed.

### Standards are too immature

The standards are incomplete and terminology varies. G7 calls its elements a
first step. SPDX and CycloneDX model overlapping but different concepts.

Waiting for perfect convergence leaves current systems untraceable. Use
existing standards for the components they represent well, document
extensions, and keep the internal evidence model independent of one exchange
format.

### Automated generation solves the problem

Automation can discover software packages, containers, model files, and some
cloud resources. It may not know intended use, dataset lineage, supplier
limitations, tool authority, or which evaluation approved a release.

Generation needs declared inputs and organisational evidence. The generated
record should expose missing information instead of filling gaps with
inference.

### A detailed BOM creates an attack map

It can. Dataset sensitivity, model weaknesses, service topology, prompts, and
tool permissions may help an attacker.

The Cyber Resilience Act explicitly states that manufacturers should not be
obliged to make an SBOM public.\[15\] Transparency does not require universal
publication. Access should match purpose.

### Compliance programmes will define the required fields

Legal and standards work will continue to shape documentation. Those
requirements may improve consistency.

An organisation still needs operational questions that are specific to its
product, deployment model, incident process, and recovery obligations.
Compliance can set a floor. It cannot identify every dependency that matters to
one system.

## 13. What this paper does not claim

This paper does not claim that an AI BOM proves accuracy, safety, fairness,
security, or legal compliance.

It does not claim that every training record, prompt, runtime trace, or
security control should be public.

It does not claim that one exchange format currently represents every model,
dataset, retrieval, agent, memory, and authority relationship.

It does not claim that hashes establish trust or that signatures establish
truth.

It does not claim that the cited security and dataset events would have been
prevented by an AI BOM.

It does not claim that complete provenance is always available, especially for
hosted and proprietary models.

The claim is narrower:

> A versioned, evidence-aware, deployment-bound AI BOM can reduce the time
> required to understand what an AI system contains, what changed, what is
> affected, and what the organisation needs to do next.

## Conclusion

Software bills of materials became necessary because modern software exceeded
what teams could reliably understand from source repositories and package
names alone.

AI systems add dependencies that ordinary software inventories do not fully
describe. Models, datasets, prompts, indexes, hosted services, tools, memory,
authority, and evaluation evidence can all change product behaviour. Some are
artifacts. Some are declarations. Some are assessments. Some exist only as
runtime observations.

The 2026 G7 guidance gives the field a useful baseline. It recognises the
system, model, data, infrastructure, security, and operational dimensions of
the problem. It also states the right limitation: an AI BOM needs operational
tooling before it can improve supply-chain security.

The next step is to make the record answerable.

Can the organisation identify every affected deployment when a model is
retired? Can it trace a dataset withdrawal into downstream models? Can it
distinguish a supplier's statement from an internal test? Can it reconstruct
the composition behind a consequential output? Can it name what remains
unknown?

If the record cannot answer those questions, adding more fields will not make
it operational.

Treat composition, release state, assurance evidence, and runtime observation
as connected records. Bind them through stable identifiers. Preserve
uncertainty. Restrict sensitive views. Exercise the graph during migrations and
incidents.

The AI Bill of Materials becomes valuable when it shortens the path from a new
fact to a correct operational decision.

## Appendix A: Illustrative CycloneDX JSON

This example is a CycloneDX 1.7 JSON BOM for a fictional AI system. It is
available as a separate
[JSON file](./example-operational-ai-bom.cdx.json) and conforms to the
CycloneDX 1.7 schema.\[7\]\[8\]

It is not a G7 template and does not encode every G7 minimum element. The
example uses native CycloneDX fields where the specification already provides
them. Properties beginning with `example.org:aibom:` are proposed operational
extensions for concepts that do not have equivalent first-class fields in this
example. Those property names are not part of CycloneDX, SPDX, or the G7
guidance.

| Part of the example | Status |
| --- | --- |
| `bomFormat`, `specVersion`, `serialNumber`, `version` | Native CycloneDX |
| `metadata.component` | Native CycloneDX representation of the assembled application |
| `components` with `file`, `machine-learning-model`, `data`, and `library` types | Native CycloneDX |
| `services` | Native CycloneDX representation of hosted APIs and services |
| `dependencies` | Native CycloneDX dependency relationships |
| `externalReferences` | Native CycloneDX links to another BOM, evidence, an attestation, and runtime analysis |
| `properties` | Native CycloneDX extension mechanism |
| Names beginning with `example.org:aibom:` | Proposed fields used by this paper |

The hashes, organisations, endpoints, and evidence URLs are fictional. They
show the data shape rather than making claims about a real system.

```json
{
  "$schema": "http://cyclonedx.org/schema/bom-1.7.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:53c5cf54-d22c-4f0c-b84d-6bd8b04e3196",
  "version": 1,
  "metadata": {
    "timestamp": "2026-09-08T19:00:00Z",
    "component": {
      "type": "application",
      "bom-ref": "urn:example:system:support-assistant:2026.09.08",
      "name": "Example Support Assistant",
      "version": "2026.09.08",
      "externalReferences": [
        {
          "type": "bom",
          "url": "https://example.org/boms/support-assistant-software.cdx.json",
          "comment": "Ordinary software SBOM for this release."
        },
        {
          "type": "evidence",
          "url": "https://example.org/assurance/support-assistant-evaluation-2026.09.08.json",
          "comment": "Evaluation evidence for this release."
        },
        {
          "type": "attestation",
          "url": "https://example.org/attestations/support-assistant-2026.09.08.intoto.jsonl",
          "comment": "Signed release attestation."
        },
        {
          "type": "runtime-analysis-report",
          "url": "https://example.org/restricted/runtime/support-assistant/",
          "comment": "Restricted runtime evidence indexed by deployment and request ID."
        }
      ],
      "properties": [
        {
          "name": "example.org:aibom:release-id",
          "value": "release-2026.09.08"
        },
        {
          "name": "example.org:aibom:deployment-id",
          "value": "support-assistant-prod-west-001"
        },
        {
          "name": "example.org:aibom:environment",
          "value": "production"
        },
        {
          "name": "example.org:aibom:region",
          "value": "example-west"
        },
        {
          "name": "example.org:aibom:promoted-at",
          "value": "2026-09-08T19:00:00Z"
        },
        {
          "name": "example.org:aibom:rollback-target",
          "value": "release-2026.09.01"
        },
        {
          "name": "example.org:aibom:authority-profile",
          "value": "support-case-create-with-approval-v3"
        }
      ]
    }
  },
  "components": [
    {
      "type": "file",
      "bom-ref": "urn:example:prompt:support-system:7",
      "name": "Support Assistant System Prompt",
      "version": "7",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "1111111111111111111111111111111111111111111111111111111111111111"
        }
      ],
      "externalReferences": [
        {
          "type": "configuration",
          "url": "https://example.org/config/prompts/support-system/7"
        }
      ],
      "properties": [
        {
          "name": "example.org:aibom:evidence:hash",
          "value": "verifiable-component-fact"
        },
        {
          "name": "example.org:aibom:observed-at",
          "value": "2026-09-08T19:00:00Z"
        }
      ]
    },
    {
      "type": "file",
      "bom-ref": "urn:example:policy:tool-use:3",
      "name": "Tool Use Policy",
      "version": "3",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "2222222222222222222222222222222222222222222222222222222222222222"
        }
      ],
      "properties": [
        {
          "name": "example.org:aibom:approval-boundary",
          "value": "human-approval-required-before-case-creation"
        }
      ]
    },
    {
      "type": "machine-learning-model",
      "bom-ref": "urn:example:model:embedding:1.2.0",
      "name": "Example Embedding Model",
      "version": "1.2.0",
      "supplier": {
        "name": "Example Model Supplier"
      },
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "3333333333333333333333333333333333333333333333333333333333333333"
        }
      ],
      "externalReferences": [
        {
          "type": "model-card",
          "url": "https://example.org/models/embedding-1.2.0/model-card"
        }
      ],
      "properties": [
        {
          "name": "example.org:aibom:evidence:model-card",
          "value": "supplier-declaration"
        },
        {
          "name": "example.org:aibom:evidence:hash",
          "value": "verifiable-component-fact"
        }
      ]
    },
    {
      "type": "data",
      "bom-ref": "urn:example:data:support-corpus:2026-09-08",
      "name": "Support Knowledge Snapshot",
      "version": "2026-09-08",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "4444444444444444444444444444444444444444444444444444444444444444"
        }
      ],
      "externalReferences": [
        {
          "type": "documentation",
          "url": "https://example.org/data/support-corpus/2026-09-08"
        }
      ],
      "properties": [
        {
          "name": "example.org:aibom:evidence:provenance",
          "value": "organisational-assessment"
        },
        {
          "name": "example.org:aibom:sensitivity",
          "value": "internal"
        },
        {
          "name": "example.org:aibom:fresh-until",
          "value": "2026-09-15T19:00:00Z"
        }
      ]
    },
    {
      "type": "data",
      "bom-ref": "urn:example:data:support-index:build-1842",
      "name": "Support Retrieval Index",
      "version": "build-1842",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "5555555555555555555555555555555555555555555555555555555555555555"
        }
      ],
      "properties": [
        {
          "name": "example.org:aibom:built-at",
          "value": "2026-09-08T18:20:00Z"
        },
        {
          "name": "example.org:aibom:source-component",
          "value": "urn:example:data:support-corpus:2026-09-08"
        },
        {
          "name": "example.org:aibom:embedding-component",
          "value": "urn:example:model:embedding:1.2.0"
        }
      ]
    },
    {
      "type": "library",
      "bom-ref": "urn:example:library:ai-client:2.4.1",
      "name": "Example AI Client Library",
      "version": "2.4.1",
      "supplier": {
        "name": "Example Software Supplier"
      }
    }
  ],
  "services": [
    {
      "bom-ref": "urn:example:service:generation-model:prod",
      "provider": {
        "name": "Example Hosted Model Provider"
      },
      "name": "Hosted Generation Model",
      "version": "model-snapshot-2026-08-15",
      "endpoints": [
        "https://api.example.org/v1/generate"
      ],
      "authenticated": true,
      "properties": [
        {
          "name": "example.org:aibom:evidence:model-reference",
          "value": "deployment-observation"
        },
        {
          "name": "example.org:aibom:observed-at",
          "value": "2026-09-08T19:00:00Z"
        },
        {
          "name": "example.org:aibom:lifecycle-status",
          "value": "active"
        },
        {
          "name": "example.org:aibom:automatic-upgrade-policy",
          "value": "disabled"
        }
      ]
    },
    {
      "bom-ref": "urn:example:service:support-case-api:v2",
      "provider": {
        "name": "Example Service Provider"
      },
      "name": "Support Case API",
      "version": "2",
      "endpoints": [
        "https://support.example.org/api/v2/cases"
      ],
      "authenticated": true,
      "properties": [
        {
          "name": "example.org:aibom:tool-authority",
          "value": "create-case-only"
        },
        {
          "name": "example.org:aibom:approval-policy",
          "value": "urn:example:policy:tool-use:3"
        }
      ]
    }
  ],
  "dependencies": [
    {
      "ref": "urn:example:system:support-assistant:2026.09.08",
      "dependsOn": [
        "urn:example:prompt:support-system:7",
        "urn:example:policy:tool-use:3",
        "urn:example:data:support-index:build-1842",
        "urn:example:library:ai-client:2.4.1",
        "urn:example:service:generation-model:prod",
        "urn:example:service:support-case-api:v2"
      ]
    },
    {
      "ref": "urn:example:data:support-index:build-1842",
      "dependsOn": [
        "urn:example:data:support-corpus:2026-09-08",
        "urn:example:model:embedding:1.2.0"
      ]
    },
    {
      "ref": "urn:example:prompt:support-system:7",
      "dependsOn": []
    },
    {
      "ref": "urn:example:policy:tool-use:3",
      "dependsOn": []
    },
    {
      "ref": "urn:example:model:embedding:1.2.0",
      "dependsOn": []
    },
    {
      "ref": "urn:example:data:support-corpus:2026-09-08",
      "dependsOn": []
    },
    {
      "ref": "urn:example:library:ai-client:2.4.1",
      "dependsOn": []
    },
    {
      "ref": "urn:example:service:generation-model:prod",
      "dependsOn": []
    },
    {
      "ref": "urn:example:service:support-case-api:v2",
      "dependsOn": []
    }
  ]
}
```

## Appendix B: Review checklist

- Is this record bound to one identifiable release and deployment?
- Does it reference the ordinary software SBOM?
- Are models, datasets, prompts, retrieval components, tools, services, and
  infrastructure represented?
- Are dependency and derivation relationships queryable?
- Can an operator distinguish supplier declarations from organisational
  assessments?
- Do hashes and signatures state exactly what they cover?
- Are hosted model identities and automatic upgrade policies recorded?
- Are unavailable versions and provenance represented as explicit unknowns?
- Does each time-bound entry have an observation time and update trigger?
- Are evaluation results bound to the tested composition?
- Can consequential outputs or actions be linked to a release manifest?
- Can the organisation identify affected deployments after an advisory?
- Can it identify downstream models after a dataset withdrawal?
- Is there a tested replacement path for critical hosted dependencies?
- Are sensitive prompts, data, security controls, and authority details
  restricted appropriately?
- Is the record connected to vulnerability, release, evaluation, and incident
  systems?
- Has the graph been exercised through a migration or incident scenario?
- Does every material gap have an owner and review date?

## About the author

Jason Doyle writes about reliable software, observability, incident leadership,
applied AI, and practical controls for systems that influence human and
organisational decisions. He publishes at
[jasondoyle.ie](https://jasondoyle.ie).

## References

1. Cybersecurity and Infrastructure Security Agency, *Software Bill of
   Materials for AI - Minimum Elements*, 2026,
   [https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements](https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements).
2. G7 Cybersecurity Working Group, *Software Bill of Materials for AI - Minimum
   Elements*, 2026,
   [https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_minimum-elements.pdf?__blob=publicationFile&v=4](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_minimum-elements.pdf?__blob=publicationFile&v=4).
3. Cybersecurity and Infrastructure Security Agency, National Security Agency,
   Federal Bureau of Investigation, and international partners, *2026 Minimum
   Elements for a Software Bill of Materials*, July 2026,
   [https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom](https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom).
4. UK National Cyber Security Centre and international partners, *Guidelines
   for Secure AI System Development*, 27 November 2023,
   [https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development](https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development).
5. SPDX, *AIPackage*, SPDX 3 model,
   [https://github.com/spdx/spdx-3-model/blob/main/model/AI/Classes/AIPackage.md](https://github.com/spdx/spdx-3-model/blob/main/model/AI/Classes/AIPackage.md).
6. SPDX, *DatasetPackage*, SPDX 3 model,
   [https://github.com/spdx/spdx-3-model/blob/main/model/Dataset/Classes/DatasetPackage.md](https://github.com/spdx/spdx-3-model/blob/main/model/Dataset/Classes/DatasetPackage.md).
7. OWASP CycloneDX, *Introduction to AI/ML-BOM*,
   [https://cyclonedx.org/capabilities/mlbom/](https://cyclonedx.org/capabilities/mlbom/).
8. OWASP CycloneDX, *CycloneDX Specification*,
   [https://github.com/CycloneDX/specification](https://github.com/CycloneDX/specification).
9. Margaret Mitchell et al., *Model Cards for Model Reporting*, FAT* 2019,
   [https://doi.org/10.1145/3287560.3287596](https://doi.org/10.1145/3287560.3287596).
10. Supply-chain Levels for Software Artifacts, *Terminology*, SLSA v1.0,
    [https://slsa.dev/spec/v1.0/terminology](https://slsa.dev/spec/v1.0/terminology).
11. National Institute of Standards and Technology, *Artificial Intelligence
    Risk Management Framework (AI RMF 1.0)*, NIST AI 100-1, 26 January 2023,
    [https://doi.org/10.6028/NIST.AI.100-1](https://doi.org/10.6028/NIST.AI.100-1).
12. National Institute of Standards and Technology, *Artificial Intelligence
    Risk Management Framework: Generative Artificial Intelligence Profile*,
    NIST AI 600-1, 26 July 2024,
    [https://doi.org/10.6028/NIST.AI.600-1](https://doi.org/10.6028/NIST.AI.600-1).
13. National Institute of Standards and Technology, *Secure Software
    Development Practices for Generative AI and Dual-Use Foundation Models*,
    NIST SP 800-218A, 26 July 2024,
    [https://doi.org/10.6028/NIST.SP.800-218A](https://doi.org/10.6028/NIST.SP.800-218A).
14. European Union, *Regulation (EU) 2024/1689 laying down harmonised rules on
    artificial intelligence*, 13 June 2024,
    [https://eur-lex.europa.eu/eli/reg/2024/1689/oj](https://eur-lex.europa.eu/eli/reg/2024/1689/oj).
15. European Union, *Regulation (EU) 2024/2847 on horizontal cybersecurity
    requirements for products with digital elements*, 23 October 2024,
    [https://eur-lex.europa.eu/eli/reg/2024/2847/oj](https://eur-lex.europa.eu/eli/reg/2024/2847/oj).
16. PyTorch, *Compromised PyTorch-nightly dependency chain between December
    25th and December 30th, 2022*, 30 December 2022,
    [https://pytorch.org/blog/compromised-nightly-dependency/](https://pytorch.org/blog/compromised-nightly-dependency/).
17. PyTorch, *torch.load with weights_only=True leads to remote code execution*,
    GHSA-53q9-r3pm-6pq6, 2025,
    [https://github.com/pytorch/pytorch/security/advisories/GHSA-53q9-r3pm-6pq6](https://github.com/pytorch/pytorch/security/advisories/GHSA-53q9-r3pm-6pq6).
18. Hugging Face, *Safetensors audited as really safe and becoming the default*,
    2023,
    [https://huggingface.co/blog/safetensors-security-audit](https://huggingface.co/blog/safetensors-security-audit).
19. Hugging Face, *Space secrets leak disclosure*, 31 May 2024,
    [https://huggingface.co/blog/space-secrets-disclosure](https://huggingface.co/blog/space-secrets-disclosure).
20. Microsoft, *Foundry Models lifecycle and support policy*, Microsoft Learn,
    updated 24 July 2026,
    [https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-retirements](https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-retirements).
21. Anthropic, *Model deprecations*, accessed 8 September 2026,
    [https://platform.claude.com/docs/en/about-claude/model-deprecations](https://platform.claude.com/docs/en/about-claude/model-deprecations).
22. OpenAI, *Deprecations*, accessed 8 September 2026,
    [https://developers.openai.com/api/docs/deprecations](https://developers.openai.com/api/docs/deprecations).
23. Google Cloud, *Model versions and lifecycle*, accessed 8 September 2026,
    [https://cloud.google.com/vertex-ai/generative-ai/docs/learn/model-versioning](https://cloud.google.com/vertex-ai/generative-ai/docs/learn/model-versioning).
24. LAION, *LAION Maintenance*, 19 December 2023,
    [https://laion.ai/notes/laion-maintenance/](https://laion.ai/notes/laion-maintenance/).
25. David Thiel, *Identifying and Eliminating CSAM in Generative ML Training
    Data and Models*, Stanford Internet Observatory, 20 December 2023,
    [https://purl.stanford.edu/kh752sm9123](https://purl.stanford.edu/kh752sm9123).