Table of contents
- Key Takeaways
- What is AI-BOM?
- Why AI-BOMs Have Become Essential for Security
- Core Components of an AI Bill of Materials
- How to Build an Effective AI-BOM
- AI-BOM Standards and the CycloneDX Framework
- AI-BOM vs. SBOM: Understanding the Differences
- Challenges in Implementing AI-BOMs
- How Orca Builds an AI Inventory and Bill of Materials
- Frequently Asked Questions About AI-BOMs
Key Takeaways
- An AI-BOM, or AI bill of materials, inventories the models, datasets, prompts, embeddings, and external AI services an AI system depends on.
- The term is ambiguous. In electronics manufacturing, an AI server BOM lists physical hardware. This article covers the security artifact.
- The format question is close to settled. CycloneDX and SPDX both carry AI components today, and no regulator has blessed either one.
- Discovery is the hard half. Software components arrive through a dependency manifest. Models, datasets, and inference endpoints arrive through a notebook or a console.
- Orca produces a complete AI inventory and bill of materials for every AI model deployed in the cloud, including shadow AI, using agentless SideScanning™.
An AI-BOM, or AI bill of materials, records the models, datasets, prompts, embeddings, and external AI services an AI system depends on. As organizations deploy more AI, maintaining that inventory has become as important as maintaining an SBOM for traditional software.
The term collides with a much older one. In electronics manufacturing, an AI BOM is a parts list for an AI server: accelerators, memory, power delivery, and cooling.
Software inventory is a mature practice. The formats are settled, the tooling works, and regulators have started asking for the output. Very little of that maturity has reached AI systems. Which model version serves production traffic, which corpus produced the vectors in the retrieval store, who owns the fine-tuned checkpoint in a staging account: those answers usually come from memory.
What is AI-BOM?
An AI-BOM is a machine-readable inventory of every component an AI system depends on, recorded with enough detail to identify each one later. Written variously as AI-BOM, AI BOM, or AIBOM, the AI bill of materials applies the discipline of a software bill of materials (SBOM) to models, datasets, prompts, embeddings, and third-party inference services.
Ask what is AI BOM in electronics manufacturing and the answer describes something else entirely. An AI server BOM is a parts list for the physical machine, covering GPUs, memory modules, power supplies, and cooling. Everything below concerns the security artifact, which records the models, data, and services behind an AI system instead of the hardware underneath it.
Why AI-BOMs Have Become Essential for Security
The objection to an AI-BOM is fair: an AI system is software, SBOM tooling already exists, and the format work really is an extension of it. Discovery is where the comparison breaks. A software component arrives through a dependency manifest that software composition analysis can read, and every install leaves a record in a lockfile. A model arrives through a notebook, a managed service console, a fine-tuning job, or a corporate card.
That asymmetry shows up under pressure. When a model provider discloses a flaw, or a public dataset turns out to carry poisoned records, the first question is which systems used it and the second is which version. Vendors now ship generative AI BOM software to close the gap, but tooling can only inventory the components it finds. An accurate inventory is what makes AI security fundamentals enforceable, and it bounds LLM security risks to the systems actually running the affected model.
Core Components of an AI Bill of Materials
Four classes of components separate an AI bill of materials from the software inventory it grew out of. Each has a version, a source, and an owner. Each can also change with no application code change at all, and that is what makes them hard to track.
Models and Model Versions
A model entry records the artifact loaded at inference time: the name, the version or checkpoint, a hash of the weights, the license, and where the artifact came from. Fine-tuned models need one field more. A fine-tune inherits the license and the known weaknesses of its base model, so the entry has to name that base model and the job that produced the derivative. A checkpoint copied out of a public model hub into a private repository loses that chain the moment nobody writes it down.
Datasets and Data Provenance
Dataset entries cover training, fine-tuning, evaluation, and retrieval corpora. Provenance is the field carrying the weight: where the data came from, who collected it, under which license or consent, and what it was permitted to be used for. A training set assembled from three internal exports and one scraped corpus carries four provenance records, one per source.
No gen AI BOM software can reconstruct that history after the fact, so the record has to be written when the data is assembled. Dataset entries also need a sensitivity marker, because sensitive data inside AI systems changes both the risk and the obligations attached to the model.
Prompts, Embeddings, and Retrieval Sources
Retrieval-augmented systems carry components that have no equivalent in a software inventory. The system prompt is one. It shapes model behavior, it changes between releases, and it is rarely versioned anywhere a security team can see.
Embeddings are the other. An embedding index needs to record which model produced the vectors, which corpus was indexed, when, and with what chunking configuration. Without those fields, nobody can answer whether a vector store still holds representations of documents deleted from the source system months ago.
External AI Services and Dependencies
Most AI systems call a model they do not host, so managed endpoints on Amazon Bedrock, Azure OpenAI, and Google Vertex AI belong in the inventory as services. Each entry needs the model identifier, the version or alias in use, the region, the credential, and the direction of data flow. The AI frameworks underneath them still belong there too, since PyTorch, TensorFlow, and scikit-learn carry ordinary software vulnerabilities.
How to Build an Effective AI-BOM
Building an AI-BOM involves three jobs performed in sequence: find the components, record a consistent set of fields for each one, and keep the record current as the estate changes. The order matters, because the second and third jobs are wasted effort on an incomplete list.
Discovery First
Discovery cannot start from a registry that teams volunteer to. Voluntary registration finds the models a team already knows about and misses the ones that matter. Enumeration from the cloud control plane works better, since the provider APIs behind Amazon Bedrock, Amazon SageMaker, Azure OpenAI, and Google Vertex AI list the endpoints and jobs running in every account. Billing data then catches the accounts nobody onboarded.
Package manifests and container images reveal the AI libraries inside workloads, and code repository scanning finds API keys pointing at services no inventory lists. This is the problem shadow AI describes, approached from the asset side, and it is the discovery layer AI security posture management tools are built around.
What to Record for Each Component
A useful component record answers five questions: what it is, which version, where it came from, who owns it, and what data it touches. Identifiers should be stable, so hashes beat display names for model artifacts, and dataset entries need a location plus a snapshot date. Ownership is the easiest field to leave blank, and an inventory without an owner per component generates findings nobody accepts. AI BOM software can emit all of this once the discovery step supplies the component list, and the output belongs in a standard format other tools can read.
Keeping It Current
An AI-BOM built once is a document, and a document goes stale inside a sprint. Regeneration works best when events trigger it: a deployment, a fine-tuning job, a new dataset version, or a change to a managed endpoint’s model alias. A periodic full sweep still earns its place for components that arrive without an event anyone instrumented. Governance programs assume this record already exists, the NIST AI Risk Management Framework among them.
AI-BOM Standards and the CycloneDX Framework
Two formats can express an AI bill of materials today, and neither has been designated the standard for it. The fields CycloneDX and SPDX ask for look similar, so producing the data is harder than picking the schema.
CycloneDX
CycloneDX is an OWASP project and an Ecma International standard. Machine learning support arrived in version 1.5, released in June 2023, which introduced the machine learning bill of materials (ML-BOM) for representing models, datasets, and their configuration.
The specification has moved since: version 1.7 shipped in October 2025 and is the version standardized in the second edition of ECMA-424, published in December 2025. A CycloneDX AI BOM is an ML-BOM emitted in the same document model as an SBOM, so one inventory can cover software and models together.
SPDX
SPDX is the Linux Foundation’s format, and its 2.2.1 release is published as the international standard ISO/IEC 5962:2021. SPDX 3.0, released in April 2024, restructured the specification around profiles, and two of them apply here. The AI profile covers AI system and model artifacts, and the Dataset profile covers a dataset’s preparation process, characteristics, and access methods.
Version 3.0 is still moving through ISO as a draft revision, so the current specification and the published ISO standard are not the same document. Teams already emitting SPDX can extend it to AI components without adopting a second format, which makes the practical question which format the rest of the toolchain already produces.
What Regulators Are Starting to Ask For
Regulation has begun asking for the same information. Under the EU AI Act, providers of high-risk AI systems must keep technical documentation, and Annex IV sets out what that documentation contains.
The list includes the training methodologies and training data sets used, with information about their provenance and how the data was obtained and selected. It also covers any recourse to pre-trained systems or tools provided by third parties, and the versions of relevant software. That is an AI bill of materials described in prose.
The timing has moved more than once, so dates are worth checking against the source. Following the AI omnibus agreement, the European Commission gives two dates for high-risk systems. Rules for high-risk systems in areas such as biometrics, critical infrastructure, employment, and border control apply from 2 December 2027. Rules for high-risk systems embedded in regulated products apply from 2 August 2028.
AI-BOM vs. SBOM: Understanding the Differences
A software bill of materials lists the software components in a build, the ground software supply chain security has covered for years. An AI-BOM keeps that list and adds four things a package inventory has no field for: model weights and their lineage, datasets and their provenance, prompts and embeddings, and external inference services. Each addition brings in a component that can change without a build, which breaks the assumption every SBOM workflow rests on.
Version means something different in each artifact. In an SBOM, a version identifies a package release that a lockfile pins and a build reproduces. In an AI-BOM, a version may be a checkpoint hash, a dataset snapshot date, or a provider alias that resolves to a different model next week.
| Inventory Question | SBOM | AI-BOM |
|---|---|---|
| Lists software packages and their versions | Yes | Yes |
| Records training and fine-tuning datasets with provenance | No | Yes |
| Records model weights, checkpoints, and fine-tune lineage | No | Yes |
| Records prompts, embeddings, and retrieval sources | No | Yes |
| Records external inference services the system calls | Partial | Yes |
| Can be built from a dependency manifest alone | Yes | Partial |
| Component version can change with no code change | No | Yes |
Challenges in Implementing AI-BOMs
The format is the easy half. Every difficulty below is a discovery or currency problem, and picking a schema solves none of them.
Model lineage is often unrecoverable
A fine-tuned checkpoint in a storage bucket carries no reliable record of the base model it started from or the license attached to that base. Reconstructing lineage afterwards is guesswork, so the fix is procedural: record it at fine-tuning time, or write down that the gap exists.
Datasets are assembled, not installed
Nobody runs a package manager to build a training set. Data arrives from internal exports, partner feeds, public corpora, and scraped pages, each with its own license and consent story. There is no manifest to read, so the pipeline that assembles the data has to capture provenance as it goes.
Embeddings outlive the documents they came from
Deleting a document from a source system does not remove the vectors derived from it. A retrieval store can keep returning content from records removed for legal reasons months earlier. An inventory listing the store but not its source corpus and index date will never surface that.
Third-party model versions change underneath you
A managed endpoint set to track a provider default can serve a different model version with no deployment on the customer side. Azure OpenAI’s auto-update to default setting does exactly that, moving a deployment within two weeks of a change to the default version. Pinning a specific version makes the inventory entry meaningful and hands the upgrade work back to the team, a trade-off worth naming out loud.
The people assembling AI systems sit outside the SBOM process
Data scientists work in notebooks and managed consoles, well away from the CI pipelines where SBOM generation was wired in years ago. An AI-BOM program waiting for those teams to adopt build-time tooling will cover the systems that already had governance and miss the rest. Placing enumeration with a team that can query the whole estate removes that dependency, which matters most under the documentation duties that come with AI security in regulated industries.
How Orca Builds an AI Inventory and Bill of Materials
Discovery is the half of this problem that fails silently, and it is a collection problem first. Orca scans the cloud estate with patented, agentless SideScanning™ technology, so AI assets appear in the inventory because they exist in an account, not because someone registered them. The platform produces a complete AI inventory and Bill of Materials (BOM) for every AI model deployed in the cloud, including shadow AI.
Coverage extends across Azure OpenAI, Amazon Bedrock, Amazon SageMaker, and Google Vertex AI, as well as more than 50 commonly used AI software packages, including PyTorch, TensorFlow, OpenAI, Hugging Face, and scikit-learn. Each finding appears alongside the sensitive data it can reach, the identities that can call it, and any exposed access keys in code repositories.
A generated inventory is where the work starts. Someone still has to own each component, decide which datasets carry consent obligations, and keep the provenance records no scanner can reconstruct. What agentless collection removes is the failure that never announces itself: the model running in an account no tool was pointed at. Get a demo to see the AI inventory Orca builds from a live environment.
Frequently Asked Questions About AI-BOMs
No single product category owns AI-BOM capabilities yet. Cloud security platforms, SBOM and software composition analysis tools, machine learning platforms, model registries, and open source generators all support parts of the workflow. Open source options include the OWASP AIBOM Generator, which emits a CycloneDX AI BOM from a model published on a public hub. The biggest difference between tools is how they discover components: those that rely only on registries can inventory only what has already been registered.
ML-BOM is CycloneDX’s term for documenting machine learning models and datasets. AI-BOM is the broader concept of inventorying everything an AI system depends on, including models, datasets, prompts, retrieval sources, and external AI services. Because the term is still evolving, organizations should define the fields they expect an AI-BOM to contain.
Ownership is typically shared. Platform or ML engineering teams maintain the inventory, security uses it for risk management, and governance or compliance teams rely on it for audits. Assigning all three responsibilities to security usually leaves the inventory incomplete.
No. A model card documents an individual model, while an AI-BOM inventories every model, dataset, prompt, and service an AI system depends on. Most organizations benefit from maintaining both and linking AI-BOM entries to their corresponding model cards.
Table of contents
- Key Takeaways
- What is AI-BOM?
- Why AI-BOMs Have Become Essential for Security
- Core Components of an AI Bill of Materials
- How to Build an Effective AI-BOM
- AI-BOM Standards and the CycloneDX Framework
- AI-BOM vs. SBOM: Understanding the Differences
- Challenges in Implementing AI-BOMs
- How Orca Builds an AI Inventory and Bill of Materials
- Frequently Asked Questions About AI-BOMs