04Execution, the disciplined path

From discipline to operating model

Knowing what the successful projects did is not the same as being able to do it. Chapter 03 ended on six points: a narrow business case, a quantified baseline, domain experts in the lead, humans in the loop, measured iteration with a kill criterion, governance from day one. Every executive reading that list agrees with it. Very few organisations execute it, because agreement is cheap and an operating model is not.

The gap between the two is where most generative AI programmes stall. The list says "governance from day one" without saying what governance consists of. It says "a narrow business case" without saying which kinds of narrow case are worth pursuing first. It says "measured iteration" without saying what the organisation should be able to do at the end of each iteration that it could not do before. This chapter fills those gaps. It is deliberately concrete, because the abstraction is where projects go to die.

One framing choice runs through everything that follows. Generative AI is treated here as a technology capability to be built, not a product to be bought. Vendors matter, models matter, but neither is the unit of progress. The unit of progress is what the organisation can safely and measurably do with AI that it could not do six months earlier.

Six governance pillars

"Governance" is the word executives most often use and least often decompose. In practice it resolves into six distinct pillars, each answering a different question, each owned by a different part of the organisation. The common failure is not the absence of governance. It is governance that exists as a single policy document owned by nobody in particular, written once, and consulted never.

1. Pillar 01 Data ownership Which data may flow into which AI system, under whose authority. Classification first: public, internal, confidential, regulated. Every class gets a rule, and every rule has an owner who can say yes or no. Can anyone name who approves a new data source for an AI use case?
2. Pillar 02 Risk policy Use cases tiered by consequence of error, not by technology. A drafting aid for internal notes and a system that influences a credit or clinical decision do not belong under the same rules. Tiering decides how much of the other five pillars applies. Does every live use case have a risk tier, and does the tier change what is required?
3. Pillar 03 Compliance mapping Each use case mapped to the obligations it triggers: GDPR, the EU AI Act, sector rules (medical devices, financial services, employment). Mapping is done per use case, not per platform, because obligations attach to purpose. For the highest-tier use case, can legal list the obligations it triggers in one page?
4. Pillar 04 Audit trail What went in, which model and version produced what came out, who reviewed it, what was done with it. Not for its own sake: an audit trail is what lets the organisation explain an outcome to a regulator, a court, or itself. Could you reconstruct a specific AI-assisted decision from last month?
5. Pillar 05 Human accountability A named person is accountable for every AI-assisted output that leaves the team. "The model said so" is never an answer. Accountability attaches to a role, and the role has the authority and the time to exercise review. For each use case, is there a named person who signs off, and do they have time to?
6. Pillar 06 Shadow AI controls Employees are already using generative AI, sanctioned or not. Prohibition fails. The control that works is a sanctioned alternative good enough that people prefer it, plus visibility into what flows out. Do you know which AI tools your staff used last week, and with what data?

Two of these pillars deserve emphasis because they are routinely underweighted.

Shadow AI is the governance problem most organisations already have. Long before any official programme starts, staff paste contracts, customer emails, source code and board papers into whatever assistant they use at home. The exposure is real and it is happening now. The instinct is to block. Blocking without offering an alternative simply moves the usage to personal devices, where it becomes invisible. The organisations that handled this well treated their first sanctioned assistant not as an AI project but as a security control: a safer channel for something that was going to happen anyway.

Compliance mapping has become concrete. The EU AI Act entered into force in August 2024 and applies in phases: prohibited practices first, obligations for general-purpose model providers next, the high-risk regime after that. Most enterprise use cases will not be high-risk under the Act. Some will, notably in employment, credit, essential services, and anything that is or feeds a regulated product such as a medical device. The Act did not invent the discipline. It codified what the damage bucket in Chapter 03 had already demonstrated: deploying AI into a decision with legal weight, before the governance to carry that weight exists, is the most expensive mistake available. Frameworks such as ISO/IEC 42001 and the NIST AI Risk Management Framework give the six pillars a recognised structure for organisations that need to show their work to auditors.

Governance is not a gate in front of the programme. It is the programme's ability to say yes to the next, more valuable use case.

That framing matters for how governance is staffed. If governance is seen as a brake, it will be resourced as a brake: minimally, late, and by people measured on saying no. If it is seen as the mechanism that unlocks higher-tier use cases, it gets resourced like the capability it is.

