What is the Intelligence Age?
The period in which organisations run on capability they buy rather than build. A modern AI system reasons, generates and acts, trained on data the deployer never saw, changing behaviour with each model version. Ownership splits across the lab, the vendor and the deployer. Accountability does not split at all.
Earlier waves of technology gave organisations better tools: a spreadsheet does exactly what its formulae say. This wave is different in degree, not just kind. The thing a board is now answerable for produces outputs its own builders cannot enumerate in advance, and it arrived faster than any control framework most organisations had in place. Of the three parties who own a piece of the capability, only the deployer sits in your boardroom, and the outcome lands in full on the deployer. That is the thesis of Governing the Intelligence Age, and everything else in this pillar follows from it.
Why do boards struggle to keep pace with AI?
Because of the pacing problem, which is a cadence mismatch rather than a technology problem. AI capability changes on a release schedule measured in weeks, while a board's authority to ratify it moves in quarters and years. The tool the board approved in March rarely still exists by the annual review.
It breaks the annual sign-off assumption in three specific ways, none of which is misconduct. The model underneath changes when a provider deprecates a version, and behaviour shifts with no paper tabled. The usage spreads, as a tool scoped for internal decision-support acquires a customer-facing surface no sign-off contemplated. And the controls drift, as thresholds are tuned and gates quietly removed, each change looking like routine engineering. The board's instrument for granting permission, the meeting and the minute, samples the system far too rarely to govern it. We work through this in The pacing problem.
Can a board meet its way out of the pacing problem?
No. You cannot out-meeting a release schedule. Moving AI to the quarterly cycle helps, but faster ratification is still a discrete act on a snapshot that has already changed by the time the minute is signed. The pacing problem demands governance that does not wait for the meeting to be true.
That means standing controls that hold on every transaction: an approval gate that cannot be bypassed, a read-only constraint the model cannot escape, an append-only ledger the system writes as it runs. The board still ratifies the slow-clock things, the risk appetite and the list of what AI may never do, while the system enforces the fast-clock controls and produces its own evidence. The engineering behind those controls is the subject of our Responsible AI in practice pillar; the cadence argument for them lives here.
What is a board accountable for when it buys AI rather than builds it?
Everything the system does under its name. Indemnities and service levels can be contracted for; regulatory and fiduciary accountability cannot be contracted away. UK regimes do not ask who built the model. They ask who is accountable for what it did, and that is always the deploying organisation.
The practical response is to govern the boundary rather than the black box: what the system may read, what it may do, what it must prove before acting, and who decides when it is wrong. None of that requires reading the model's weights. All of it can be specified by a board and enforced in code, and it is far cheaper to design before deployment than to retrofit after an incident. The binding regimes that make this urgent, from UK GDPR to the Data (Use and Access) Act 2025, are collected in the UK AI Regulation Tracker.
What should a board do now?
Name the boundary and govern it. Decide what AI may never do in your organisation. Require the controls that enforce that boundary to live in the systems themselves. And insist on evidence that is produced continuously rather than assembled for the meeting.
None of this requires the board to become technical. It requires the board to do what boards have always done, which is to decide what the organisation will and will not answer for, and to demand proof that the decision is being enforced. The difference is only where the proof comes from: not a quarterly paper, but the system's own record. Those three moves convert the Intelligence Age from a threat a board cannot inspect into a capability it can answer for. They also happen to be measurable: the Board AI Scorecard tests how far your board already is from that position across accountability, policy, risk, data and capability, in about two minutes. The essays below develop the argument.
