Procurement wants your bill of materials.

Why "we follow best practices" stopped closing deals

The software Bill of Materials — the SBOM — got its regulatory push after a run of supply-chain incidents made one thing undeniable: you cannot secure what you cannot list. A buyer who does not know which open-source libraries sit inside the product they bought cannot tell, when the next vulnerability drops, whether they are exposed. The SBOM answered that by making the parts list a deliverable. The AI Bill of Materials is the same idea applied to a stack that is harder to inventory and easier to lie about.

An AI system's supply chain is not just code. It is a foundation model whose weights came from somewhere, fine-tuning data whose provenance is often fuzzy, a vector index built from customer documents, a chain of third-party model APIs the request passes through, and a set of frameworks and hardware that determine how any of it behaves. Every one of those is a component a regulated buyer now has reason to ask about — because a poisoned dataset, a model with unknown licensing, or a silent dependency on an external API that trains on the input are all supply-chain risks that a security questionnaire full of yes/no boxes never surfaces.

So the questionnaire changed. Where a 2024 RFP asked "do you follow secure development practices," a 2026 RFP asks "provide your AI-BOM." The shift is the same one we described for the high-risk deadline: the obligation moved from something you assert to something the system has to emit. A vendor that answers with prose has already lost to the one that attaches a versioned, machine-readable inventory — because the buyer's own auditor can ingest the second answer and cannot verify the first.

What an AI-BOM actually inventories

The word "inventory" undersells it. A credible AI-BOM covers six areas, and the ones teams skip are exactly the ones auditors probe. It is not a list of npm packages with "plus we use some models" bolted on the end.

• Models — every model in the pipeline, including third-party ones reached by API: name, version, provider, licence, and whether the model was fine-tuned and on what.
• Data — training, validation, fine-tuning and reference data, with provenance: where it came from, how it was licensed, and what transformations it went through before the model saw it.
• Code and dependencies — the software components, ML frameworks and transitive dependencies, the part that overlaps a classic SBOM and can be generated the same way.
• Hardware and infrastructure — the accelerators, runtimes and deployment surface the inference actually runs on, which matters for both reproducibility and residency claims.
• Pipelines — the processing steps between raw input and output: pre-processing, retrieval, prompt construction, post-processing and the guardrails in the path.
• Governance metadata — the evaluation results, known limitations, intended use and change history that turn a parts list into something an auditor can reason about.

The component that separates a real AI-BOM from a marketing artifact is provenance. Listing that the pipeline uses a given foundation model is table stakes; being able to say where the training data came from, and which transitive third-party model entered through a dependency's back door, is the part that survives scrutiny. The most common gap we see is exactly this: an inventory that names the model the team chose and is silent about the model that the model calls.

Two formats matured to the point of being contractually nameable in 2026, and they are not interchangeable. Knowing which one to hand over — and which to generate for yourself — is now part of the job.

The pragmatic pattern that emerged is to generate CycloneDX internally in CI/CD — where the pipeline knows its own components and can keep the inventory honest on every build — and to ask for SPDX from external suppliers, where the regulatory weight and the licence disclosure sit, with translation between the two formats where a buyer standardizes on one. What you do not want is a single static document in either format that was true at one release and has been drifting ever since.

The framework that survives the RFP

Producing an AI-BOM once, by hand, for a specific deal is the trap. It reads well in the moment and rots the day after. The teams that answer the AI-BOM question without a fire drill share a small set of habits, and none of them are about writing a better PDF.

Generated in the pipeline, not drafted at deal time

The defining property of a trustworthy AI-BOM is that it is a by-product of the build, not a document assembled under deadline. When the inventory is emitted by the CI/CD pipeline on every release — components resolved, versions pinned, models and datasets recorded as they are wired in — it describes the stack that actually shipped. A hand-drafted AI-BOM describes the stack someone remembered, which is a different and less defensible thing.

All six areas, with provenance on the two that matter

Covering code and dependencies is the easy 60% because SBOM tooling already does it. The value is in the other four, and above all in provenance for data and for third-party models. An AI-BOM that lists frameworks and stops has answered the question a classic SBOM already answered. The one that traces the training data to its source and names the transitive model dependency is the one that changes the auditor's posture from suspicious to satisfied.

The right format for the right reader

SPDX 3.0's AI Profile carries the regulatory and licence weight, which is why it is the artifact to hand a regulated buyer; CycloneDX ML-BOM slots into the security pipeline and is the one to generate internally on every build. The habit that scales is to produce both from the same underlying inventory and translate between them, rather than maintaining two parallel documents that drift apart and eventually contradict each other in front of the buyer.

The AI-BOM as an RFP clause you can also answer

The most reliable way to keep your own AI-BOM current is to require one from your suppliers. A homologation clause that makes a vendor's AI-BOM a condition of onboarding does two things at once: it closes the transitive-dependency gap that is otherwise invisible, and it forces the same discipline internally that you are demanding externally. A team that asks its vendors for an inventory it cannot produce for itself does not survive the first reciprocal question.

The AI-BOM is not a document you write about the system. It is a view over what the system already recorded about itself — which is why the ones drafted by hand are the ones that turn out to be fiction.

Four ways the AI-BOM goes wrong

The failure modes are not exotic. Each has a defensive pattern that costs far less applied early than discovered in an audit.

The static AI-BOM that lies about the current stack

