Last week’s piece on why AI pilots stall ended with a claim worth restating plainly: the hardest part of AI governance isn’t building a framework. It’s someone in the room being willing to ask an uncomfortable question out loud, before the money is spent, not after.

This week, that someone is the board.

Three in four boards have now approved a major AI investment. Fewer than half have set any governance expectations around it, and fewer than half have made AI risk a standing item on their own oversight agenda. Separately, a recent industry analysis found that while 88 percent of organisations report using AI in at least one business function, only 39 percent of Fortune 100 companies disclose any form of board-level AI oversight. Boards are saying yes to AI faster than they’re building the muscle to ask what happens if it goes wrong.

That gap isn’t a knowledge problem. Most directors don’t need to understand a transformer architecture to govern AI well, any more than they need to understand cryptographic protocols to govern cybersecurity. What they need is a short list of questions precise enough that a non-technical director can ask them verbatim, and specific enough that a vague answer is itself the warning sign.

Here are five:

1. Who owns this, by name — not by function?

“The AI team owns it” is not an answer. Neither is “IT and the business unit share it.” Shared ownership of a working system is fine. Shared ownership of a system that just produced a wrong, costly, or reputationally damaging output is how organisations end up with an incident and no one authorised to have stopped it. Ask for a name. If management can’t give you one without a pause, the system isn’t ready to scale, regardless of how well the pilot performed.

2. Who can stop it today, and how long would that actually take?

Not “there is an escalation process.” Ask them to walk through it in the room, as if it were happening right now. Who gets the call? What authority do they have? Whether stopping the system requires convening a committee first, or whether one person can act. Protiviti’s 2026 board governance research found that organisations with strong AI returns place AI on every board agenda roughly five times more often than organisations reporting weak returns — the pattern that separates them isn’t more meetings; it’s that oversight is a live, rehearsed capability rather than a policy that exists on paper and has never been tested.

3. What’s the evidence this creates value — not the argument that it should?

A pilot’s promise and a production system’s proof are different documents, and boards are routinely shown the former labelled as the latter. Ask for the metric, the baseline it’s measured against, and who signed off on that baseline before the system went live — not after, when the numbers were already flattering. If the success measure was defined retroactively, treat that as a governance gap, not a technicality.

4. Can this be explained — to a regulator, an auditor, or a customer who was harmed by it?

This is different from asking whether the system is accurate. A system can perform well and still be unable to produce a defensible account of why it reached a specific decision in a specific case. For anything touching credit, hiring, healthcare, or other consequential decisions, “we don’t fully know why it said that” is not a compliance footnote — it’s the whole risk. Ask management to produce one real example, not a hypothetical, of the system’s reasoning being reconstructed after the fact.

5. Where does the data live, and under whose jurisdiction?

This question gets skipped more than any other, and in the GCC and other regulated, sovereignty-conscious markets, it’s often the one with the sharpest teeth. A vendor’s global architecture, a cross-border processing agreement, a model hosted outside the jurisdiction your regulator actually cares about — any of these can turn a well-governed system into a compliance exposure unrelated to the model’s accuracy. Ask where the data sits, who can access it, and what happens if that vendor’s jurisdiction changes its rules.

Why these five, and not a longer list

Boards don’t fail at AI oversight because they lack frameworks. Most large organisations now have an AI policy document somewhere. They fail because the questions inside that document are answerable in the abstract and never get asked concretely, in the room, against a specific system, before the approval is given.

Notice what these five questions have in common: none of them can be answered well with a policy citation. Each one demands a specific, current, falsifiable answer — a name, a rehearsed action, a baseline, an example, a jurisdiction. That’s deliberate. A board that can get concrete answers to these five questions has effectively audited the system’s accountability structure without needing to understand a single line of its architecture.

If management’s answer to any of these is a process description rather than a fact, that’s not a failed question. That’s the system telling you it isn’t ready yet — and a board that hears that clearly, before scaling, has just done its job.

Next in this series: the control gap nobody talks about — why “human-in-the-loop” is, in most organisations, still a fiction.