AI supply chain and AI bill of materials (AIBOM)

What is the AI supply chain and an AIBOM?

The AI supply chain is everything that had to exist before your AI feature could answer its first question, and you made almost none of it. An AI bill of materials, shortened to AIBOM, is the list of those parts: which models, which datasets, which libraries, which tools, and who supplies each one.

Compare it to the allergen sheet behind the counter in a bakery. It does not make the bread safer. It makes the question answerable in the ten seconds the customer is standing there.

If you bought your AI rather than built it, and almost every company did, the chain has about eight links.

• A base model you did not train, from Anthropic, OpenAI, Google or an open-weight family.

• Either weights on your own hardware, or an API where the model never leaves the provider's machines. The second is far more common and leaves you far less to look at.

• Training data you cannot see, which decides most of how the model behaves.

• A fine-tune your software vendor applied on its own material, rarely mentioned on the invoice.

• Libraries and frameworks, the one part a classic SBOM already covers properly.

• A vector store with your indexed documents, plus the embedding model that turned them into vectors.

• Tools and MCP servers: your CRM, a mailbox, a payment endpoint, a search API.

• The vendor's hosting: which cloud, which region, whose data terms.

Most companies can name the first link and the last one. The middle six are where the surprises sit.

SBOM versus AIBOM: what you can actually inspect

An SBOM answers what is inside a program. An AIBOM is that same list applied to an AI system, and it needed its own name because two components refuse to behave like software.

With an SBOM you can open the component. A row says openssl 3.0.11, so you can read the source, hash the binary and look the version up in a vulnerability database. The version string is a promise: those exact bytes, forever.

With a model you cannot. Best case you hold the weights, which tell you the architecture and the size and nothing about what the model learned or from where. Usually it is worse: the model is an endpoint and you hold nothing. Training data decides how the thing behaves, and no bill of materials gives you access to it.

The second difference is timing. A library pinned at 2.4.1 is the same code next year. A hosted model behind a plain name or a latest alias gets replaced on the provider's schedule, while your prompts and output parsers sit on top of the version you tested. Anthropic gives at least 60 days' notice before retiring a publicly released model and says requests to a retired model will fail. Clear policy, and still a component of your product with an expiry date somebody else set.

An SBOM lists things you can open and verify. An AIBOM lists things you can only name, date and attribute to a supplier.

Where the standards stand in September 2026

Real standards work exists here, with a lot of marketing on top. The split matters, because a supplier claiming a standards-compliant AIBOM is saying something you can check.

CycloneDX is published and is what you are most likely to be handed. Version 1.5 added machine-learning-model and data as component types next to the software ones, plus a modelCard object for model parameters, datasets, technical limitations and ethical considerations, which is the machine-readable cousin of the model card a provider publishes as prose. Version 1.7 came out in October 2025 and was ratified by the ECMA General Assembly that December as the second edition of ECMA-424.

SPDX is published too. Its AI profile is a normative part of the 3.0.1 specification, with an AIPackage class carrying properties such as typeOfModel, safetyRiskAssessment and useSensitivePersonalInformation, next to a separate Dataset profile.

CISA and the G7 published guidance, and it is explicitly voluntary. Software Bill of Materials for AI: Minimum Elements appeared in May 2026 from CISA with Germany, Canada, France, Italy, Japan, the United Kingdom and the European Union. It sorts the content into seven blocks: document metadata, system level properties, models, dataset properties, infrastructure, security properties and performance indicators. The text calls those elements supplemental to the general SBOM minimum elements, and neither exhaustive nor mandatory.

What does not exist is a law requiring you to publish a document called an AIBOM. The word appears in no article of any European regulation. Regulation asks for the content instead, and only from specific parties.

What the AI Act asks, and from which role

The AI Act hands out a role per system, and the documentation duty lands almost entirely on providers. A company that buys AI software is a deployer, and a deployer owes no bill of materials.

