Seriesaibom-library

AIBOM Questions to Ask Every AI Vendor

aibom ai-vendor-risk third-party-risk ai-procurement ciso ai-governance cyclonedx

October 29, 2026 · PlayCISO

TL;DR

Before you buy or approve an AI model or AI product, ask the vendor for evidence in six areas: identity and lineage, data, security and runtime, evaluation and risk, attestation, and change notification. For each question there is an AIBOM field that proves a good answer, such as pedigree.ancestors for the base model, a VEX analysis for each advisory, or a signature link for the weights. Answers that cannot be checked against a field are the red flags. Put delivery of the AIBOM, change notice, vulnerability notice and an AI-specific incident definition into the contract.

Put it into practice

Turn these questions into an approval gate

The AI Model Intake and Approval Checklist (Pro) walks a model through identity, data, security, evaluation and attestation checks before it reaches production, and records the decision and its conditions.

Open the Intake Checklist

Ask an AI vendor for evidence, not assurances. Twenty questions in six groups cover what you need before you buy or approve a model: what it is, what it learned from, what it runs on and can reach, how it was tested, who vouches for it, and how you hear about changes. For each one, a good answer points at a field in an AI Bill of Materials (AIBOM). An answer that points at nothing is the red flag.

Who this is for: CISOs and security leaders who buy AI products or approve models for production, and the third-party risk teams who run the reviews for them.

First: what kind of vendor is it?

You run the model (open weights, a vendor-supplied fine-tune, an appliance). Ask for the full AIBOM, in CycloneDX 1.6 or later or SPDX 3.0. Every question below applies.
You call a hosted model API. You will not get weight hashes or a runtime list. Ask for a dated model snapshot you can pin, the model or system card, the sub-processor list and written change notice. If the vendor provides a general-purpose AI model and you build an AI system on it, Article 53(1)(b) of the EU AI Act entitles you to the Annex XII information, unless the open-source exemption applies.
You buy a product with AI inside. Ask for the AIBOM of the system: the models it uses, whose they are, and the tools and data it can reach.

The worked example in this series is Northwind Health, a fictional company that runs a support assistant called Triage Assistant v2.3. Its AIBOM is used below to show what a good answer looks like.

Identity and lineage

Question	Why it matters	A good answer (the field that proves it)	Red flag
1. Which exact model and version will we run, and how do we pin it?	You cannot scope an advisory, reproduce a test or notice a silent swap without an exact version.	Name, version and an immutable identifier: CycloneDX `name`, `version`, `purl` (for a Hugging Face model, the revision commit hash) and `hashes`. For an API: a dated snapshot ID you can request.	“You always get the latest model.”
2. What is it built from: base model, fine-tunes, adapters, merges?	A licence restriction, backdoor or flaw in a base model travels into every model built on it.	CycloneDX `pedigree.ancestors`; SPDX `descendantOf`; Hugging Face `base_model` with `base_model_relation`.	“Proprietary” for what is plainly a fine-tune, with no base model named.
3. Under which licences: the model and every ancestor?	Use restrictions in a base model’s licence bind you too.	`licenses` on the model and on each ancestor component, as SPDX licence IDs where they exist.	A licence for the vendor’s wrapper only; nothing for the base model.

A good answer to question 2 is short. Northwind’s model component names its ancestor and how it was derived: pedigree.ancestors lists mistralai/Mistral-7B-Instruct-v0.3 with its revision-pinned purl, and pedigree.notes says “Fine-tuned from mistralai/Mistral-7B-Instruct-v0.3 with LoRA adapters merged into the base weights before release.” The identity and lineage guide shows each derivation type in each format.

Data

Question	Why it matters	A good answer (the field that proves it)	Red flag
4. What data trained and fine-tuned it, at least by category and source?	Data decides behaviour, bias and legal exposure (copyright, personal data).	CycloneDX `data` components (`contents`, `classification`, `governance`); SPDX `dataset_dataCollectionProcess`; a datasheet per dataset. For a general-purpose model, the public training-content summary required by Article 53(1)(d).	“Industry-standard datasets.”
5. Does any training data contain personal or sensitive data, and how was it treated?	Sensitive data in training can surface in outputs.	CycloneDX `sensitiveData`; SPDX `dataset_hasSensitivePersonalInformation` and `dataset_anonymizationMethodUsed`; Croissant RAI `rai:personalSensitiveInformation`.	“We don’t keep personal data” with no word on how it was removed.
6. Will our prompts, files or feedback be used to train anything?	Your confidential data becomes someone else’s model.	A contract clause, not a settings page. The AIBOM cannot prove a negative; the contract can.	The answer exists only in a FAQ or a toggle the vendor can change.
7. How would you know if training data had been tampered with?	Article 15(5) of the AI Act names data poisoning as an AI-specific attack.	Versioned datasets with hashes on each data component, and a named owner who controls changes.	No dataset versions; “we retrain continuously from the web”.

