An AI procurement checklist should decide whether the proposed system is lawful, useful, secure and governable before contract award. For boards, the test is not whether a supplier sounds credible; it is whether evidence, controls, owners and exit rights are contractually visible.
AI risk can enter through ordinary buying decisions: a case management system with an embedded summariser, a customer contact product with sentiment analysis, a recruitment platform with scoring, or a meeting tool that records and transcribes board papers. Procurement is therefore not an administrative stage after governance. It is one of the first controls in the AI governance framework, alongside policy, risk appetite and the live risk register.
Key takeaways
- The board should approve the use case and the risk appetite before procurement asks suppliers for a solution.
- Supplier claims are not evidence. Require model cards, data-use terms, test results, security responses, human oversight design and incident procedures.
- AI features in non-AI products still need disclosure. The UK Government's 2025 PPN 017 asks suppliers to declare AI use in tender creation and service delivery.
- UK GDPR, security, equality, sector duties and EU exposure should be checked before award, not pushed into implementation.
- The last procurement gate is operational: add the system to the AI risk register, assign an owner, set review dates and define exit rights before signature.
Who this applies to, and what the board decides
This applies to any UK board buying, renewing or materially changing a system that generates content, predicts outcomes, recommends decisions, profiles people, ranks cases, automates workflow or embeds third-party AI into an existing product. It includes explicit AI products and ordinary SaaS where the supplier has added AI features after the last renewal. That second category is easy to miss, which is why the companion article on shadow AI policy treats supplier-enabled AI as part of the same governance problem.
The board does not need to approve every prompt tool. It does need to decide the threshold for board or committee approval. A practical threshold is: any AI system that touches personal data, affects customers or service users, informs eligibility or pricing, creates external-facing content at volume, or changes a regulated control should come to the board, audit committee, risk committee or a delegated AI governance group before contract award.
The board decision frame is short:
- What decision or workflow will this system affect, and why is AI needed rather than a simpler rule, workflow or search tool?
- Which policy permits the use case, and which uses remain prohibited under the AI policy and acceptable-use rules?
- Who owns the system after procurement, including exceptions, drift, supplier changes and exit?
- What evidence proves the supplier's claims about data, security, performance, fairness, human oversight and incident handling?
- What will the board see in the next quarterly report: adoption, incidents, control failures, user complaints, model changes and unresolved supplier issues?
AI procurement checklist for the board
Use this as a pre-award gate, not a paperwork exercise after the contract has been negotiated.
| Gate | Board question | Minimum answer before award |
|---|---|---|
| Use case | What problem are we solving, and why is AI the right tool? | A named workflow, a measurable outcome, a non-AI alternative considered and a clear reason for using AI |
| Classification | Is this low, medium or high risk for people, money, safety, compliance or reputation? | A recorded risk band mapped to approval level, data type, affected people and sector duties |
| Data | What data enters the system, where is it processed, and is it used for training? | Data flow, lawful basis where personal data is involved, processor terms, retention, location and written training-data restrictions |
| Supplier AI use | Did the supplier use AI to prepare the tender or deliver the service? | A declaration, any limitations of generated tender content, and due diligence where AI affects delivery capacity or evidence |
| Human oversight | Who can accept, reject, override or stop the output? | Named role, training, thresholds, exception route and audit trail |
| Performance | How has the system been tested in conditions close to our deployment setting? | Test data description, limitations, failure modes, accuracy or quality metrics, bias assessment and monitoring plan |
| Security | How does the service meet our security needs? | Cloud security evidence, access model, logging, encryption, incident process, vulnerability handling and supplier chain visibility |
| Contract and exit | Can we leave, audit, challenge changes and retain our records? | Audit rights, change notification, portability, deletion, continuity, liability, IP and successor-supplier terms |
The GOV.UK AI Playbook, published on 10 February 2025, gives public sector teams a useful benchmark even when the buyer is private or third sector. It says teams should use the right tool for the job, involve commercial colleagues early and specify data strategy, bias, limitations, supplier AI approach, lock-in, support, hidden costs, IP and risk appetite when buying AI. Those items translate cleanly into board evidence.
Evidence to require before award
Supplier due diligence should produce artefacts the organisation can keep, not just answers in a presentation. Use the supplier due-diligence questions for the evidence pack, then feed the answers into the living AI risk register.
| Control | Evidence to request | Owner before signature |
|---|---|---|
| Lawful and fair processing | DPIA or screening note, lawful basis, processor terms, data minimisation, retention and subject-rights handling | Data protection officer or privacy lead |
| Supplier disclosure | AI use declaration for tender creation and service delivery, including whether client data trains models | Procurement lead with legal support |
| Security assurance | NCSC cloud security response or equivalent, penetration test summary, access model, audit logs and incident notification terms | CISO or IT security lead |
| Human oversight | Workflow showing where human judgement enters, who can override, how outputs are labelled and how exceptions are logged | Business owner |
| Performance and bias | Test report, deployment assumptions, known limitations, subgroup analysis where relevant and monitoring schedule | Product, data or operations lead |
| Contract resilience | Change-control rights, model-update notice, audit rights, exit plan, data export, deletion certificate and liability allocation | Legal and procurement |
| Board reporting | Register entry, risk owner, review date, key metrics, incident trigger and escalation route | Executive sponsor |
The Cabinet Office's PPN 017, updated in February 2025, is directed at central government departments, executive agencies and non-departmental public bodies, but its logic is useful beyond government. It asks buyers to understand supplier AI use, require disclosure where AI is used in tender creation or service delivery, prevent confidential buyer information being used as training data without written approval, and apply proportionate due diligence when AI creates uncertainty in a tender.
For personal data, the ICO's AI and data protection risk toolkit is the procurement prompt: identify risks to rights and freedoms before the supplier is embedded in the workflow. A board should be wary of any supplier answer that treats privacy as a post-signature configuration task.
Framework mapping
Procurement should not create a separate governance language. Map the supplier pack to the frameworks the board already uses.
| Framework or source | What it means for procurement |
|---|---|
| GOV.UK guidelines for AI procurement | Treat AI buying as a distinct procurement challenge, with evaluation of suppliers and responsible procurement built in from planning. |
| NIST AI RMF Core | Use Govern, Map, Measure and Manage to structure the supplier pack: accountability, context, metrics and controls. NIST also warns that its actions are not an ordered checklist, so adapt them to the use case. |
| ISO/IEC 42001 | Procurement evidence should support an AI management system: policies, objectives, risk treatment, traceability, transparency, reliability and continual improvement. |
| NCSC cloud security principles | Analyse the cloud or SaaS service and the company that runs it; ask what evidence gives enough confidence in the provider's claims. |
| EU AI Act | For EU-facing systems, check whether the supplier is a provider, importer or distributor, whether the buyer becomes a deployer, and whether transparency or high-risk duties apply. Article 113 says the Regulation applies from 2 August 2026, with earlier dates for some chapters. |
This mapping also prevents overbuying. If the NIST Map stage cannot define the context, users and foreseeable misuse, the procurement is not ready. If ISO 42001-style ownership and review cannot be named, the system may be useful but not governable. If the NCSC evidence is too thin, the board has not bought a secure AI service; it has bought a trust claim.
Common mistakes and next step
The first mistake is starting with supplier demos. A demo tells you what the product can appear to do on the vendor's data. It does not tell you how it behaves on your data, under your controls, with your users, under your regulator.
The second is treating procurement as a substitute for policy. A supplier cannot decide which uses your organisation permits, what human oversight means in your sector, or where your risk appetite stops. Those choices belong in policy and board minutes. If the policy itself is thin, start with the generative AI policy template guide. See the questions every UK board should ask about AI before treating the buying process as the first governance conversation.
The third is accepting "no training on your data" without contract wording. The phrase must survive legal review: which data, which models, which affiliates, which subcontractors, which logs, which support tickets, which retention periods, and what audit or deletion evidence follows termination.
The fourth is forgetting renewal. Many AI features arrive through product updates inside existing contracts. Every renewal should ask whether AI features were added, whether default settings changed, whether new sub-processors appeared, and whether the risk register still reflects the live system.
Next step. Before signing or renewing, put the proposed system into the AI Risk Register Generator and create a named row for the use case, supplier, owner, evidence and review cadence. If the board wants a wider maturity view first, use the Board AI Scorecard. If the procurement affects personal data, regulated decisions or public trust, commission the AI governance diagnostic before the contract is locked.
Sources
- GOV.UK, Artificial Intelligence Playbook for the UK Government
- GOV.UK, Guidelines for AI procurement
- GOV.UK, PPN 017: Improving transparency of AI use in procurement
- ICO, AI and data protection risk toolkit
- NIST AI Resource Center, AI RMF Core
- ISO, ISO/IEC 42001:2023 AI management systems
- NCSC, The cloud security principles
- EUR-Lex, Regulation (EU) 2024/1689 Artificial Intelligence Act
- Governance AI, AI Risk Register Generator