Four capability patterns

The variety of generative AI use cases is less than it appears. Under the vendor vocabulary, almost every deployment that has produced value in the past four years is an instance of one of four patterns. Naming them is useful because each pattern has its own risk profile, its own natural form of human oversight, and its own prerequisites.

The four patterns, ordered by how much of the decision moves from the person to the system.

Read top to bottom, the table describes a gradient. In assist, a person reads every output before it goes anywhere. In act, the system does things and a person reviews the exceptions. Every step down the table moves verification further from the individual output and closer to statistical oversight, which means every step down requires more of the six pillars to be real rather than written.

Three observations follow.

Assist is the training ground, not the destination. Most organisations start here and should. It is where people learn what the models are good and bad at, where the shadow AI problem gets addressed, and where the acceptable-use policy gets tested against reality. But the measured gains from assist are individual and diffuse. They rarely show up in a P&L line on their own. Organisations that stop at assist end up in the 95% bucket by default, not because anything failed, but because nothing was ever measured at the level where value becomes visible.

Retrieve and extract are where measurable value concentrates. They attach to a specific workflow, a specific team, a specific volume. A baseline exists or can be built: time per document, error rate, cases handled per week. The domain experts who own the workflow can judge output quality directly. These two patterns account for most of the quiet, governed, compounding wins described in Chapter 03.

Act is where the industry's attention is, and where discipline matters most. Agentic systems are improving quickly and some of the results are genuinely impressive, particularly in software engineering. The prerequisite is not a better model. It is an organisation that already has a reliable audit trail, clear authority limits, reversible actions, and people who know how to supervise a process rather than review a document. Organisations that reach for act before they have mastered extract are rehearsing the Klarna story.

Crawl, Walk, Run, Fly

The roadmap ties the pillars and the patterns together. It has four stages, and its defining feature is not the stages themselves but the gates between them. Each gate has explicit exit criteria. An organisation moves forward when it meets them, not when the calendar says so, and not because a competitor announced something.

Crawl: sanctioned individual use. The organisation provides an approved assistant, an acceptable-use policy, a data classification that says what may and may not go in, and basic training. The purpose is threefold: replace shadow AI with a visible channel, build literacy across the workforce, and surface candidate use cases from the people who do the work. Crawl is cheap and fast. Its main risk is that it feels like progress and becomes permanent.

Walk: one bounded team workflow. One use case, chosen against the criteria in the next section, in one team, with a measured baseline and a domain-expert owner. Typically a retrieve or extract pattern. Every output is reviewed by a person. The purpose is to prove, or disprove, that the organisation can move a real metric. Walk is where the kill criterion is exercised for the first time, and an organisation that has never stopped a Walk project has probably not been measuring honestly.

Run: integrated into operational processes. Several use cases, on a shared platform, feeding operational systems. Review shifts from every output to sampling, monitoring and exception handling, which is only defensible because the audit trail and the quality metrics now exist. The portfolio is managed: new use cases enter through a defined intake, existing ones are reviewed against their numbers, weak ones are retired. Run is where the six pillars stop being documents and become routines.

Fly: delegated action within limits. AI systems take actions, not just produce outputs, within explicit authority limits, with humans supervising the process rather than each step. Fly is appropriate where actions are reversible, error costs are bounded, and verification of outcomes is cheap. It is not a maturity badge. Many well-run organisations will run most of their portfolio at Run indefinitely and reach Fly in a handful of tightly bounded workflows, and that is a sound outcome.

The governance required at each stage scales with it. The table below is the practical answer to "what does governance from day one actually mean": not the Run-level apparatus on day one, but the right minimum for the stage you are in, with the next level built before you need it.

Minimum governance per stage. Each column assumes the previous one is in place.

The exit criteria at each gate follow from the table. Crawl exits when usage is visible and shadow AI is measurably displaced, and when there is a shortlist of candidate use cases owned by people who want them. Walk exits when one use case has moved its baseline metric by a margin agreed in advance, under review, with the Walk-level governance demonstrably working. Run exits into Fly, for a specific workflow, when the sampling data shows error rates low and stable enough that exception-based oversight is defensible, and when every action in scope is reversible or bounded. Gates are passed per use case, not per organisation. A firm can be at Run for document extraction and at Crawl for everything customer-facing, and usually should be.