A datasheet behind each dataset makes questions 4 and 5 easy to answer and easy to check. See the AIBOM data section guide and dataset card templates compared.

Security and runtime

Question	Why it matters	A good answer (the field that proves it)	Red flag
8. What format are the weights, and what loader setting enforces it?	Loading a pickle-based checkpoint can run code. Safetensors cannot.	A recorded weights format (for example safetensors) and the pinned loader setting, both as testable properties.	Third-party .bin or .pt files loaded with default settings.
9. What runtime serves it, at which exact versions, and how do you handle advisories?	Inference servers have advisories like any other software.	Every library with `version` and `purl`; a `vulnerabilities` entry per matching advisory with `analysis.state` and `justification` (a VEX statement).	“No known vulnerabilities”, with no version list to check it against.
10. What tools, MCP servers, retrieval indexes and APIs can the model reach, with what permissions?	What a model can reach decides the blast radius of a prompt injection.	Each as a CycloneDX `service`: `endpoints`, `authenticated`, `x-trust-boundary`, `data` flows with classification, and permissions.	Write permissions wider than the stated use.
11. Where does inference run, and does any other model provider see our prompts?	Many AI products wrap another company’s model.	Services and their data flows in the AIBOM, matched by the sub-processor list.	An upstream model API that appears only after you ask twice.

Why question 9 matters in practice: Northwind’s AIBOM lists vLLM 0.6.3 with torch 2.4.0. That precision is what lets a scanner match CVE-2025-24357 and its fix bypass, and lets Northwind record a verdict for each. The security and runtime guide shows the VEX entry, and using an AIBOM in incident response shows what happens when the verdict is tested.

Evaluation and risk

Question	Why it matters	A good answer (the field that proves it)	Red flag
12. What was it tested on, with what results, for a use like ours?	Leaderboard scores rarely match your task or your data.	`modelCard.quantitativeAnalysis.performanceMetrics` with `slice` (the test set) and `confidenceInterval`; SPDX `testedOn`.	Benchmark names only, no test set, no uncertainty.
13. What is it not for, and what are its known limitations?	Out-of-scope uses are where your controls must go.	`considerations.useCases` and `considerations.technicalLimitations`; SPDX `ai_limitation`; a model card “Out-of-Scope Use” section.	“No known limitations.”
14. Has it been red-teamed, including injection through retrieved content and tools?	Indirect prompt injection is the live risk for assistants with tools.	`considerations.ethicalConsiderations` with `mitigationStrategy`, and a dated test report linked from the AIBOM.	“The base model provider handles safety.”
15. How does it perform for different groups of users?	An average can hide a group the model fails.	`considerations.fairnessAssessments` and per-slice metrics.	Not measured, and not listed as a limitation either.

Ask for the model card as well as the AIBOM, and score it. Real model cards, reviewed and scored shows how far public cards fall short, and the Model Card Scorer (Pro) scores a vendor’s card against the same rubric.

Attestation

Question	Why it matters	A good answer (the field that proves it)	Red flag
16. Is the model signed, and which signing identity should we expect?	A hash proves which bytes you have; a signature proves who produced them.	`externalReferences` type `digital-signature` pointing at, for example, a Sigstore bundle from OpenSSF model signing, plus the identity to verify against.	“It’s delivered over HTTPS.”
17. Can you show build provenance that links the model to its inputs?	Provenance names the base model revision and dataset hashes the build used.	`externalReferences` type `attestation` to SLSA provenance in an in-toto statement. Ask who issued it: the vendor, its build platform, or a third party.	A PDF letter in place of a verifiable statement.
18. Is the AIBOM itself signed and versioned?	An unsigned AIBOM can be edited to match a swapped model.	A `serialNumber` and `version` per BOM, and a signature over the BOM.	The AIBOM is a spreadsheet emailed on request.

A vendor attesting to its own model is not the same as a build platform or a third party attesting to it. Who can attest to an AI model, and to what explains the difference, and sign a model and attach provenance shows what a verifiable answer to questions 16 and 17 looks like.

Change notification

Question	Why it matters	A good answer (the field that proves it)	Red flag
19. How much notice do we get before the model, its base, its data or its tools change?	A silent change invalidates your testing and your approval.	A new AIBOM version per release, a diff against the last one, and a notice period in the contract.	“Updates are continuous and transparent to customers.”
20. How and how fast will you tell us about new vulnerabilities and AI incidents?	Your own reporting clock starts when you become aware, not when they tell you.	A VEX update for affected components within an agreed time, and an incident definition that includes model compromise, data poisoning, unauthorised model change and exposure of your data through outputs.	An incident definition that covers personal-data breaches only.

When a new version arrives, compare the two AIBOMs before you re-approve. The AIBOM Diff (Pro) shows what changed: model, base, data, runtime or services.

Hold your own AI to the same bar

Northwind’s own AIBOM, checked against the same questions:

