The short answer. AI vendor due diligence is the structured pre-procurement review of an AI vendor — covering data handling, security baseline, regulatory alignment, contract terms, and exit options. For UK businesses it sits inside the existing third-party risk management framework, with AI-specific extensions covering training data, model lifecycle, and sub-processor disclosure.
The 10-item AI vendor due diligence checklist
1. Data processing agreement. A signable DPA covering UK GDPR — controller/processor split, instructions, sub-processor disclosure, return-or-deletion on exit. The standard third-party requirement; AI vendors are not exempt.
2. Sub-processor disclosure. The list of every onward processor the vendor uses, including the AI model provider if separate. Most AI vendors are at least two layers deep — the vendor, the model provider, and often a hosting provider underneath that.
3. Data residency. Where customer data is processed and stored. UK or EEA preference for most regulated UK businesses; explicit clauses for any non-EEA processing, with the transfer mechanism documented.
4. Training data treatment. Whether customer-submitted data is used to train models — at the base-model level, at any fine-tuned level, or for "improvement" purposes. The contractual answer should be explicit. Enterprise tiers typically say no; consumer tiers typically say yes.
5. Audit logging. Whether the vendor exposes audit logs to the customer — who used what, when, what data was accessed, what was output. Retention period, format, and export mechanism. Increasingly an audit expectation.
6. Security evidence. SOC 2 Type II, ISO 27001, Cyber Essentials Plus, or equivalent third-party assurance. Currency (last 12 months), scope (covers the relevant product), and findings (clean or with remediated material findings).
7. Vulnerability and incident disclosure. The vendor's process for disclosing vulnerabilities and security incidents — notification timeline, content, remediation expectations. Increasingly mirrors the GDPR personal-data-breach 72-hour standard.
8. Right to audit. The contractual right for the customer (or an appointed assessor) to audit the vendor's controls. Most enterprise vendors accept this with conditions; consumer-tier products typically do not.
9. Exit and portability. What happens to customer data on exit — return mechanism, deletion confirmation, retention period for backups. For some AI tools, "exit" also includes withdrawal of model-improvement contributions where consent was given.
10. Insurance. The vendor's cyber liability cover, AI-specific cover where it exists, and the contractual cap on liability. For larger UK businesses, the cap drives where residual risk sits.
UK regulatory alignment
The 10 items map cleanly to existing UK regulator expectations on third-party risk. For financial services, SS2/21 on outsourcing and PS21/3 on operational resilience cover most of the territory; AI extends rather than replaces them. For ICO purposes, the DPA, sub-processor disclosure, and incident processes are the principal artefacts. For sector-specific work (legal SRA, healthcare CQC), the regulator's third-party expectations apply with AI-specific overlays.
Red flags during AI vendor due diligence
Recurring patterns that should at least pause procurement:
- Inability to name sub-processors. "We use cloud infrastructure" is not a sub-processor disclosure. Material AI vendors can name every layer.
- Vague training data position. "We may use data to improve our services" is not a contractual answer. The answer should be specific: yes / no / with consent / opt-out / never.
- No exportable audit log. The vendor can show audit logs in their UI but cannot export them for the customer's records.
- Generic security evidence. A SOC 2 report that does not cover the product being procured. A Cyber Essentials self-assessment used as third-party assurance.
- Liability cap below the data-breach floor. Caps that look standard for a £50/month tool but are insufficient for the value of data the tool will process.
How vendor due diligence relates to AI readiness
AI vendor due diligence is part of the governance dimension of AI readiness — specifically the approval workflow that decides whether a new tool gets added to the approved tools register. A business with an immature governance dimension typically does not run due diligence; tools are procured on the strength of the sales conversation and added retrospectively. A business with mature governance runs due diligence pre-procurement as standard.
The Arx Certa scorecard checks whether vendor due diligence is part of the approval workflow. The free AI Governance Checklist PDF is the printable companion.
Frequently asked
How long does AI vendor due diligence take?
Two to four weeks for a mid-market UK business once the framework is in place. The vendor responses themselves take one to two weeks; the analysis and decision a week after that. The first vendor in a new framework takes longer (typically six weeks); subsequent vendors slot in faster.
Is AI vendor due diligence different from standard third-party risk management?
It extends rather than replaces. The 10 items above include the standard third-party items (DPA, security evidence, exit) plus AI-specific extensions (training data treatment, sub-processor depth covering the model provider, audit log expectations on AI interactions specifically). Most UK businesses run AI as a heavier flavour of existing TPRM, not a separate process.
Do small businesses need to run formal vendor due diligence?
Yes, but proportionate. A 10-person business does not run a six-week formal review for every AI tool. It does run a 90-minute review of the DPA, sub-processors, training-data position, and exit terms before signing. The components scale; the principle is the same.
What if the AI vendor refuses to engage with due diligence?
It is a signal worth listening to. Enterprise-tier AI vendors expect and welcome due diligence; consumer-tier vendors typically deflect it. A vendor that refuses to engage on the items above is signalling that the controls and contracts are not where they need to be for regulated use.
How does AI vendor due diligence change when the AI is embedded in another product?
When AI capability reaches the business as a feature of an existing vendor's product (Copilot inside Microsoft 365, AI features inside the CRM), the existing vendor relationship becomes the due-diligence path — but with AI-specific questions added to the standing review. The principal-vendor's contract should now address the AI features explicitly; if it does not, that is the artefact to ask for.
Related Arx Certa services
If the gaps the scorecard surfaces need outside help to close, these are the engagement types we run for UK firms:
- AI services — implementation reviews, AI policy work, vendor due diligence, and pilot scoping.
- Cybersecurity — UK GDPR, NCSC alignment, vendor risk assessment, audit-readiness.
- Database — the data foundations AI projects depend on.
- Infrastructure — cloud, identity, network and integration foundations.
See how your vendor due diligence scores against the rest of the readiness picture
The Arx Certa AI Readiness Scorecard takes 4 minutes and surfaces the governance and vendor-management gaps that determine whether AI procurement is safe or expensive.
Get your AI readiness score →