AI Certified. Capability Not Found.

Why the AI a board pays for is not the AI it can rely on, and the eight elements that close the gap

James A Lang · 13 November 2026 · Trusted capability

Imagine a Formula One team where every mechanic has completed AI training. The certificates are on the wall. Every one of them has the latest assistant on a tablet. And nobody knows how to change a tyre.

It is a joke until you look at how most organisations are adopting AI. Licences purchased. Employees certified. Pilots launched. Yet the work has not fundamentally changed, and neither have the numbers.

The lesson I learned in 2019

In 2019 I was working on the programme that became Cyber Mission Data, the Ministry of Defence's cyber command and control platform. It taught me the most important lesson in this field, because I could see it from both sides.

Some of our AI use cases succeeded. Others failed, at real cost. The failures often started from the same assumption: pull all the data into one big store, point AI at it, and the answer will come out. But the pattern only became clear when I set the failures beside the successes.

The successful use cases were built to deliver an effect, and they succeeded because we ran them through the Defence Lines of Development, the same discipline Defence uses to field any new capability. The unsuccessful ones were treated like a new software update: installed, announced and left to run. The technology was often similar. The difference was whether anyone had built a capability around it.

A product is something you buy. A capability is something you can do. The gap between the two is where most AI investment is lost.

Equipment is not capability

The Defence Lines of Development exist because Defence learned this long ago. Capability is the enduring ability to deliver a desired effect, and nobody in Defence confuses a new vehicle with a new capability. The vehicle is equipment. The capability exists only when trained people, the right information, a doctrine for using it, an organisation built around it, the infrastructure to house it and the logistics to keep it running all arrive together. Anyone who has fielded anything knows the checklist by its mnemonic, TEPID OIL: training, equipment, personnel, information, doctrine and concepts, organisation, infrastructure, logistics, with interoperability running through them all.

Miss one line and you do not have a smaller capability. You have an expensive object.

The management literature reaches the same conclusion by a different road. Returns from general-purpose technologies flow to the firms that invest in the organisational changes around them, and measured returns often dip before they rise. Erik Brynjolfsson, Daniel Rock and Chad Syverson call this the productivity J-curve. A board that measures only what it has bought will read the dip as failure, or will never see the rise at all.

OUTCOMES: eight elements, one outcome

OUTCOMES takes the discipline that made our successful use cases work, the Defence Lines of Development, and rebuilds it for a board adopting AI. I call it OUTCOMES because that is the only thing worth measuring. Eight elements must be in place, and joined up, before AI delivers a measurable result. Each maps one to one to a Defence Line of Development.

Look at how most organisations fund AI against that list. Technology gets the budget, the board paper and the launch. Upskilling gets a certificate. The other six arrive late, partly or not at all. Nobody owns the outcome, so AI sits with IT. The work is the old process with AI added on top. The data is siloed and its quality unknown. Nobody close to the work can challenge what the model produces. And there is no plan for month nine, when the pilot team has moved on and the supplier's contract comes up for renewal.

From access to outcomes

The value of AI arrives in four stages, and a board should know which one it is paying for.

Access is the tools bought. Adoption is the people trained. Both are inputs. Value starts at Traction, when the OUTCOMES elements change how the work is actually done, and it is proven at Outcomes, when the numbers move.

Most board reporting on AI stops at the first two stages. Licences, seats, completion rates and pilot counts are easy to measure and easy to grow. They are also the stages where nothing has yet changed.

Using it in the boardroom

OUTCOMES is a scorecard, not a slogan. Score each element from 1 to 5 against one named outcome: 1 means absent, 3 developing, 5 embedded. For Ownership, 1 means no named owner and AI sitting with IT; 5 means an executive owns the outcome and the decision rights are written down. For Expertise, 1 means nobody can challenge what the AI produces; 5 means expert judgement is designed into every critical step.

Then use it in five steps.

Name one outcome. A revenue, margin or strategic effect, with a number and a date. Without it, there is nothing to score against.

Score independently. Each director and the accountable executive score alone, then compare. Wide gaps show where the board lacks a shared picture.

Find the constraint. The lowest score is the binding constraint. Investment in any other element will not move the outcome until that one is fixed. The most common pattern is a high Technology score next to low scores for Culture & Ways of Working or Expertise.

Fund the constraint. Direct the next tranche of investment at that element, with an owner and a review date.

Re-score quarterly. Track the scores alongside the outcome itself, not alongside licences or certifications.

One question belongs in every board's AI discussion. If your AI provider went dark for 48 hours, what could your organisation still do? It tests Operating Foundations, Maintenance & Support and Expertise at once. The answer tells you how much of your AI is capability and how much is dependency. Resilience is what buys you the right to be wrong.

Why capability comes after leadership

I use a frame with boards that puts four questions in order: purpose, leadership, capability, outcomes. Capability is third for a reason.

You cannot build the right capability until you know what it is for, and you cannot build it without leadership that understands what it is building: not the mathematics in detail, but enough to know that a model is not an oracle, that data does not become knowledge by being stored in one place, and that a tool is never the whole system. This is why I tell boards that the first thing to protect in an AI programme is the leadership. Protect the leadership, and the leadership protects the team, the capability and, in the end, the investment.

The question for the board

The question is not how many people you have trained or how many AI tools you have bought. It is which element is holding back the outcome you want.

Certificates measure inputs. Capability is measured in outcomes. Leaders are responsible for AI decisions they did not build, and for the capability those decisions depend on.

How I used AI in this article

I drafted this article with AI assistance from my own notes, the OUTCOMES board tool and earlier writing. The illustrations come from The Decision Theatre, my illustrated film series, and were made with AI image tools to my direction. The experience, the framework and the judgements are mine, and so are any errors.