The inventory is generated once, attached to a deal, and never regenerated. Three releases later it describes a model version that is no longer in production and omits two dependencies that are. At audit time the gap between the document and the running system is the entire finding. The fix is to make the AI-BOM a build artifact: regenerated on every release, versioned alongside the code, never edited by hand.

The inventory with no data provenance

The AI-BOM lists models and libraries in clean detail and says nothing about where the training or fine-tuning data came from. This is the gap that a data auditor heads straight for, because it is where poisoning, licensing violations and privacy exposure hide. The fix is to treat provenance as a required field, not an optional one — an inventory of the data is not complete without its lineage.

Treating the AI-BOM as a marketing piece

The document is polished, confident and traceable to nothing. It asserts a clean stack without the component-level references that let anyone verify the claim. This fails the same way a security posture without evidence fails: the moment the buyer's auditor asks "show me," the artifact has nothing behind it. The fix is traceability — every component links to its source, its version and its licence, so the AI-BOM is checkable rather than merely readable.

Ignoring the third-party model that came in the back door

The team inventories the models it chose and misses the one those models call. A retrieval step reaches an embedding API, a "single" model routes to a fallback provider, a dependency ships a model of its own — and none of it appears in the AI-BOM. The fix is to resolve transitive model dependencies the way SBOM tooling resolves transitive code dependencies: follow the chain, not just the top level.

The trade-off, stated honestly

There is a real cost to generating and maintaining an AI-BOM, and waving it away would be dishonest. Instrumenting the pipeline to emit a complete, provenance-bearing inventory on every release is engineering work. It competes with roadmap features a customer can see today, and it imposes a discipline — pinning versions, recording data lineage, tracking transitive model dependencies — that a team can otherwise defer indefinitely. A vendor that builds all of it before anyone asks has spent effort ahead of the demand. That is the honest downside.

The other side of the trade is the RFP filter. A vendor that answers the AI-BOM question with prose is not merely marked down — it is set aside at the first procurement gate, in exactly the regulated verticals where document AI is worth the most. The AI-BOM also maps directly onto the EU AI Act's Annex IV technical-documentation requirement, so the same artifact that clears the procurement gate is a down-payment on the high-risk conformity work due the same year. The cost of building it is a known quantity, paid in engineering weeks. The cost of not having it is a deal you cannot enter and a documentation obligation you will scramble to meet later, under an audit schedule you do not control. For any vendor with regulated exposure, the trade favours generating the inventory as architecture — once, automatically — rather than assembling it repeatedly, by hand, under deadline.

What we ship at Cogneris

Cogneris was built as an audit-instrumented platform, which means the pipeline already records most of what an AI-BOM needs — the question was only how to surface it. The choices that show up in the architecture are the ones the procurement bar happens to reward:

• Component inventory as a pipeline output — the models, versions, frameworks and dependencies in each tenant pipeline are recorded as the pipeline is built, so the parts list is a query rather than a reconstruction project.
• Provenance on data and models — data sources and the third-party models reached along the way are logged at runtime, giving the lineage the two hardest AI-BOM fields demand without a forensic exercise.
• Transitive model resolution — the inventory follows the chain past the model the tenant chose to the models it calls, so the back-door dependency shows up in the list instead of in the audit finding.
• Format on demand — the same underlying inventory renders as the machine-readable artifact a security pipeline ingests internally and as the disclosure document a regulated buyer requests, rather than two documents maintained in parallel.
• Versioned with the release — the AI-BOM is regenerated as the pipeline changes and retained with the audit trail, so "is this current?" has the same answer as "is this the version in production?"

Where we deliberately stop

An honest list of what an AI-BOM does not do for the customer, because pretending otherwise would be wrong.

The AI-BOM is not the compliance verdict. An accurate parts list tells you what the system is made of; it does not decide whether a given deployment is in Annex III scope, or whether a component's licence is compatible with the customer's use. It makes those determinations cheap to defend by holding the evidence. It does not issue them.

An inventory is not a guarantee of quality. Listing a model, its provenance and its evaluation results does not make the model accurate, fair or robust. The AI-BOM tells the auditor what to examine; it does not replace the examination. A complete inventory of a bad stack is still an inventory of a bad stack.

Jurisdictional legal advice. Everything here is operational, not legal. The formats, the regulatory mapping and the dates are our working understanding, and standards evolve. The customer's counsel owns the reading the customer relies on; we refuse to substitute for it.

Closing thought

The AI Bill of Materials is not a new compliance program sitting beside the product. It is a property the pipeline either has or does not have — the ability to produce, on demand, a current and traceable account of what it is made of — and the buyer's auditor now assumes the property is there. The teams that will pass treat the inventory as a build artifact: generated in the pipeline, complete across all six areas, provenance-bearing on data and models, rendered in whichever format the reader needs, and versioned with every release. The teams that will struggle treat it as a document to write when the RFP arrives, and discover that the honest version takes quarters to assemble because the runtime never recorded what the document is supposed to claim. The buyer has stopped accepting self-attestation. The parts list is the new answer, and it is the answer Cogneris was built to be able to give.

If your next regulated RFP is going to ask for an AI-BOM — and the request will arrive the same week your customer's audit does — see our data-protection page for the control posture we ship, or talk to our team and we will walk you through the inventory your pipeline can already produce, before the questionnaire lands, not after.