How to choose · AI risk and governance

How to assess an AI vendor during due diligence

Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes

Short answer

Assess an AI vendor on data handling, security assurance, model and subprocessor transparency, contractual protections, testing and monitoring support, and operational resilience. Request evidence rather than assertions: independent attestations, data flow diagrams, retention terms and incident commitments. Tailor depth to the risk of the use case, and revisit when features or subprocessors change.

Who this is for: A procurement, security or legal reviewer who must approve an AI product or service that will process company or customer data.

What to evaluate

Data flows and retention
You must know where inputs, outputs and logs travel and how long they persist.
How to check: Obtain a data flow description, retention schedule and deletion process in writing.
Training and secondary use
Use of your content to improve models changes confidentiality exposure.
How to check: Confirm contractual language on training, evaluation and any human review.
Security assurance
Independent evidence is stronger than questionnaires alone.
How to check: Request recognised security attestations and penetration test summaries, and check scope matches the service you are buying.
Subprocessors and model providers
Many AI products rely on third-party models and infrastructure.
How to check: Ask for the list of subprocessors, locations and the notice process for changes.
Transparency about the system
Reviewers need to understand capabilities, limitations and intended use.
How to check: Request documentation on intended use, known limitations, testing performed and update practices.
Contract protections
Liability, indemnity and exit terms shape real risk transfer.
How to check: Review confidentiality, liability limits, intellectual property indemnity, audit rights and termination assistance with legal counsel.
Resilience and change management
Silent model or feature changes can alter behaviour in production.
How to check: Ask how changes are announced, whether versions can be pinned and what service commitments exist.

Comparison

Diligence depth by use-case risk
Use-case risk	Example	Diligence depth
Low	Drafting public marketing text	Standard security questionnaire, review of terms
Moderate	Summarising internal documents	Data flow review, attestations, subprocessor check
High	Handling personal or confidential customer records	Full review, contractual data processing terms, testing evidence, legal sign-off
Consequential decisions about people	Screening, eligibility, assessment	Impact assessment, bias and accuracy testing, oversight design, regulator guidance review

Decision worksheet

Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.

1. Have you checked each criterion?

Data flows and retention — Obtain a data flow description, retention schedule and deletion process in writing.
Training and secondary use — Confirm contractual language on training, evaluation and any human review.
Security assurance — Request recognised security attestations and penetration test summaries, and check scope matches the service you are buying.
Subprocessors and model providers — Ask for the list of subprocessors, locations and the notice process for changes.
Transparency about the system — Request documentation on intended use, known limitations, testing performed and update practices.
Contract protections — Review confidentiality, liability limits, intellectual property indemnity, audit rights and termination assistance with legal counsel.
Resilience and change management — Ask how changes are announced, whether versions can be pinned and what service commitments exist.

0 of 7 criteria checked.

2. Compare options (0 = fails or unknown, 3 = meets it well)

Criterion	Option 1 name	Option 2 name	Option 3 name
Data flows and retention	Data flows and retention score for Option A	Data flows and retention score for Option B	Data flows and retention score for Option C
Training and secondary use	Training and secondary use score for Option A	Training and secondary use score for Option B	Training and secondary use score for Option C
Security assurance	Security assurance score for Option A	Security assurance score for Option B	Security assurance score for Option C
Subprocessors and model providers	Subprocessors and model providers score for Option A	Subprocessors and model providers score for Option B	Subprocessors and model providers score for Option C
Transparency about the system	Transparency about the system score for Option A	Transparency about the system score for Option B	Transparency about the system score for Option C
Contract protections	Contract protections score for Option A	Contract protections score for Option B	Contract protections score for Option C
Resilience and change management	Resilience and change management score for Option A	Resilience and change management score for Option B	Resilience and change management score for Option C
Total (max 21)	0	0	0

Questions to ask before you commit

