The request that arrives in the middle of a renewal
It usually comes through procurement, attached to a security review, four weeks before a contract that was supposed to renew on paper. The wording varies. Some customers ask for an AI bill of materials by name. Some ask for a model inventory, an AI component disclosure, or a list of every third-party model and dataset used in delivering the service. A bank or an insurer routes it through model risk management and cites SR 11-7. A hospital system routes it through vendor risk. The question underneath is identical: tell us everything in your product that learned from data, and where it came from.
The first response most companies give is a paragraph. We use a commercial large language model provider under an enterprise agreement, we do not train on customer data, our vendors are SOC 2 audited. That answer is true and it is usually enough for round one. It fails in round two, when a named reviewer sends back three questions: which specific model version, what happens when the provider deprecates it, and what other models are in the path. Almost nobody can answer the third question from memory, because the answer includes an embedding model somebody selected eighteen months ago, a reranker added during a latency fix, an open-weights classifier a contractor dropped in to route support tickets, and a fine-tune of a small model that exists only as a checkpoint in a storage bucket with one person's name on it.
The gap is not a documentation gap. It is an inventory gap that the documentation request exposed. The companies that clear these reviews in days rather than months are the ones whose build system already knows the answer, and the whole engineering problem is getting the build system to know it.
What Enterprise Reviewers Actually Ask For — Our Ranking by How Often It Blocks a Signature
Relative frequency across vendor security reviews we have worked, not a survey. The ordering is the useful part.
An AIBOM is a software bill of materials with four extra columns
The software bill of materials became a fixture of enterprise procurement after Executive Order 14028 pushed it into federal software purchasing in 2021, and the tooling settled on two formats: CycloneDX, maintained by OWASP, and SPDX, standardized as ISO/IEC 5962. Both now carry model and dataset component types. CycloneDX added a machine learning model card structure in version 1.5. SPDX 3.0 added AI and dataset profiles. So an AIBOM is not a new artifact class you invent. It is your existing dependency inventory with model, dataset, prompt and service components added, in a format your customer's scanners already ingest.
The four things an AI component carries that a software package does not are worth stating plainly. A model has weights, which are not source and cannot be diffed. A model has training data, which is a provenance claim rather than a file you ship. A model has a license that frequently restricts use rather than distribution, which is the opposite of how most open-source licenses behave. And a model has measured behavior that changes when anything upstream of it changes, so the version identifier has to cover more than the weights file.
That last point is where hand-written AIBOMs fail. A team lists gpt-class-model, v4 and considers the row complete. The reviewer then asks what the system prompt says, because the system prompt determines the output as surely as the weights do, and it is edited far more often. A prompt is a component. So is a retrieval index, a threshold, and a guardrail filter.
What actually belongs in the inventory
The scoping rule we use: include everything that, if changed, would change the output for some input a customer cares about. That test settles nearly every argument about what belongs in the document.
| Component | What the row has to pin | Where the record usually goes missing |
|---|---|---|
| Hosted model APIs | Provider, model identifier, pinned version or snapshot, endpoint region, data retention terms in force | Code calls a floating alias, so the version in the document is a guess about what production resolved to last Tuesday |
| Open-weights models | Repository, revision hash, weight file digest, license text, quantization applied | A model pulled by name from a hub at container build time, meaning the artifact changed without a code change |
| Models you trained or tuned | Base model, training data snapshot identifier, training code commit, hyperparameters, output artifact digest | A fine-tune produced in a notebook, with the base model recorded and the data selection query lost |
| Embedding models and rerankers | Same as above, plus the index they populated and when it was last rebuilt | Treated as infrastructure rather than as a model, so nobody thinks to list it |
| Prompts and instructions | Content hash, storage location, who can change it, whether a change requires review | Edited in a dashboard by a non-engineer, with no version history and no link to a release |
| Retrieval corpora | Source systems, refresh cadence, tenant isolation method, what gets excluded | The corpus contains customer content, which turns an inventory question into a data residency question |
| Guardrails and filters | Vendor or library, version, the policy configuration itself, failure behavior | Configuration lives in a console, not in the repository, so it is invisible to any generated document |
| Serving runtime | Inference server and version, base image digest, accelerator drivers, resolved dependency lock | Already covered by the existing SBOM, and then decoupled from the model rows so nobody can join them |
Generate it from the build, never write it by hand
A hand-written AIBOM is accurate on the day it is written and wrong within a sprint. This is the single most consequential decision in the whole exercise, and it is an engineering decision rather than a compliance one.
The mechanism is straightforward. Every AI component gets a declaration that lives next to the code that uses it, in the repository, under review. The build pipeline reads those declarations, resolves each one to a concrete identifier at build time, and emits a CycloneDX or SPDX document as a release artifact alongside the container image. Resolution is the part that carries the value: a declaration that names a model alias gets resolved to the snapshot the alias pointed at during that build, and the resolved value is what lands in the document.
Two rules make it hold. First, the build fails when a declared component cannot be resolved to a pinned identifier, which is what stops a floating tag from reaching production without anybody noticing. Second, an undeclared component in the runtime path fails a check, which requires a small amount of instrumentation on outbound model calls but converts the whole problem from an audit into a test. A team that adds a reranker without declaring it finds out in continuous integration, not in a customer security review nine months later.
The generation itself is a few days of work. What fills the calendar is discovering that the embedding model is pulled by tag, the prompts live in a database, and the guardrail policy exists only in a vendor console. Every one of those is a real operational risk the inventory work happened to surface first.
The provenance question you cannot answer, and how to answer it anyway
Somewhere in the review a reviewer will ask what data a foundation model was trained on. You do not know. Neither does anyone outside the lab that trained it, and pretending otherwise is the fastest way to lose credibility with a technical reviewer who already knows the answer.
The correct response has three parts and it works reliably. State what is known and cite it: the model card the provider published, the contractual terms governing your use, and the provider's own disclosures. State the boundary precisely: training corpus composition is not disclosed by the provider, and here is the clause in our agreement that addresses indemnity and output ownership. Then state what you control and can evidence: your data does not enter training, here is the setting and the contract term that establishes it, here is what your retention window is, and here is the evaluation you run against the model in your own context.
Reviewers accept bounded claims with evidence. They escalate confident answers that turn out to be wrong.
For anything you trained or tuned yourself, the standard is different because you do control it. There the expectation is a dataset snapshot identifier, a documented selection method, a licensing position on every source, and a statement of what was excluded. If a fine-tune used customer data, that fact needs to appear in the document with the contractual basis next to it, because it will surface later and it is far cheaper as a disclosure than as a discovery.
Where the frameworks fit, and which one your customer is holding
Reviewers rarely say which framework is behind their questions, but the questions have accents you can recognize.
A question set organized around govern, map, measure and manage is reading from the NIST AI Risk Management Framework. A request for evidence of an AI management system, with internal audit and management review, is ISO/IEC 42001, which more enterprises are certifying against and then pushing down to suppliers. Questions about prompt injection, insecure output handling, training data poisoning and excessive agency come from the OWASP Top 10 for LLM Applications. Questions phrased as adversary techniques against an ML system come from MITRE ATLAS. Questions about model validation being performed by someone independent of the model developers are SR 11-7, and they mean a bank or an insurer is on the other end.
An AIBOM satisfies none of these on its own. What it does is supply the object each one operates on. NIST AI RMF Map cannot be completed without an inventory. A threat model against OWASP or ATLAS is a list of guesses until it is anchored to real components. The inventory is the substrate, which is why building it first is cheaper than building it fourth.
How Much of a Review a Given Artifact Closes Out
Editorial ranking of how much of a typical enterprise AI review each artifact retires, read from the question sets reviewers send. An ordering of effect, not a measured statistic.
The spread between the top row and the bottom row is the whole argument. A narrative answer is a claim about a system. A generated document is an observation of one, produced by the same pipeline that produced the running code, which is why a reviewer treats it differently.
The five failure modes that cost the most
The floating version. Production calls a provider alias that silently advances. Your document says one thing, your traffic does another, and the day the provider retires the snapshot behind the alias your outputs change without a deploy. Pin the snapshot, and put the deprecation date in your own calendar.
The console-configured component. Prompts, thresholds and guardrail policies edited outside the repository are invisible to any generated artifact and to code review. Either bring them into the repository and deploy them, or accept that your inventory has a hole with a person's login in it.
The shadow model. A team ships a small classifier or a summarizer without telling anybody, because it felt like a library call rather than a model. Runtime detection on outbound model calls is the only reliable fix. Policy alone does not find these.
The license nobody read. Open-weights licenses often carry use restrictions rather than distribution restrictions, and some carry acceptable-use terms that flow to your customers. A model that is free to download can still be unusable in a specific commercial deployment, and that is a question your legal team wants before a customer's legal team asks it.
The stale document. An AIBOM produced once for a review is worse than none, because it creates a written claim you will contradict. Generation per release is the only version of this that stays true, and it is the version that makes the next review cost hours instead of weeks.
What this looks like as a piece of work
We scope this in three stages, and the sequence matters because each one makes the next cheaper.
Discovery, one to two weeks. Trace every path from a user request to an output and name every component that touches it, including the ones that are not in any repository. The deliverable is a component list with a resolution status against each row: pinned, floating, or unlocatable. The unlocatable rows are the finding, and there are always some.
Pinning, two to four weeks. Convert floating references into pinned ones, move console configuration into the repository, and give every trained artifact a real identity with lineage attached. This is ordinary engineering work with an ordinary schedule, and it improves reliability whether or not anybody ever asks for the document.
Generation and gating, one to two weeks. Emit a CycloneDX or SPDX document per build, attach it to the release, and add the two checks: unresolved declaration fails the build, undeclared runtime component fails the check. After that the document is free, and the next customer questionnaire is a retrieval rather than a project.
The whole sequence runs six to ten weeks with one or two engineers, and the pinning stage is where the variance lives. Teams that already pin container images and lock dependencies move faster, because the discipline transfers directly.
Bottom line
The AI bill of materials request is not really a documentation request. It is your customer asking whether you know what is in your own product, and the honest answer for most companies right now is partially. The teams that clear these reviews quickly are not the ones with the best writers. They are the ones whose components are pinned, whose configuration lives in a repository, and whose build system emits the inventory as a byproduct of shipping. That work pays for itself the first time a provider deprecates a model version and you can tell in a minute which features are affected. The security review is just the deadline that finally made it worth doing.
Frequently asked questions
CycloneDX or SPDX. Both carry model and dataset component types now, and both are ingested by the tooling enterprise security teams already run. Pick whichever your customers' scanners already accept, and emit it from the build rather than authoring it.
You cannot, and reviewers who work in this area know it. Cite the provider's published model card, state the disclosure boundary plainly, and then give full detail on what you do control: whether your data enters training, retention terms, and your own evaluation results.
Yes. A prompt determines output as directly as weights do and changes far more often. Give it a content hash, store it in the repository, and put it through review. A prompt edited in a console is the most common hole in an otherwise complete inventory.
Six to ten weeks for a product with five to twenty AI components, with one or two engineers. Generation is days. The time goes into pinning floating references and pulling console-managed configuration into the repository.
Every release, automatically. A document produced once for a review becomes a written claim you will contradict at the next one. Per-build generation is the only approach that stays true without anybody maintaining it.