Ask a security or IT team to list every model, agent, and prompt running in their environment right now, and most can't. A data scientist fine-tuned something on a Tuesday, a product team wired an MCP server into a customer workflow last quarter, and marketing pays for three AI tools nobody logged. That undocumented sprawl is where AI security risk lives.
AI-BOM programs are primarily held by security and governance teams, though IT, data science, and compliance each hold parts of the record. This article approaches AI-BOMs from that governance vantage point; teams applying the same patterns to internal-use AI in HR, finance, or RevOps will find the structure transferable, but the control points security-led.
Most organizations try to extend the software bill of materials (SBOM), while asset spreadsheets and cloud access security broker (CASB) dashboards fill the gaps. None of it holds. Spreadsheets go stale the week a data scientist fine-tunes an approved model on internal data, and network controls can't see the browser-based AI tool an employee reached through a personal account. When AI runs within an intelligent workflow platform, workflow definitions and run history can serve as inventory evidence, with approvals attached to the same record.
AI-BOMs extend SBOM practice with records for models, datasets, weights, prompts, agents, and runtime evidence, and governed workflows help keep those records current.
What is an AI bill of materials?
An AI bill of materials (AI-BOM) is a structured, machine-readable inventory of the components that shape an AI system. It answers what is in this AI and what shaped its behavior, usually across five groups: models and datasets, serving dependencies, connected agents and tools, prompts, and provenance.
CISA frames the concept as an ingredients list for AI systems. Standards bodies describe the artifact, sometimes called an ML-BOM, as an inventory of every component, configuration, and process involved in developing, training, deploying, and hosting a model, for transparency, traceability, security, and compliance across its lifecycle.
Practitioners describe the failure mode this way: someone hands an approved model to a business unit, the unit fine-tunes it on internal datasets, and the unit deploys it with no record of who built it, how, or where it runs. The security team sanctioned the base model. The business unit created a shadow AI derivative. The discovery problem is broad: AI can surface across enterprise software estates, including outside centrally approved applications.
How an AI-BOM differs from a traditional SBOM
An SBOM inventories software components: the same code and packages produce the same results every run. An AI-BOM inventories components whose behavior changes with data and model configuration. The two artifacts stack. CISA and G7 partners state that teams should consider AI-specific minimum elements in addition to the general minimum elements for an SBOM.
An SBOM can tell you a system uses a particular machine learning library. An AI-BOM records what training data shaped the model behind it and whether someone fine-tuned it on data the organization never approved. Model weights carry their own attack surface: many models ship in pickle serialization formats that execute code on load, and researchers have documented malicious model files on public model hubs, including one that connected to an external IP on load and gave attackers interactive shell access to the workstation.
Lifecycle differs too. An SBOM is a build-time snapshot, whereas AI systems retrain, fine-tune, and drift continuously, so the inventory must track AI lifecycle artifacts over time. And a whole category has no SBOM equivalent at all: AI agents that load tools dynamically at runtime, Model Context Protocol (MCP) server connections, and prompt templates that shape model behavior the way framework versions shape software.
What goes inside an AI-BOM: models, data, dependencies, and lineage
Six component families carry the governance weight. Model entries, including weights, and dataset records determine behavior, so they earn the most detailed entries; the software layer at the bottom is the part existing tooling already handles.
Models and lineage: name, version, architecture, license, provenance, and base-model ancestry. CycloneDX records ancestry in a pedigree object with an ancestors array, so a fine-tuned model traces back to its base checkpoint.
Datasets: training and fine-tuning data sources, collection methods, licenses, preprocessing steps, and known biases. Track fine-tuning data and adapter weights with their own lineage entries.
Model weights: checksums and weight provenance, verifiable against your registry before any artifact reaches staging.
Agentic components: agents, orchestration chains, inference API connections, and MCP servers. For each server, record its declared capabilities and the tool connections or resource references it exposes.
Prompts and governance fields: versioned prompt templates, approval history, evaluation results, and change logs.
Software dependencies: frameworks, libraries, container images, and GPU drivers, the layer a traditional SBOM already handles.
CycloneDX v1.7 and SPDX 3.0 lack a dedicated formal component type for agents or prompts. Both appear in practitioner guides and in SPDX's stated areas of interest, and CycloneDX supports them today through its properties and externalReferences extension mechanisms.
Why teams need an AI-BOM now
Shadow AI and agent growth are outpacing every inventory method currently in place. The gap shows up during an incident, when the question is which systems call the affected model and the only answer available is a spreadsheet nobody has touched since last quarter.
Shadow AI now shows up directly in incident data, with recent industry research linking unsanctioned AI to a substantial share of confirmed AI security incidents. A Cloud Security Alliance whitepaper reports that only 37% of organizations have policies to manage AI or detect shadow AI, and only 34% of that group conduct regular audits for unauthorized AI use.
Without proper AI access controls and AI governance policies, the inventory gap continues to widen. A Forrester Consulting study commissioned by Tines found that 73% of IT and security decision-makers need end-to-end visibility into AI initiatives.
Agent growth compounds the exposure. Each new agent carries its own model calls, tool connections, and credentials, and a meaningful share of that growth lands outside centralized visibility as unsanctioned tools. Agent entries also have to account for tools/APIs, governing prompts, and underlying models that never appear in a software dependency list.
The same visibility problem shows up in security operations, where consolidating playbooks onto an intelligent workflow platform directly shrinks the AI inventory surface and leaves fewer places an AI action can execute without a workflow-level entry.
AI supply chain attacks have already reached real systems. The 2022 torchtriton dependency-confusion attack poisoned PyTorch's nightly build chain and exfiltrated files over encrypted DNS queries. The ShadowRay campaign later exploited a disputed Ray framework vulnerability to access GPU infrastructure, the models and the cloud credentials behind it, marking the first widely reported instance of AI workloads exploited in the wild.
How to build an AI-BOM that doesn't go stale
Quarterly AI-BOM reviews go stale before the meeting ends; accurate programs generate the record from the pipeline. The steps below sequence the work from initial discovery through ongoing enforcement.
Step 1: Scope the inventory. Decide what counts as an AI system for the purposes of the record: hosted foundation models, fine-tuned derivatives, retrieval pipelines, agents with tool access, and third-party AI features embedded in SaaS. Write the scope down before discovery starts, because it determines which signals matter in the next step.
Step 2: Run layered discovery. Treat discovery as layered rather than a single scan. Start with sanctioned-system logs (model registries, inference endpoints, notebook environments), then add network egress data to capture browser-based tools and unmanaged API calls, and finally correlate with identity signals to connect activity to accounts. Each layer catches what the previous layer misses.
Step 3: Generate the initial record. Use an AI-BOM generator, not a spreadsheet, to produce a structured entry for each in-scope system. OWASP's AIBOM Generator creates CycloneDX 1.6 inventories from Hugging Face models, with completeness scoring; the CycloneDX Tool Center lists AI-specific generators that complement dependency scanners such as Syft and Trivy. Populate all six component families: models and lineage, datasets, weights, agentic components, prompts, and software dependencies.
Step 4: Consolidate where AI executes. Discovery shrinks as more AI runs on governed surfaces. On the Tines platform, the Story definition can record which model, prompt, tools, approvals, and output fields an AI-touching workflow uses before it runs, while run history captures what happened after execution. Moving each workflow onto a governed surface removes one place where an AI component can appear without a record.
Step 5: Wire the inventory into CI/CD. Turn the record into an enforcement gate, not a report. Use hash-based verification for model artifacts before staging, block model files that lack a corresponding entry, and compare the runtime inventory against the approved baseline on every deployment. Discrepancies open a case automatically.
Step 6: Assign owners and a review cadence. Assign explicit owners for pipeline operation, lineage, and oversight, with a human review cadence as the floor and automation covering the weeks in between. How much of that pipeline a team builds depends on where the AI runs; the more that runs on a governed workflow surface, the less bespoke tooling the pipeline needs.
Why the architecture of where AI runs decides whether the record stays true
An AI-BOM stays current when workflow definitions, approvals, and run history double as inventory evidence. When AI runs on a governed surface, teams can query the record for the model version of a workflow that ran six weeks ago, which is exactly what the EU AI Act's event-logging obligation expects.
A governed workflow definition captures both the control points before execution (model, prompt, allowed tools, required outputs, approvers) and the evidence after execution (inputs, outputs, and decisions per run). Investigations and approvals are integrated into the workflow, so the record of what the AI did and who approved it lives in one place.
Static records still miss runtime behavior, so discovery sweeps and runtime monitoring stay in place for anything outside the governed surface, and teams constrain what AI can do before it runs- the principle behind designing AI workflows safely.
Every AI governance control, access policy, risk tiering, incident response and regulatory evidence assumes an accurate inventory underneath it. Standards define the format, and discovery closes coverage gaps, but the architecture of where AI runs determines whether the record remains true.
A Forrester Consulting study commissioned by Tines found that 88% of IT and security decision-makers say AI stays fragmented without orchestration, and fragmentation is what makes the EU AI Act's August documentation and logging obligations expensive: teams must reassemble evidence from every place AI ran.
Turning AI visibility into an ongoing practice
An accurate AI-BOM isn't a one-time deliverable. It's the byproduct of running AI on a surface that records itself. Standards give teams the format, discovery closes coverage gaps, and CI/CD enforcement keeps the record honest, but inventory durability comes down to where AI actually executes.
Start smaller than a standards program. Move one AI-touching process into a governed workflow, and see how much of the inventory the workflow definition already records. Tines 3B is an AI-native environment for every team's most important agents, apps, and automations.
It's a single place to see and orchestrate everything running across systems, giving security and governance teams a live inventory instead of a stale spreadsheet. Each workflow step runs in an isolated sandbox, credentials are hidden from builders and the AI model, and one dashboard tracks every app, agent, and automation across the company.
Because every step is defined in code and every run is captured, the platform naturally records the models, prompts, tools, and approvals an AI-touching workflow uses, which are the same fields an AI-BOM needs.
Frequently asked questions
What's the difference between an AI-BOM, an ML-BOM, and an AI SBOM?
Mostly naming. AI-BOM, AIBOM, AI SBOM, and ML-BOM all refer to substantially the same artifact with minor scope differences depending on the vendor or standards body. CycloneDX refers to its implementation as an ML-BOM, while CISA and G7 partners use "SBOM for AI" in their joint minimum-elements guidance.
How does the EU AI Act affect AI-BOM practices?
The Act's technical documentation obligation (Article 11) and event-logging obligation (Article 12) apply to high-risk AI systems from August 2, 2026. Neither article names an AI-BOM specifically, but the required content, including model identification, training-data records, and runtime logs, maps closely to AI-BOM fields. Providers that keep a current AI-BOM tied to workflow run history reduce the effort required to assemble technical files and event logs when regulators or downstream deployers request them.
Which regulatory obligations does an AI-BOM help satisfy?
Several jurisdictions have binding documentation obligations that an AI-BOM can help satisfy, though no major regulation currently mandates a specific AI-BOM format by name. The EU AI Act requires technical documentation and automatic event logging for high-risk AI systems from August 2, 2026, and US federal agencies must inventory their AI use cases at least annually under OMB guidance. An AI-BOM is the practical evidence base for meeting those requirements.
How does a model card relate to an AI-BOM?
A model card is human-readable documentation for a single model: intended uses, limitations, training parameters, and performance metrics. An AI-BOM is a machine-readable, system-level inventory covering the full dependency graph, including datasets, pipelines, agents, and runtime artifacts, and it can reference model cards as components. CycloneDX defines a model card as an external reference type for this purpose.