Where are our data and logs processed and stored, and can we select regions?
Is our content used for training or evaluation in any form?
Which independent assurance reports can you share and what is their scope?
Who are your subprocessors and how will we be told of changes?
What testing have you done for accuracy, bias and misuse relevant to our use?
How are model and feature changes communicated and can we pin versions?
What are your incident notification timelines and obligations?
What happens to our data and outputs on termination?

Typical trade-offs

Lengthy questionnaires versus evidence-based review

Upside: Questionnaires are easy to standardise.
Downside: They capture assertions; attestations and testing evidence give stronger assurance.

Approving established vendors quickly versus equal scrutiny for all

Upside: Saves effort.
Downside: Familiar names can hide changed terms and new features.

Strict contract demands versus speed to adopt

Upside: Better protection.
Downside: Slows adoption and may push users to unsanctioned tools.

Common mistakes

Accepting marketing statements as evidence. Ask for documents and contract language.
Reviewing the product once. Reassess when features, models or subprocessors change.
Forgetting embedded AI features in existing tools. Include them in the inventory and reviews.
Leaving legal out until signature. Involve counsel early.

Sources and further reading

These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.

AI Risk Management Framework — National Institute of Standards and Technology, retrieved 27 October 2026
10 Steps to Cyber Security — National Cyber Security Centre, retrieved 27 October 2026

Comparison · AI risk and governance

Comparing AI governance frameworks: risk framework, management standard and regulation

These instruments do different jobs. A risk management framework offers guidance on identifying and managing risk; a management system standard describes the organisational processes that can be audited and certified; regulation creates legal duties with penalties and applies by jurisdiction. Most organisations use a framework to design practice, a standard to structure it and legal advice to meet obligations.

Problems & fixes · AI risk and governance

Shadow AI: staff using unapproved tools and what to do about it

Shadow AI arises when approved options are slow, limited or unknown. Prohibition alone seldom works. Combine discovery, a clear policy with examples, an approved alternative that meets real needs, a quick exception route, technical guardrails on sensitive data and training that explains reasons. Treat discovery as information about unmet needs rather than only a disciplinary matter.

Requirements · AI risk and governance

Requirements for using AI in decisions about people

Tools that influence decisions about people face the strictest expectations. Typical requirements include a defined lawful purpose, documented impact assessment, testing for discriminatory effects, transparency to affected people, meaningful human oversight with authority to override, routes to contest outcomes, record keeping, and vendor evidence. Laws differ by jurisdiction, so obtain legal advice and consult regulator guidance before use.

Requirements · Workflow automation

Security and governance requirements for workflow automation

Treat the platform as a privileged system. Require single sign-on and role separation, scoped service connections instead of personal logins, secret storage you can audit, restrictions on which data may flow through it, run-log retention limits, change review for important flows, and an inventory with named owners. Without these, automations become unmanaged paths around your normal controls.

How to choose · B2B software

How to run a security review of a SaaS vendor

Scale the review to the data and access the vendor will have. Collect independent assurance reports, a completed security questionnaire and documentation on encryption, access control, incident response and subprocessors, then verify claims rather than accepting them. Focus on what the vendor does with your data, how it detects and reports incidents, and how you can exit with your data intact.

Requirements · B2B software

SaaS contract terms to review and negotiate

Beyond price, the clauses that most affect outcomes are renewal and termination mechanics, data ownership and return, service levels and remedies, liability caps, security and breach commitments, and rules on price changes. Contract law varies by jurisdiction, so treat this as a checklist for conversation with counsel, not legal advice. Negotiate before signature, because leverage drops once data is in the system.

Problems & fixes · B2B software

Why software implementations fail or run late and how to prevent it

Implementations falter less from technology than from unclear scope, poor data, weak ownership and underestimated change effort. Prevent trouble by defining outcomes and boundaries up front, cleaning data before migration, naming a business owner with decision authority, and planning training and adoption as seriously as configuration. When a project slips, reset scope and sequence rather than adding pressure.

All AI risk and governance guides · All Artificial intelligence