AI bill of materials: the emerging standard for knowing what's inside your AI stack

If you have not heard the term AI Bill of Materials yet, you will soon. It is moving quickly from a niche security concept to something enterprise procurement teams actively ask for, and it is being pulled into that position by real regulation, not just industry enthusiasm. This article explains what it is, why it exists, what a good one actually contains, and what an AI startup should do about it now, while it is still early enough to be a genuine advantage rather than a scramble.

The idea it builds on

To understand an AI Bill of Materials, it helps to start with its older relative, the Software Bill of Materials, or SBOM. An SBOM is simply an inventory of every component inside a piece of software, the libraries, packages, and versions it depends on. It became standard practice after a US government cybersecurity order made it a procurement requirement, and it earns its keep in moments like a serious vulnerability being discovered in a widely used library. If you have an accurate SBOM, you can answer are we affected in minutes. Without one, you are searching blind.

An AI Bill of Materials, often shortened to AIBOM, extends the same idea to AI systems. The reason it needs to be its own thing, rather than just an extended SBOM, is that an AI system's behaviour depends on far more than its code. It depends on the model itself, the data it was trained or fine tuned on, and the configuration it runs with, none of which a traditional software inventory captures at all.

What actually goes into one

The industry is converging on a fairly consistent picture of what a proper AIBOM covers, drawing on work from OWASP, the standards bodies CycloneDX and SPDX, and frameworks like NIST's AI Risk Management Framework. In practice, a defensible AIBOM covers six broad areas.

• Models. Which models you use, their version, architecture, and provenance, including whether they came from a third party provider or were fine tuned in house.
• Datasets. What data trained or fine tuned each model, where it came from, and considerations like licensing and known bias.
• Code. The same software component tracking a traditional SBOM covers, since your AI system still runs on ordinary code and dependencies too.
• Hardware. Where relevant, the infrastructure the system runs on.
• Data processing pipelines. How data moves through your system, including preprocessing and the services it passes through.
• Governance. Evidence of oversight, evaluation, and accountability around the system, tying the technical inventory to the management processes around it.

Two technical formats have matured enough to actually be used in contracts. CycloneDX, an OWASP backed standard, extended its specification to cover machine learning components and is generally the practical choice for automated generation inside a development pipeline. SPDX, the other major standard, added an AI profile with roots in a recognised international standard, which gives it more weight in regulatory and procurement contexts. Most teams will encounter one or both, and open source tooling exists to help generate them, including a free generator from the OWASP AI security project for models hosted on Hugging Face.

Why this is happening now, and why it is not just theory

Three things converged to turn AIBOM from a nice idea into something buyers are starting to require in contracts, and it is worth understanding all three because together they explain why this is moving fast.

The EU AI Act includes a technical documentation requirement for high risk AI systems, and the fields it asks for map closely onto what an AIBOM contains. That obligation applies from 2 August 2026, though a proposed set of amendments may push part of it later. Separately, the CycloneDX and SPDX formats reached a stable, mature enough state in 2025 and 2026 that procurement teams can actually specify them in a contract, which removes the chicken and egg problem that existed a couple of years earlier when there was interest but no standard to point to. And a cluster of frameworks, including NIST's AI Risk Management Framework and the ISO 42001 AI management standard, have converged on requiring the same kind of inventory and supplier governance that an AIBOM directly supports.

The practical result is that some enterprise buyers are now writing AIBOM delivery directly into their procurement requirements, specifying the format, requiring delivery at the start of a contract and again whenever something material changes, and reserving the right to see an updated one later. Buyers who have added this language are starting to receive AIBOMs from their vendors by default. Buyers who have not are simply not getting one, because it does not happen automatically.

Do you actually need one yet

Here is the honest, practical answer for a startup. If any part of your product would be classified as high risk under the EU AI Act, an AIBOM, in substance if not yet in a specific mandated format, is becoming a genuine conformity requirement, and your buyers are entitled to receive that documentation from you as the provider. If nothing you build sits in a high risk category, you are not yet legally required to produce one, and the honest driver is procurement discretion rather than obligation. Some buyers will simply start asking for it because it has become common practice, well before it is legally mandatory for them to require it.

Either way, the direction of travel is clear. This is not a passing trend. It is being reinforced from multiple directions at once, regulation, standards maturity, and buyer expectation, and that combination rarely reverses.

What to actually do about it now

The advice that keeps recurring from people already working with this is to start small and concrete rather than trying to build a full governance programme on day one. A sensible first step for a startup looks like this.

• Pick your single highest risk or most commercially important AI system, not your whole stack, and build one proper inventory for it.
• List the model or models it uses, including version and provider, the data involved, and the key components in its pipeline.
• Use an existing open source generator where you can, particularly if you are working with models hosted on common platforms, rather than building this by hand from scratch.
• Keep it updated when something material changes, since a stale inventory undermines the entire point of having one.
• Be ready to produce it, or a clear summary of it, when a buyer's procurement or security team asks, because increasingly they will ask before they will tell you it was expected.

Full automation of this process is not quite here yet. Provider documentation still has to be combined with your own use case information, which takes some manual effort. But starting with one concrete system beats waiting for a perfect, fully automated process that does not exist yet.

Why this is worth being early on

Being ready with a clear AI Bill of Materials before a buyer asks is a genuine differentiator right now, precisely because so few AI companies have one. It signals a level of operational maturity that goes beyond a security policy or a certification, because it shows you actually know, in specific and current detail, what is inside your own AI system. For a buyer trying to assess supply chain risk, that is a meaningfully more concrete answer than most vendors can currently give.

The honest takeaway

An AI Bill of Materials is becoming the accepted way to answer a question enterprise buyers are increasingly going to ask, which is simply what is actually inside your AI system. It is being pulled forward by real regulation and maturing standards, not just enthusiasm, and the startups that build one now, even a small one for their most important system, will find themselves answering a question with confidence that most of their competitors cannot yet answer at all.