Choosing the first project

The first Walk project is the most consequential decision in the programme. It sets the organisation's belief about what generative AI can do, it trains the team that will run the next ones, and it either establishes or destroys the credibility of the people sponsoring it. It deserves more deliberation than it usually gets.

The common mistake is to choose for value: the use case with the largest theoretical saving, the most visible sponsor, the best story for the board. High-value use cases tend to be high-risk, cross-functional, politically contested and hard to measure. They are the right second or third project. As a first project they combine every factor that put the 95% in their bucket.

The first project should be chosen for learnability: the speed and clarity with which the organisation will find out whether it worked. One criterion matters more than the others.

Choose work where checking the output is much cheaper than producing it.

This asymmetry is the economic engine of every successful generative AI deployment. A clinician who can confirm a draft discharge summary in two minutes, when writing it took fifteen. An analyst who can verify extracted contract clauses against the source in a glance, when finding them took an hour. A developer who can run the tests on generated code. Where verification is cheap, humans in the loop is not a cost but the mechanism. Where verification is as expensive as production (judging a strategy paper, checking a legal argument from scratch) the gain collapses, and the temptation to skip review grows. That is the Deloitte story.

The full set of criteria for a first project:

• Verification is cheap. A competent person can check an output in a fraction of the time it takes to produce one.
• An owner who wants it. A domain-expert manager who asked for help, not one who was assigned an AI initiative.
• A baseline you can measure in weeks. Time per item, error rate, backlog, throughput. Ideally already tracked.
• Enough volume to see a signal. Dozens of items a week, not a handful a quarter.
• Errors are visible and bounded. A mistake is caught before it reaches a customer, a regulator or a patient, and costs little when it happens.
• Data you own and may use. Inside the classification rules, with no new legal basis required.
• A result inside ninety days. Long enough to measure honestly, short enough to keep the kill criterion credible.
• A kill criterion written down before it starts. The number below which the project stops, agreed by the sponsor in advance.

And the disqualifiers. Any one of these should move a candidate to the later list, however attractive it looks:

• The output goes directly to customers or into a regulated decision without review.
• Success depends on several departments changing how they work at once.
• No one can say what "better" would look like in numbers.
• The sponsor's credibility depends on it succeeding, so stopping it will be resisted.
• It requires data that has never been cleaned, consolidated or legally cleared.

A first project that meets these criteria will usually look modest. It is meant to. Its purpose is not to transform the organisation. It is to prove that the organisation can pick a problem, measure it, run AI against it under governance, and make an honest decision at the end. An organisation that can do that once can do it again, at increasing scale. One that cannot will not be rescued by a more ambitious second attempt.

What this means

Three conclusions for the executive deciding how to proceed.

Execution is a sequence, not a launch. The programmes that worked did not start with a big announcement. They started with a sanctioned tool, a policy, and one modest project, and they earned each subsequent stage with evidence. The visible ambition came later, built on a foundation that could carry it. Inverting that order is the most reliable way to join the damage bucket.

Governance and value are the same programme. Every step up in value, from assist to retrieve to extract to act, requires a step up in governance. An organisation that treats the two as separate workstreams, one accelerating and one braking, will find them in permanent conflict. An organisation that treats governance as the capability that unlocks the next tier will find that the two move together.

The capability compounds; the projects do not. A single successful project is a result. A team that knows how to select, measure, govern and stop AI projects is an asset that produces results repeatedly, across model generations and vendor changes. The models will keep changing. The operating model is what the organisation keeps.

Restated as the six-point discipline from Chapter 03, now with the operational meaning attached:

1. 01A narrow, measurable business case: chosen with the first-project criteria, with verification cheaper than production.
2. 02A quantified baseline before deployment: the Walk gate cannot be passed without one.
3. 03Domain experts in the lead: the owner who wants it, accountable under pillar 05.
4. 04Humans in the loop by design: author, reader, reviewer or supervisor, depending on the capability pattern.
5. 05Measured iteration with a kill criterion: stage gates passed on evidence, per use case.
6. 06Governance from day one: the six pillars at the minimum for the current stage, the next level built before it is needed.

What remains is the most practical question of all: given all of this, what does an executive actually do next week? That is Chapter 05.