AI Vendor Due Diligence Checklist for UK Businesses

Overview

AI procurement can look straightforward when a tool promises faster research, better customer support or more efficient content operations. The risk is that a seemingly simple feature may involve personal data, confidential business information, automated decisions, third-party subprocessors or a new dependency in a critical workflow.

A proportionate review should match the vendor and use case. A public text summariser handling non-sensitive material needs a different level of scrutiny from an LLM integrated with customer records, employee information or production systems. Before approving a supplier, document:

• What the tool will do and which business process it supports.
• What information will be submitted, generated, stored or exported.
• Who controls the purpose and means of processing.
• Which supplier entities and subprocessors are involved.
• What happens when the service fails, changes terms or is discontinued.

Treat vendor due diligence as an evidence-gathering exercise, not a box-ticking exercise. Save the relevant contract, privacy documentation, security answers, technical limits and commercial assumptions with the approval record.

Checklist by scenario

1. Low-risk trial or public-information workflow

For an early experiment using non-confidential, non-personal information, confirm the basics before staff begin:

• Is the correct business account being used rather than an unmanaged personal account?
• Does the supplier use submitted content to improve or train models, and can that use be restricted?
• Can users delete prompts, files and outputs, or request account deletion?
• Are there usage limits, automatic renewals or material pricing assumptions?
• Can the trial be stopped without leaving data or integrations behind?

Set a written boundary for the trial: approved users, permitted data, prohibited data, retention expectations and the person responsible for reviewing the outcome.

2. Business workflow containing personal or confidential data

Increase scrutiny when the tool processes customer, employee, supplier or other identifiable information. Ask the vendor to clarify:

• Which party acts as controller, processor or another relevant role for each processing activity?
• What categories of data are accepted, and what uses are prohibited?
• Where is data processed and stored, and what transfer arrangements apply where relevant?
• How long are prompts, uploaded documents, logs, backups and outputs retained?
• Can the vendor support deletion, access, correction or other operational requests?
• Which subprocessors receive data, and how are changes communicated?
• What security controls protect accounts, data in transit, stored data and administrative access?

Ask your privacy or legal owner whether a data protection impact assessment, contract review or additional internal approval is appropriate. Do not assume that a vendor’s general privacy notice answers questions about your particular configuration.

3. LLM API, RAG or production integration

For LLM app development, retrieval-augmented generation and API-based automation, assess operational and technical dependencies as well as privacy:

• Are API inputs, outputs and diagnostic logs used for training or retained by default?
• What are the model, context, file, rate and concurrency limits?
• How are version changes, deprecations and breaking changes announced?
• Are availability targets, incident communication and support routes documented?
• Can prompts, retrieval sources, evaluations and outputs be tested against a stable version?
• Can you export configuration, data, indexes, logs and evaluation results?
• What is the realistic migration path if quality, cost, policy or availability changes?

Keep provider-specific assumptions separate from application logic. A documented fallback and migration plan is often more valuable than a broad promise of portability. See the LLM API Migration Checklist and production deployment checklist when reviewing an integration.

4. High-impact or sensitive use case

If outputs could influence access to employment, credit, services, safety, healthcare or other sensitive decisions, pause routine procurement. Involve the appropriate privacy, security, legal, risk and business owners. Define human review, escalation, auditability, accuracy thresholds and prohibited uses before a supplier is approved. A vendor’s capability does not remove your responsibility to govern the workflow.

Comparison table

What to double-check

Evidence-request template

Send a concise request rather than asking for “all compliance documents”. Request:

Please provide the current data-processing terms; processing locations; subprocessor list and change process; retention and deletion rules; model-training and input-use terms; security control summary; incident-notification process; availability and support commitments; data export format; account termination procedure; pricing, renewal and material-change terms; and the date each document was last updated.

Record whether each answer is documented, contractually binding, configurable, verbally explained or unanswered. Unanswered questions should remain visible in the risk decision.

Risk-rating worksheet

Score each area using a simple scale such as low, medium or high. Consider:

• Data sensitivity: public, internal, confidential or personal.
• Business impact: experimental, important or operationally critical.
• Vendor dependency: replaceable, difficult to replace or deeply embedded.
• Evidence quality: clear contractual evidence, partial evidence or unsupported assurance.
• Control strength: configurable safeguards, manual safeguards or no practical control.

For every medium or high rating, assign an owner, a mitigation, a due date and an approval decision. “Accepted” should mean that a named person understands the exposure, not that the issue has disappeared.

Common mistakes

• Relying on a marketing page: product claims may not describe the plan, region or configuration you will use.
• Confusing encryption with complete security: also examine identity controls, access reviews, logs, deletion, support access and incident handling.
• Ignoring subprocessors: the visible brand may not be the only organisation processing information.
• Approving the tool but not the workflow: prompts, plugins, browser extensions, exports and human review can introduce separate risks.
• Skipping output evaluation: privacy and security checks do not demonstrate that an AI system is accurate, reliable or fit for purpose. Use representative tests and documented acceptance criteria; the prompt evaluation framework can help structure them.
• Planning only for adoption: document how to pause, migrate, delete and communicate a service exit before production use.

When to revisit

Review the assessment before the tool moves from trial to production, before adding a new data category or user group, and before connecting it to a new system. Revisit it during renewal and before seasonal planning cycles when usage, volumes or business reliance may change.

Trigger an earlier review when the vendor changes its contract, privacy notice, model-training terms, subprocessors, pricing, API behaviour, retention settings, security documentation or service architecture. Also review after a security incident, material outage, unexpected output pattern or change in relevant UK regulatory expectations.

For a practical next step, create a one-page supplier record today. Name the use case and owner, list permitted data, attach the vendor evidence, complete the risk ratings, record open questions and set the next review date. If the tool passes, approve the exact configuration rather than the brand in general. If it does not pass, restrict the workflow, request better controls or choose an alternative. This keeps AI procurement proportionate, reviewable and ready to repeat when the business or supplier changes.