AI Vendor Risk Assessment: A Buyer’s Checklist

Search for an AI vendor security questionnaire and most of what you find was published by an AI vendor. That is not necessarily bad faith — vendors genuinely want procurement to go smoothly — but it does mean the questions are the ones they are comfortable answering. Encryption at rest is comfortable. "What happens to our data if you are acquired" is not.

This is written from the buyer's side. It is organised by how often each area causes an actual problem rather than by control family, and it flags the answers that should end the conversation.

Before you send anything: what are you buying?

Three questions decide which of the rest matter:

1. Does this system take part in a consequential decision? If it affects employment, credit, housing, benefits, enforcement or access to services, the depth of assessment goes up sharply — and statutory duties may attach.
2. Does the vendor build the model, or resell someone else's? This determines what they can tell you at all.
3. What data will touch it? Personal data, confidential business data, or neither.

A proportionate assessment for a meeting-notes summariser is not the same as for a system that scores applicants. Sending a 200-question form for the former is how procurement gets a reputation that makes people route around it.

1. Data — where most real problems live

Ask, and get the answers in the contract rather than in a sales email:

• Is our data used to train or improve your models? For us specifically, or across customers? Is there an opt-out, and is it the default?
• Does that commitment extend to the upstream model provider? A reseller can honestly say they do not train on your data while the developer behind them does.
• Who owns the outputs? And any fine-tunes, embeddings or indexes derived from our data?
• How long is data retained, including prompts and logs? Retention for abuse monitoring is common and frequently undisclosed.
• What is deleted at termination, on what timescale, and how is deletion evidenced?
• Who are the sub-processors, and how are we told when they change?
• Where is data processed? Relevant if you have residency obligations.

Answers that should stop you: "we do not train on customer data" offered verbally but not contractually; an inability to say what the upstream developer does; or no defined deletion process at termination.

2. Evidence — not benchmarks

The shift worth internalising: buyers increasingly want evidence rather than assurance. US federal procurement now provides for performance validation and pre-award testing for high-impact AI, and enterprise and insurer expectations are converging on the same thing.

• Can you demonstrate performance on our task, with our data, before award? A vendor confident in their product will want to.
• What are the known failure modes? A vendor who says there are none has either not looked or will not say.
• How was the system evaluated for disparate performance across groups? If it touches a consequential decision, this is not optional — existing anti-discrimination law applies to the decision regardless of what produced it.
• What is the error rate, and what does a wrong answer look like? A confidently wrong output is a different operational problem from a refusal.
• What documentation comes with the system? Colorado's replacement act, for example, puts a technical-documentation duty on developers precisely because deployers cannot explain what they were never told.

Answers that should stop you: refusal to test on your data; benchmark figures offered in place of task performance; "the model handles that" as a response to a failure-mode question.

3. The supply chain your vendor does not control

This is the question most assessments miss entirely, and it is increasingly the one procurement turns on.

Many vendors are resellers, integrators or platform operators sitting between you and a model developer. US federal AI acquisition guidance explicitly recognises that the information available varies with position in the software supply chain, with more generally available closer to the original developer.

• Whose model is underneath, and can you tell us if it changes?
• What can you pass through from the developer — documentation, evaluations, incident notifications?
• What happens to us if your upstream relationship ends or its terms change?
• Can you make commitments the developer has not made to you? If not, some of your contract is aspiration.

4. Change — the risk that arrives after signature

Traditional software changes on a release schedule you can see. Models can change underneath you.

• How will we know the model has been updated?
• Can we pin a version, and for how long?
• What notice do we get before a deprecation?
• Does an update invalidate the validation we did at procurement? If behaviour can shift materially, your pre-deployment testing has a shelf life and needs a re-test trigger.

5. Agents, if the product acts rather than answers

If the system can take actions — send messages, call APIs, move data, spend money — the assessment changes character. Joint guidance from CISA, the NSA, Australia's ACSC and international partners in April 2026 points at the same controls:

• Can the agent hold its own identity and credentials, rather than borrowing a user's or sharing a key?
• Can we scope its permissions outside the product, in the systems it calls, rather than by prompt configuration?
• Which actions require human confirmation, and can we change that list?
• What is logged — the actions only, or also the content the agent saw? Without the latter, an indirect prompt injection is close to undiagnosable. See prompt injection.

6. Contract terms worth insisting on

• Data commitments in the contract, not the FAQ or the trust centre. Marketing pages change without notice.
• Notification of material model change.
• Audit or evidence rights proportionate to impact.
• Incident notification with a defined timescale, covering AI-specific failures and not only security breaches.
• Indemnities — and read what is excluded. Output-related indemnities frequently carve out exactly the scenarios that worry you.
• Exit terms: export format, timescale, what you keep, and what happens to derived artefacts.

7. The exit, planned before the entrance

Ask before you sign, because the answer is never better later:

• What can we export, in what format, and how long does it take?
• Do we keep fine-tunes, embeddings or indexes built from our data?
• What is deleted, when, and how is that evidenced?
• Could we run this on a different model without rebuilding the integration?

Proportionality, so this gets used

A three-tier approach keeps procurement usable:

A questionnaire that treats every purchase as high tier trains the organisation to route around procurement, which is worse for risk than a proportionate process people actually use.

For where this sits in a wider programme, see AI governance. If you are selling rather than buying, selling AI to the federal government covers the same ground from the other side.

Nothing here is legal advice, and contract terms should be reviewed by counsel.