A board's guide to governing AI

AI governance, for a board, means four controls: a human approves consequential actions, every action the system takes is logged, performance is monitored so drift is caught early, and the whole programme is reported in terms a director and an auditor can read. An organisation that can evidence those four controls can defend how its AI was used, and defending the use is the test that matters. A board that approves AI without them is taking on risk it cannot see.

What are the four controls a board should require?

The first control is human approval. Anything consequential, such as money or messages leaving the business, pauses for a person to approve it until the system has earned autonomy with a measured error rate. The second is logging. Every action is recorded with its basis, so any decision can be reconstructed after the fact, months later, from the record alone.

The third is monitoring. Model behaviour drifts as inputs change, so performance is measured continuously against a baseline and reviewed on a fixed cadence, with drift triggering a review rather than being discovered in an incident. The fourth is reporting. What the systems did, what they decided, what they refused, the error rate and the approvals applied are summarised in language a board pack can carry.

None of this is exotic. These are the same disciplines a finance function already applies to any process that touches money or customers. The mistake is treating AI as special and exempting it from them, then discovering the organisation cannot explain what a system did when someone asks.

What questions should a director ask before approving AI?

Five questions cover the ground. One: where does a human approve consequential actions, and what counts as consequential? Two: what does the system log, and can we reconstruct any decision after the fact? Three: how is performance monitored, and who reviews it? Four: how is all of this reported to us, and how often? Five: who is accountable when an automated action goes wrong, and what is our exposure to the vendor?

A management team that can answer all five in writing is running a governed programme. A management team that answers with an assurance that the technology is very good is describing a demo.

Who is accountable when an automated action goes wrong?

The organisation that owns and operates the system carries the accountability, in the same way it does for any other business process. That is a reason to demand controls rather than to avoid automation. The controls exist so that nothing consequential happens without a human approval while autonomy is being earned, which keeps a person in the chain of responsibility for exactly the actions that could cause harm.

Logging completes the picture. When every action is recorded with its basis, responsibility can be established from the record rather than argued about after the fact. The record shows what the system did, what information it acted on, and who approved the action.

Vendor risk sits alongside this. A board should expect the organisation to own the code, the prompts and the data, rather than renting a system it cannot inspect. Ownership is what makes independent review possible, and it means a supplier failure or a price change never leaves the business running software it cannot see inside.

How often should AI be reported to the board?

A workable cadence has three layers. Weekly, the operating team reviews volume, exceptions, approvals and drift for each live workflow; this is management information rather than board material. Monthly, a one-page summary goes to the executive: what ran, error rates against threshold, incidents, and any change to autonomy settings.

Quarterly, the board receives a short pack: the live systems and what each is permitted to do, error rates and how they moved, any incident and its resolution, any change to data processing that required an updated impact assessment, and the approvals framework in force. A pack like that takes minutes to read, and it means the board is never approving in the dark.

Treat autonomy as a setting the organisation raises on evidence. Begin with a human in the loop, measure the error rate, and relax the controls only as the record justifies it. Governance, run this way, is what lets a board say yes to AI with confidence and keep saying yes as the systems take on more.