Questions	In Northwind’s files
1–3 Identity, lineage, licences	Yes: `northwind/triage-assistant` 2.3.0, hashed; ancestor `mistralai/Mistral-7B-Instruct-v0.3` pinned by revision, Apache-2.0
4–5 Data	Yes: `northwind/support-tickets-2025` (48,210 de-identified tickets) and `northwind/triage-eval-v4`, both hashed, classified confidential
8 Weights format	In a description sentence only, not as a testable property
9 Runtime and advisories	Versions yes (vLLM 0.6.3, torch 2.4.0); no `vulnerabilities` section
10 Tools and services	Yes: `northwind-helpcentre-index` and `ticketing-mcp` as services; the MCP tool list is missing and the write scope is wider than drafting needs
12–13 Evaluation and limits	Yes (fictional): accuracy 0.87 on `northwind/triage-eval-v4`, out-of-scope uses listed; no confidence interval
15 Groups	Not measured
16–17 Signature and provenance	Yes: Sigstore bundle and SLSA provenance linked
18 Signed AIBOM	No

Fictional example. Northwind Health, Triage Assistant and its datasets, services, scores and URLs are invented for illustration; the base model and open-source libraries are real.

Even a careful team leaves gaps. Ask vendors for the gaps they know about; a vendor who lists none has usually not looked.

Contract clauses to ask for

These are the points to raise with your lawyer, in plain words. They are not legal advice or contract wording.

AIBOM delivery. A machine-readable AIBOM (CycloneDX 1.6 or later, or SPDX 3.0) at onboarding and with every release, covering the model, its ancestors, datasets at least by category, the runtime and the services the model can reach.
Change notice. Written notice a set number of days before a change to the model version, base model, training data or reachable tools, and the right to stay on the validated version for a set period.
Vulnerability notice. Notice of advisories affecting delivered components within a set time, with an exploitability statement (VEX) and a fix date.
AI incidents. An incident definition that includes model compromise, data poisoning, unauthorised model change and exposure of your data through outputs, with a notification window that fits inside your own regulatory clock.
Integrity. Models delivered signed, with the signing identity named, and build provenance available on request.
Data use. No training on your prompts, files, outputs or feedback without explicit opt-in.
Documentation support. The information and help you need for your own obligations. If you are the provider of a high-risk AI system, Article 25(4) of the EU AI Act requires a written agreement with suppliers of AI tools, services and components setting this out (free and open-source components are exempt, except general-purpose AI models).
Evidence on request. The right to see test reports, red-team summaries and attestations behind the AIBOM.

For the company-level questions (certifications, data processing, sub-processors, exit), use the AI Supplier Due-Diligence Questionnaire. When a vendor answers, the GRC team can file the answers as evidence: the AIBOM as compliance evidence shows which field supports which requirement. All guides by role are on the AIBOM Library hub.

Frequently asked questions

What should I ask an AI vendor before buying?

Ask for evidence, not assurances, in six areas: which exact model and version you get and what it is built from; what data trained and tested it; what runtime, tools and services it uses and how vulnerabilities are handled; how it was evaluated and what it must not be used for; whether the model and its documentation are signed and attested; and how much notice you get before any of that changes. A machine-readable AIBOM answers most of these in one file.

Should I require an AIBOM from AI vendors?

For any model you self-host, or any AI product that handles confidential data or makes decisions, yes: ask for a CycloneDX (1.6 or later) or SPDX 3.0 AIBOM at onboarding and with every release. For a hosted model API you will not get weight hashes, so ask for the model snapshot identifier, the model or system card, and written change notice instead.

What is a red flag in an AI vendor’s answers?

Answers that cannot be checked. “We always run the latest model”, “industry-standard datasets”, “no known vulnerabilities” with no version list, “the base model provider handles safety”, or an incident definition that only covers personal-data breaches. Each one means you cannot pin, scope or audit what you are buying.

What AI clauses should be in a vendor contract?

Commonly requested clauses cover AIBOM delivery with each release, advance notice of model, base-model, data or tool changes, vulnerability notices with an exploitability statement, an incident definition that includes model compromise and data poisoning, signed model delivery, no training on your data without opt-in, and documentation support for your own EU AI Act duties. Have your lawyer draft the wording.

Does the EU AI Act require vendors to share documentation?

In some cases. Providers of general-purpose AI models must give downstream providers the information listed in Annex XII (Article 53(1)(b)), unless the open-source exemption applies. Providers of high-risk AI systems must have a written agreement with suppliers of AI tools, services and components setting out the information and help they need (Article 25(4)), with an exemption for free and open-source components other than general-purpose AI models.

How is this different from an AI supplier questionnaire?

A supplier questionnaire covers the vendor as a company: governance, certifications, data handling, sub-processors and exit. These questions cover the model itself and ask for the AIBOM field that proves each answer. Use both: the questionnaire for the company, the AIBOM questions for each model you approve.

Sources

Checked on 29 October 2026. PlayCISO is not affiliated with any standards body, vendor or project named here. This is general information, not legal advice.

Turn these questions into an approval gate

Open the Intake Checklist