A provider of a high-risk system owes the technical documentation of Annex IV, and two of its points read like an AIBOM written out in sentences. Point 2(a) asks how the system was developed, including recourse to pre-trained systems or tools provided by third parties and how those were used, integrated or modified. Point 2(d) asks for datasheets on the training data: provenance, scope and main characteristics, how the data was obtained and selected, the labelling procedures and the cleaning methods.

A provider of a general-purpose AI model owes something narrower and public. Article 53(1)(d) requires a summary of the content used to train the model, on a mandatory template the Commission published in July 2025. That template shows how much transparency the law actually bought: the large publicly available datasets used, and the top 10 percent of the domains scraped, dropping to 5 percent or 1000 domains, whichever is lower, for SMEs. The obligation applies since 2 August 2025, and older models have until 2 August 2027.

A deployer gets Article 26, which is about use rather than composition: follow the instructions for use, assign competent human oversight, keep the input data relevant, keep the logs, inform the people affected. Nowhere does it ask what the model was trained on. The deadline for those high-risk duties moved to 2 December 2027 with the Digital Omnibus on AI, Regulation (EU) 2026/1744.

The one page an SME should keep

A company of forty people will never produce a CycloneDX document and does not need to. It needs a table somebody can open during a meeting, with five columns: which model, through which vendor, on which contract, holding which data, and with which fallback.

Write the exact identifier your system calls, claude-sonnet-4-5-20250929 rather than "Claude", because the brand is not the thing that stops working. Record whether you buy it straight from the model provider or inside a piece of software, since that decides who you phone. Note what the data terms say about training on your input, what goes in as data, and what you would move to if this disappeared next month.

Two more lines per system finish it: who owns it, and which tools it may call. That second one is the line almost nobody fills in.

A worked example: which of our systems use model X?

Take a Belgian engineering firm of fifty-five people. On 14 April 2026 Anthropic announced that claude-sonnet-4-20250514 would retire on 15 June. Somebody forwards the mail internally and asks whether it touches them.

Without a list. Nobody can answer, so the answer gets assembled. The IT lead searches the code repositories and finds two hits. Finance asks their invoice-processing vendor, who replies after nine days that they run on Azure OpenAI, which turns out to be beside the point. A marketing tool bought on somebody's own card, shadow AI by another name, is remembered by one colleague in week three, and a Power Automate flow built by someone who has since left the company is found on 10 June by accident, five days before the shutdown. Nobody is ever sure the search was complete, and the whole exercise starts from zero at the next announcement.

With the list. Somebody opens the sheet, filters the model column and has four rows inside a minute, each with an owner: two internal scripts, the quoting assistant a customer sees, and a vendor product where the row already records that the vendor manages the version. The customer-facing one gets tested against the replacement first, the scripts get switched the same afternoon, and the vendor gets a mail asking for their migration date.

Both firms had the same sixty days of notice. One of them could turn a provider announcement into a list of names on the day it arrived.

What to watch out for with an AIBOM

A list does not make anything secure. It makes questions answerable. When a library in your stack turns out to carry a known vulnerability, when a vendor changes its data terms, or when a customer asks what a system was built on, the list is the difference between an answer in a minute and a fortnight of asking around.

It goes stale faster than an SBOM. A software dependency list changes when somebody deploys. An AI list changes when a provider updates a model behind an alias, with no deploy on your side at all. Put a date and an owner on the sheet and read it again every quarter.

The vendor's document covers the vendor's product. A supplier's AIBOM says what is inside their own product, and nothing about the vector store you connected or the mailbox you gave it access to.

The tools are the missing column. Models get inventoried because they have names and invoices behind them. What an agent may call gets inventoried by nobody, and that is where the damage an attacker can reach actually sits.

Do not buy software for this before you have a spreadsheet. Generators exist and they work, mostly on models you host yourself. If your AI arrives inside SaaS products, no scanner will find it. Somebody has to ask the vendors, and that person is the actual project.