AI vendor due diligence questions should test whether a supplier can prove what its system does, what data it uses, where its limits sit, how risks are monitored, who is accountable after go-live, and what evidence the board can inspect before approval.
The board is not buying "AI". It is accepting a new source of operational, data, legal and reputational risk. As of 17 June 2026, the safest procurement position for UK boards is to ask for evidence that can sit in the board pack, not assurances that disappear after the demo.
Key takeaways
- Treat the AI supplier review as a board risk-control decision, not only a procurement scoring exercise.
- The first question is scope: what output or decision will the system influence, and who remains accountable inside your organisation?
- Evidence matters more than confidence language: request data-flow maps, DPIA material, test results, security controls, human oversight design, incident routes and exit terms.
- Supplier answers should feed the same AI governance framework and risk register used for internal AI, not sit in a separate procurement folder.
- For personal-data use, the ICO expects organisations to show accountability, controller and processor analysis, and DPIA reasoning where risk is high.
- The next step is to turn the supplier answers into risks, controls and owners before contract signature, not after implementation.
Who this applies to
This guide is for chairs, audit and risk committees, company secretaries, procurement leads, DPOs, CIOs and executives who are asked to approve an AI-enabled supplier. It applies whether the supplier sells a standalone AI system, embeds AI inside a wider SaaS product, or uses AI while delivering an outsourced service.
Use this guide for the supplier evidence pack. Use the AI procurement checklist for the wider purchase process, including business case, data screening, contract controls and post-go-live monitoring.
It is not limited to public sector procurement. GOV.UK's Guidelines for AI procurement were written for government buyers, but the disciplines are useful to any board: define the AI-specific criteria, test supplier claims, plan governance and auditability, and agree how the model will be monitored during the contract. The Cabinet Office's PPN 017 makes the same procurement point in a tender context: AI use in bids is not prohibited, but buyers may need proportionate due diligence, clarification questions and supporting evidence where AI increases risk.
For listed companies, the FRC's UK Corporate Governance Code 2024 frames why this belongs with the board. Provision 29 expects monitoring and review of risk management and internal controls, with evidence behind any declaration on material controls. AI supplier approval should therefore produce a control record the board can inspect later.
AI vendor due diligence questions for board approval
Before approval, ask these questions in this order. They move from purpose to data, then from evidence to contract control.
- What decision, recommendation or output will the system affect? Name the process, the people affected, the owner inside the organisation and whether the AI output is advisory, determinative or public-facing.
- What data will the supplier process? Separate personal data, special-category data, confidential material, customer records, staff records, board papers and public data. Ask where data is stored, who can access it, whether prompts or outputs are retained, and whether your data trains supplier models. If personal data is involved, screen whether a DPIA for AI is required before approval.
- What is the controller, processor or joint-controller position? The ICO's AI accountability guidance says senior management and DPOs remain accountable for AI governance, and that outsourced AI may require careful controller, processor and DPIA analysis.
- What evidence proves performance in our context? A generic benchmark is not enough. Ask for validation data, test conditions, known limitations, bias and accuracy results, failure cases, and how performance will be monitored after use begins.
- What security controls sit around the model and its supply chain? The NCSC's secure AI system development guidelines cover design, development, deployment, operation, supply-chain security, logging, monitoring and update management. The supplier should be able to show which of those controls apply.
- How is human oversight designed? Ask who can override the system, what they see, how escalation works, and whether the user can understand the output well enough to challenge it.
- What happens when the model changes, fails or exits? Require update notices, incident routes, audit rights, data-return and deletion terms, transition support and a record of what has changed.
These questions should also catch shadow procurement. If teams are already using AI features inside approved tools, the supplier review should be linked to your shadow AI policy, your acceptable-use rules and your wider AI policy, not treated as a new-contract-only exercise.
What evidence should the supplier provide?
A useful supplier answer gives you an artefact, not a paragraph. The board paper should summarise those artefacts and identify gaps before signature.
| Board question | Evidence to request | Verification owner |
|---|---|---|
| What AI is being used? | Product architecture note, AI feature list, model provider names, intended purpose and limits | Procurement with CIO |
| What data is processed? | Data-flow map, retention schedule, processor terms, sub-processor list and training-data position | DPO with legal |
| Is the use lawful and proportionate? | DPIA or documented rationale for why one is not required, including data subjects affected and safeguards | DPO |
| How accurate is it in our context? | Test results, validation set description, known error modes, monitoring plan and re-test trigger | Risk owner with technical lead |
| How are bias and fairness checked? | Cohort testing where people are affected, limitations, mitigation plan and review cadence | Risk owner with DPO |
| How is it secured? | Security architecture, access controls, logging, vulnerability management, incident route and supplier assurance | CISO or IT lead |
| How does oversight work? | User instructions, override route, escalation log, training plan and record of accountable owner | Executive sponsor |
| What if we leave? | Exit plan, data deletion certificate, export format, transition support and post-contract obligations | Procurement with legal |
The exact evidence changes with the use case. A meeting-summary tool will not need the same review as a supplier that triages complaints, recruitment or credit decisions. The board-level test is constant: if the supplier's answer cannot be converted into a named control, owner and evidence record, the board cannot monitor it.
How the questions map to the main frameworks
The supplier checklist should not invent a new governance language. Map the answers to the frameworks the board already needs to recognise.
| Framework or regulator | What it asks you to prove in supplier review |
|---|---|
| FRC UK Corporate Governance Code 2024 | The AI supplier risk is inside the risk management and internal-controls framework, with evidence for board monitoring and review. |
| ICO AI and data protection guidance | The organisation has assessed accountability, controller and processor roles, DPIA triggers, human involvement and residual risk where personal data is involved. |
| NCSC secure AI guidelines | The supplier can evidence secure design, secure development, secure deployment, secure operation, supply-chain control, logging and monitoring. |
| NIST AI RMF | The use case has been governed, mapped, measured and managed, with attention to trustworthiness characteristics such as validity, safety, security, transparency, privacy and fairness. |
| ISO/IEC 42001 | The supplier decision fits an AI management system: policy, objectives, processes, risk treatment, documentation, performance evaluation and continual improvement. |
| EU AI Act Article 13 | Where EU high-risk AI exposure exists, the provider's instructions must let deployers understand intended purpose, performance limits, accuracy, cybersecurity, risks, human oversight and logging. |
| FCA outsourcing and third-party guidance | For regulated financial services firms, AI in cloud or third-party IT services should be treated through the firm's outsourcing and operational resilience controls. |
The NIST AI Risk Management Framework is voluntary, but it gives procurement a practical sequence: govern the decision, map the context, measure the risk, manage what remains. BSI's ISO/IEC 42001 guidance describes the management-system frame for organisations that want policies, objectives and processes to be maintained over time rather than reviewed once. The EU's AI Act Article 13 text is more specific for high-risk systems: the provider's instructions must include information that lets deployers interpret and use the system properly, including intended purpose, accuracy, limitations, human oversight and logging.
Common mistakes in supplier review
Accepting the demo as evidence. A demo shows what the supplier chose to show. It does not prove performance on your data, with your users, under your controls.
Reviewing the product but not the use case. The same supplier can be low risk for drafting internal notes and high risk for making recommendations about tenants, staff, borrowers or beneficiaries. Classify the use, not just the product.
Letting procurement own the whole answer. Procurement can manage the process, but the risk owner, DPO, IT security lead and executive sponsor must each own part of the evidence. A supplier response with no internal owner is not a control.
Missing embedded AI. Many tools now add AI features inside products the organisation already bought. The due diligence trigger should be "new AI function or changed use", not only "new supplier".
Leaving assurance until renewal. GOV.UK procurement guidance asks buyers to consider ongoing management, model testing, knowledge transfer and end-of-life arrangements. Those terms belong in the contract before the system is live.
Keeping the answers outside the risk register. If the supplier handles personal data, influences a decision or changes a control, the answer belongs in the same living register as internal AI use. Otherwise the board has a procurement file, not governance evidence.
These mistakes connect directly to the broader board agenda in the questions every UK board should ask about AI: what systems are in use, who owns them, what data they touch, how they are tested, and what evidence the board receives.
Next step
Start with one supplier on the next approval agenda. Put the answers into the AI Risk Register Generator, then assign each risk to a named control owner before the contract is signed. If the board does not yet have a baseline for policy, data, risk, capability and accountability, take the Board AI Scorecard first. If the supplier is already live or touches a high-risk process, commission an AI governance diagnostic so the evidence set is mapped before renewal or expansion.
The board does not need to know every model parameter. It does need to know what it approved, what evidence supported that approval, who owns the residual risk and when the answer will be checked again.
Last reviewed: 17 June 2026.
Sources: GOV.UK Guidelines for AI procurement · GOV.UK PPN 017 · ICO AI accountability and governance · NCSC secure AI system development · FRC UK Corporate Governance Code 2024 · NIST AI Risk Management Framework · BSI ISO 42001 AI Management System · AI Act Service Desk Article 13 · FCA FG16/5 · Governance AI Risk Register Generator.
