Before the Next AI Licence Is Signed: A Board Assurance Checklist
Photo: UK boardroom directors reviewing documents around table formal meeting, via s3.amazonaws.com
Artificial intelligence has moved from pilot project to line-item budget. By 2026, many UK boards are no longer deciding whether to experiment with AI; they are deciding whether to renew, expand or replace tools that staff already use. That shift changes the nature of the decision. A licence renewal is not simply an IT purchase. It is a governance choice about data, accountability, operational resilience and the credibility of the board’s oversight.
The difficulty is that renewal papers often arrive late, framed around features and discounts rather than assurance. Directors can find themselves asked to approve a three-year commitment after a short demonstration and a commercial summary. The following seven questions are designed to slow that process down just enough to make it sound.
Start with the decision, not the demonstration
Before the board reviews functionality, it should establish what decision it is actually being asked to make. Is this a renewal of an existing tool, an expansion into new teams, a move to a different pricing tier, or a replacement of several systems? Each carries a different risk profile. A short board minute should record the purpose, the accountable executive, the total cost and the review date. If those four elements are absent, the proposal is not yet ready for approval.
1. Where will the data sit, and who can reach it?
Data residency is not a technical footnote. Directors should ask where company and customer data will be stored, which sub-processors are involved, and whether any support or model-training activity takes place outside the UK. If data leaves the UK, the board should see the transfer mechanism and the contractual controls that apply. For regulated firms and organisations handling personal data, the question should extend to retention periods, deletion rights and whether the vendor uses customer data to improve its own models. A clear answer should be available in writing, not only in a sales conversation.
2. What remains a human decision?
The most important governance question is often the simplest: where does the tool stop and human accountability begin? Directors should ask which outputs are advisory and which are treated as authoritative, who reviews them, and what happens when an error reaches a customer, regulator or supplier. Liability should be examined in the contract, but also in practice. Does the vendor offer indemnities, and are they meaningful? Does the company’s insurance respond if an AI-generated output causes loss? Can the organisation reconstruct why a decision was made? If the answer depends on an individual’s memory, the control is weak.
3. What would it cost to leave?
Vendor lock-in rarely appears as a single clause. It accumulates through proprietary formats, integration work, staff habits and data that cannot be easily exported. Boards should ask for an exit plan before renewal, not after a dispute. What data can be extracted, in what format, and at what cost? How long would migration take? Which internal processes would need to be rebuilt? A vendor that cannot describe a practical exit route is asking the board to accept a concentration risk it may not have priced.
4. Who owns the risk internally?
AI governance fails when it belongs to everyone in principle and no one in practice. The board should identify a named executive owner, a documented risk assessment and a route for escalating concerns. It should also ask whether the tool appears on a register of systems and suppliers, and whether internal audit or risk functions have reviewed it. For larger organisations, the board may wish to see how the tool interacts with existing policies on information security, records management and acceptable use. The answer should not be “the technology team” unless the technology team also has the authority and resources to enforce it.
5. Can staff use it competently and safely?
A licence is not a capability. Directors should ask what training has been delivered, how completion is monitored and whether staff understand the limits of the tool. They should also ask about shadow AI: the use of unapproved tools that can bypass controls entirely. Practical questions include whether prompts and outputs are retained, how confidential information is protected, and what staff should do when an output looks plausible but may be wrong. Training should be refreshed when the tool changes materially, not only at onboarding.
6. What measurable outcome justifies renewal?
The board should be wary of ROI expressed only in time saved or enthusiasm scores. It should ask for a baseline, a small set of measurable indicators and a comparison with alternatives, including doing nothing. Depending on the use case, relevant measures might include cost per transaction, error rates, cycle time, customer response times or compliance exceptions. The question is not whether the tool is impressive. It is whether the organisation can show, with evidence, that the licence is improving an outcome the board has chosen to prioritise.
7. How will the vendor’s changes be governed?
AI vendors change models, terms, pricing and functionality frequently. The board should ask how material changes are notified, whether the company can object or terminate, and what service levels apply during disruption. Audit rights, security certifications, incident notification and continuity arrangements should be reviewed alongside the commercial terms. A renewal that locks in today’s functionality without governing tomorrow’s changes is not a stable arrangement.
A short board record
The output of this exercise need not be a lengthy report. A one-page assurance note can record the seven answers, the unresolved points and the conditions attached to approval. That note becomes useful evidence of director diligence and a practical reference at the next renewal. In 2026, the boardroom question is no longer whether AI is relevant. It is whether the board can explain, on reasonable grounds, why this tool, on these terms, is being approved.