Board Questions on AI Risk: A Practitioner Q&A for NEDs and Chairs

This page answers the questions we are asked most often by non-executive directors, chairs and CEOs preparing an AI item for the board agenda. It covers what to ask, what a credible answer sounds like and how to tell assurance apart from evidence. Written for boards in UK regulated markets who need to discharge oversight duties without becoming technical specialists.

Reviewed by Jason Holloway, QL Security.

What should the board be asking about AI risk?

Five questions expose most of the posture:

• Who owns AI risk?
• Which tools are staff actually using?
• What data leaves the organisation through those tools?
• Which suppliers apply AI to our data?
• What happens in the first hour of an AI-related incident?

If the executive team answers those with evidence rather than reassurance, the board has something to oversee. Everything else is refinement. Boards often open with regulation, which produces a compliance answer and tells you little about exposure. Start with usage and ownership, because those two determine whether any control or policy the executive describes is being applied. Our AI Security Gap Analysis is structured around the same sequence for exactly that reason.

Who owns AI risk, and how do we know the answer is real?

Ask for a named individual, not a committee. Then test the answer: what decisions has that person made in the last quarter, what did they refuse and what budget do they control?

A weak answer distributes ownership across IT, legal, data protection and a steering group. That arrangement looks thorough in a board pack and fails in practice, because no one has authority to stop a deployment. A credible answer names one accountable executive with a defined mandate, an escalation route to the board and a record of applied decisions. Our answer on who should be responsible for AI sets out how that mandate is written. Where organisations lack the capability internally, a virtual Chief AI Officer arrangement places accountability with a named external executive without a permanent hire.

How do we find out what AI tools staff are actually using?

Ask for the list, then ask how it was produced. A policy document, a procurement register or a survey of department heads will understate real usage, usually by a wide margin.

Credible visibility comes from technical discovery: network and identity telemetry, browser extension inventories, expense data and SaaS integration logs. That work surfaces Shadow AI, the tools staff adopted without approval because they solved an immediate problem. The follow-up question matters more than the list. Ask what the executive team did with the tools it found. Blanket bans push usage further out of sight, so the useful response is a sanctioned route for the highest-value use cases plus monitoring for the rest.

What should we ask about data leaving the organisation?

Ask which categories of data have been entered into AI tools, under what contractual terms and whether that data trains a third-party model. Then ask how the answer is verified rather than assumed.

The exposure boards underestimate is not customer records; it is unstructured internal material such as board papers, legal advice, pricing models and staff casework. Enterprise agreements often exclude training use, though free and personal-account tiers frequently do not, and staff move between the two without noticing. A sound answer distinguishes the sanctioned estate from personal usage and states which data classes are prohibited from both. Our AI Behaviour Verification work tests whether those prohibitions hold in operation.

How do we know whether our suppliers are using AI on our data?

Ask how many material contracts have been reviewed for AI clauses in the past twelve months and what proportion of suppliers gave a written answer. The gap between contracts reviewed and contracts held tells the board most of what it needs.

Supplier AI is where oversight quietly breaks down. Processors adopt AI features inside existing services, often without a contract variation, and the organisation inherits the exposure. A serviceable answer covers the highest-risk contracts first, records supplier responses in writing and updates due diligence questionnaires so new suppliers are asked before onboarding rather than afterwards. Boards should also ask what happens when a supplier declines to answer.

What does board-level AI incident readiness look like?

Ask who is called in the first hour when an AI system produces a harmful or unlawful output, and whether that scenario has been rehearsed. If the answer references the existing cyber incident plan without modification, readiness is unproven.

AI incidents differ from breaches in a way that matters at board level. There may be no intrusion, no exfiltration and no attacker, so the standard playbook triggers do not fire. Decisions instead concern suspension of a live system, correction of affected outputs, regulatory notification and customer communication. A credible answer names the decision-maker for suspension, the technical route to disable the system and the threshold for board notification.

Do we need ISO 42001, or is that premature?

Ask what problem certification is intended to solve before asking whether to pursue it. ISO 42001 provides a management system for AI, which is valuable when the organisation already has visibility of its AI estate and needs governance discipline around it. Pursued too early, it documents controls over systems the organisation cannot yet see.

The sequencing we recommend is discovery, then ownership, then a management system, then certification if a customer, regulator or tender requires it. Boards in scope of the EU AI Act should ask separately about classification of their systems, since obligations there follow risk category rather than certification status.

How often should AI risk appear on the board agenda?

Quarterly as a standing item, with the first two sessions longer than subsequent ones. Annual review is too infrequent for a control environment changing this quickly, and monthly reporting produces volume without insight.

Ask for three things in the standing paper: change in the sanctioned AI estate since the last meeting, incidents and near-misses, and progress against the agreed remediation plan with dates. If the paper contains only strategy and opportunity, the board is receiving an innovation update rather than a risk report. Reading both in the same session is reasonable, provided they are clearly separated.

We have never had this discussion. Where do we start?

Start with a single agenda item at the next scheduled meeting and one request to the executive team beforehand: an evidenced inventory of AI systems in use, including tools adopted without approval, and a named owner for AI risk. Those two artefacts convert a general concern into a governable one.

Expect the first inventory to be incomplete. That is useful information in itself, because it establishes how much visibility currently exists. From there the board can commission an independent baseline assessment and set a remediation timetable with dates it intends to hold the executive to.

For related reading, see AI Governance and the AI Security Gap Analysis we use to produce board-ready baselines. To discuss an upcoming board session, contact us.