The Boardroom Guide to AI Governance

A board cannot discharge oversight of a system whose decisions it cannot reconstruct. Every other artefact of AI governance, the policy, the risk register, the vendor attestation, sits downstream of that one capability. Oversight is establishing, against challenge and after the fact, what a system actually did in a specific case on a specific date. Without that, a board is not governing. It is trusting, and calling the trust governance.

What is the board actually accountable for when a model makes a decision?

Not the model. The decision. A director's duty under section 172 of the Companies Act 2006 contains no carve-out for outcomes produced by software. When a system refuses a customer credit, flags a person for investigation or shapes a clinical pathway, the accountable party is the organisation that acted, and the accountable people sit in its boardroom.

The exposure is not the model's aggregate error rate; nobody sues over an error rate. It is the single case: one claimant, one date, one decision, one demand from a court or a regulator to explain exactly why. GDPR Article 22 already gives data subjects rights over decisions taken solely by automated means with significant effects. The EU AI Act adds deployer obligations for high-risk systems, distinct from the provider's, applying from 2 December 2027: a build window, not a reprieve. Both converge on a demand that is not for a policy. It is for a record.

Why do AI policies pass board review and still fail?

Because a policy governs intent and a system executes behaviour, and nothing in between guarantees the two match. The board approves an intention; the system then runs for a year through model updates, prompt changes, new data sources and workarounds by people under delivery pressure. What fills that gap is assurance by assertion: a vendor attests, a model card describes, an evaluation was run once on a benchmark by the party with an interest in the result. Each speaks in general terms. Every challenge a board faces is specific.

What does reconstruct actually mean, and why is a log not enough?

To reconstruct a decision is to rebuild it independently: the inputs, the exact model version, the retrieved context, the policy in force at that moment, the human clearance if any, the output, and the action taken. Logging built for engineering purposes fails on four properties, and each is where a case is lost.

• Completeness at the moment of action. A record written after the fact, sampled, or inferred from telemetry is a reconstruction of a reconstruction. It must be sealed before the action executes, not after it succeeds.
• Immutability. A log the operator can edit is not evidence. It is a claim by the operator, and opposing counsel will say exactly that.
• Independence. The record must be verifiable by someone who does not trust the operator and cannot reach its infrastructure. Otherwise the organisation marks its own homework.
• Longevity. Records must outlive the vendor contract, the model version and the cryptography protecting them, which is why the signature standard is post-quantum, such as FIPS 204 ML-DSA.

Logging serves engineers debugging yesterday. Evidence serves a stranger with power interrogating you in three years.

What should a director ask, and what does a good answer sound like?

Four questions. The value lies in the shape of a real answer.

• Take a decision this system made last Tuesday. Who can reconstruct it, how long does it take, and does it need our cooperation? A good answer: a named person, a number of hours, and no.
• Which decisions can this system take without a human clearing them, and where is that boundary enforced? A good answer points at the runtime, a bad one at a policy document, which is to say at nothing.
• If the vendor went insolvent on Friday, what happens to our evidence? A good answer: we hold the records, on hardware we own, and they verify without the vendor.
• Which named executive owns the outcome, not the project delivering it? A good answer is a person who was in the room when you asked.

Then run the drill. Take one live automated decision, chosen by the board rather than volunteered by the team, and ask management to reconstruct it in full for the audit committee within a stated time. Watch for the deflections: certified to SOC 2, explainable, full logs. Each is true about something other than the question asked.

Is this not just over-governance?

For many systems, yes, and the concession is honest. AI that drafts documents, summarises meetings and writes code carries none of this exposure: sealed cryptographic evidence for a meeting-notes assistant is cost with no return. Cloud is the right answer for that class of workload, and we would say so in any boardroom. The test is narrow. Does the output touch a person's money, liberty, safety, employment or health, or the organisation's regulatory standing, or a function of the state? If yes, reconstructability is not optional. If no, govern lightly and move on. Reconstructability will not make a decision correct, but wrong and reconstructible is survivable: the error can be found, bounded and explained. Wrong and unreconstructible leaves the organisation guessing at the scope of its own error, under oath.

Frequently asked questions

Does AI governance belong to the audit committee or to the full board?

The full board. Audit committees are suited to testing evidence and challenging management on controls, and they should own the drill described above. But which classes of decision the organisation is willing to automate at all is a strategy question, not an assurance one. Delegating it to audit turns a question about what the company is for into a question about tidy paperwork.

Is a vendor's compliance certification enough for the board to rely on?

No. A certification tells the board that a third party assessed a defined scope, at a point in time, against a control set the vendor helped shape. It says nothing about what your instance did in a specific case on a specific date, which is the only thing anyone will ask you. It is a procurement filter, not a foundation for oversight.

What is the single question a director should ask about any AI system?

Reconstruct a real decision this system made last month, in front of us, and tell us who can verify it without our help. Everything a board needs is in the answer: whether the record exists, whether it was sealed before the action, and whether the organisation's account of itself rests on its own goodwill.

Does the EU AI Act apply to a UK-headquartered company?

Yes, in defined circumstances, and its high-risk obligations apply from 2 December 2027. The Act reaches providers placing systems on the EU market, deployers established in the EU, and cases where a system's output is used within the EU, wherever the operator sits. A UK company serving EU customers or subsidiaries should assume it is in scope until counsel establishes otherwise, and treat that date as a design deadline.

Mickai is a British Sovereign Intelligence Operating System, built and live today, running offline on hardware the organisation owns and in its own jurisdiction. Its Open Audit Record seals every consequential action before it executes, signs it with post-quantum FIPS 204 ML-DSA-65 and hash-chains it so a regulator, an auditor or a court can verify it offline, without our cooperation and without our infrastructure. Agents operate inside a gated sandbox under per-action clearance, so the boundary a board approves is the boundary the runtime enforces. The architecture is protected by 104 filed UK patent applications carrying 2,340 claims, owned by Mickai LTD. Read /sovereign-ai for the design position, /oar for how the evidence is verified, and /ai-readiness to test whether your organisation could pass the drill.