A board signs off on an AI tool that drafts customer correspondence. Nobody in the room wrote the model. Nobody in the company trained it, can read its weights, or can tell you precisely why it produced one sentence rather than another. The vendor cannot fully explain it either. And yet, the moment that tool sends a letter under the company's name, the board owns the outcome. If the letter is wrong, unfair, or unlawful, "the model decided" is not a defence anyone will accept.
That gap — between the capability you are accountable for and the capability you actually built — is the governance problem of the Intelligence Age. It is not new in kind; boards have always been accountable for things they did not personally do. It is new in degree. The thing you are answerable for now reasons, generates and acts, and it arrived faster than any control framework you had in place to govern it.
Key takeaways
- The defining governance problem of the Intelligence Age is accountability for capability your board buys rather than builds and cannot fully inspect.
- Ownership splits three ways — the lab, the vendor, the deployer — but accountability does not: it lands in full on the organisation that points the AI at a real decision.
- You can contract for indemnities and service levels, but you cannot contract away your regulatory and fiduciary accountability; UK regimes ask who is accountable, not who built the model.
- You cannot govern a black box, but you can govern its boundary: what the system may read, what it may do, what it must prove before acting, and who decides when it is wrong.
- The boundary is far cheaper to design before deployment than to retrofit after an incident, which is why "buy the capability, govern it later" fails so reliably.
The Intelligence Age is a shift in who holds the capability
Earlier waves of technology gave organisations better tools. The Intelligence Age gives them capability they no longer fully author. A spreadsheet does exactly what its formulae say. A modern AI system produces outputs that its own builders cannot enumerate in advance, trained on data the deploying organisation never saw, behaving in ways that shift with each model version.
This is the substantive change a board has to absorb. The capability is real and useful. But ownership of it is now split three ways: the lab that trained the model, the vendor that wrapped it into a product, and the organisation that points it at a real decision and signs its name to the result. Of those three, only the last one sits in your boardroom. Accountability does not split the way the supply chain does. It lands, in full, on the deployer.
Most of the AI adoption advice aimed at boards skips past this. It treats AI as a procurement question — pick a tool, run a pilot, measure return — and the evidence is that the procurement framing fails. Industry reporting through 2025 has put the proportion of enterprise generative-AI pilots delivering no measurable financial return strikingly high, with most projects never reaching production at all. We treat figures like these as context to verify rather than as our own measurements, but the pattern is consistent: organisations buy capability and discover they cannot govern it, so it stalls.
Accountability does not transfer with the contract
The instinct, when capability is bought rather than built, is to push the risk down the contract. The vendor has the expertise; let the vendor carry the liability. This is where boards most often misread their position.
You can contract for indemnities and service levels. You cannot contract away your own regulatory and fiduciary accountability for an outcome your organisation caused. In the UK this is not a future problem waiting on an AI statute. There is no single UK AI Act; governance is principles-based and applied by the regulators you already answer to. The binding regimes already reach your AI today.
- Where your AI processes personal data, the Information Commissioner's Office is your lead regulator under the UK GDPR and the Data Protection Act 2018 — and it holds you, the controller, responsible for a third party's model.
- The Data (Use and Access) Act 2025 reshaped the rules on automated decision-making; its section 80 came into force on 5 February 2026, replacing the old Article 22 with new Articles 22A to 22D. The ICO's updated guidance on automated decision-making and profiling remains in draft, with its consultation closed on 29 May 2026 and final guidance expected in summer 2026 — so treat that detail as provisional.
- If you have EU exposure, the EU AI Act (Regulation (EU) 2024/1689) is binding and extraterritorial. It can catch a UK organisation whose AI output is used in the EU, regardless of where the model was built or bought. Its high-risk application dates were pushed back under the 2026 "Digital Omnibus on AI" to 2 December 2027 for stand-alone systems and 2 August 2028 for systems embedded in regulated products, though those amendments were still completing the EU legislative process as of late May 2026 — confirm final adoption before relying on the dates.
None of those regimes asks who built the model. They ask who is accountable for what it did. That is always the deploying organisation, which means it is always the board.
You cannot govern a black box, but you can govern its boundary
If a board cannot read a model's weights, what is left to govern? The answer is the boundary around it: what the system is allowed to read, what it is allowed to do, what it must prove before it acts, and who decides when it is wrong. You do not need to understand how a model reasons to constrain what it can touch. The boundary is where governance over bought capability actually lives.
This is also where governance stops being a policy document and becomes engineering. A few patterns we build into our own systems make the point concrete.
| Governance question | A control that answers it | Where it sits |
|---|---|---|
| Can the model change data it should only read? | Read-only by construction — the database itself rejects any write the model attempts | Property operations system |
| Can it state something its source does not support? | Every AI-extracted quote must be a literal substring of the source, or the extraction fails | Insolvency intelligence engine |
| Who decided, and can you prove it? | An append-only decision ledger recording the model's suggestion, the named person's accept/modify/reject, and the timestamp | Surveying operations system |
In each case the control does not depend on the model behaving well. The read-only constraint holds even if the model tries to write. The substring check fails closed if the model invents a quote. The ledger cannot be silently edited after the fact. That is the difference between governing the boundary and hoping the vendor governed the centre. You are accountable for capability you did not build; you make that accountable by constraining the capability you cannot inspect.
A board governs the boundary, not the model
This reframes the board's job in the Intelligence Age more usefully than "understand AI" ever did. You do not need to become a machine-learning team. You need to be able to answer, for any AI system your organisation relies on, a small set of questions that have nothing to do with how the model works internally:
- What is it allowed to do on its own? A system that drafts is a different risk to one that acts. Name the line. In the systems we build, the AI advises and a named person decides — it does not score, post, finalise or send on its own.
- What must it prove before a human relies on it? A claim should be checkable against its source. A confidence threshold should be able to overrule the model and route a borderline case to a person rather than letting the model proceed.
- What evidence survives the decision? If a regulator, an auditor or a claimant asks in eighteen months why the system did what it did, the answer should already exist as a dated record, not be reconstructed under pressure.
- Who is the named person? Accountability that cannot be attributed to an individual is not accountability. The control that matters most is the one that records a human in the loop.
These are governance questions, not technical ones. They are answerable by a board, and they apply whether the underlying model came from a large AI lab, a UK vendor or an internal build.
The Intelligence Age rewards boards that govern early
There is a timing argument underneath all of this, which we set out in full in a companion piece on the pacing problem: capability is moving faster than governance can ratify it. The practical consequence for the brand thesis here is simple. The boundary is far cheaper to design before deployment than to retrofit after an incident. A board that decides, up front, what its AI may and may not do — and insists the controls are built in rather than promised — is governing the Intelligence Age rather than reacting to it.
This is also why "buy the capability, govern it later" fails so reliably. The capability arrives complete; the governance does not. The work is to specify the boundary as part of the buying decision, and to require evidence that the boundary is enforced in code, not asserted in a slide. That is a board-level discipline, and it is the one the Intelligence Age most rewards.
The honest summary is this. You will deploy capability you did not build. You cannot inspect it fully, and you cannot give the accountability back. What you can do — and what your board is for — is govern the boundary around it so that, whatever the model does, your organisation can show who was accountable, what the system was permitted to do, and that the evidence was there all along. That is what governing the Intelligence Age means in practice.
Last reviewed: 29 May 2026.
If your board is adopting AI it did not build and wants to be sure it can answer for it, that is the conversation we have. See how we approach it, or read the controls we build into our own systems.
