The Operating Layer

Why this module exists

You cannot govern what you cannot picture.

Executives are routinely asked to fund, approve and defend systems described to them entirely in metaphor. The model "understands" the contract. It "thinks" about the options. It "learns from your data." Every one of those words is doing damage, because each imports a set of expectations that the machine does not meet — and the gap between the expectation and the machine is exactly where projects fail.

This module replaces the metaphors with a mental model that is accurate enough to make decisions on and simple enough to hold in a meeting. There is no mathematics and no code. There is one idea per lesson, and each one has a direct managerial consequence.

1.1 Prediction, not retrieval

Here is the whole thing in one sentence: a language model produces a likely continuation of the text it was given.

It is not looking anything up. There is no document inside it that it consults, no database of facts it queries, no index it searches. It has been exposed to an enormous quantity of text and has settled into a very large set of numerical parameters that encode statistical regularities in that text. When you give it a prompt, it produces what tends to follow text like that — one fragment at a time, each choice conditioned on everything before it.

Almost every surprising behaviour follows from that single fact.

Why it hallucinates. A plausible continuation and a true continuation are different things that usually coincide. When they diverge — an obscure fact, a case citation, a part number — the machine produces the plausible one, because plausibility is the only thing it is optimising. It is not lying and it is not broken. It is doing exactly what it does.

Why it is fluent. Fluency is the easiest property of text to learn, because it is the most regular. Fluency arrives long before accuracy, which is why output sounds authoritative at capability levels far below the ones that make it reliable. This is the single most expensive confusion in enterprise AI.

Why it struggles to say "I don't know." Refusal is a rare continuation in most text. Confident answers are common. The model reproduces that distribution unless something in the system deliberately corrects for it.

Why the same question gives different answers. Selection among likely continuations involves deliberate variation. Two identical requests can produce different outputs. This is not a defect to be reported; it is the technology. It is also why any process that requires the same input to yield the same output must not have a model at that step — a point Module 3 turns into a test.

1.2 Training, context and memory are three different things

This is the distinction most often collapsed in planning meetings, and collapsing it produces expensive plans.

Three consequences worth stating to a board:

"We'll train it on our data" is usually the wrong plan. What people almost always want is for the system to know things about their business. Retrieval delivers that: keep your documents where they are, find the relevant ones at the moment of the question, and put them in the context. Fine-tuning does not reliably install facts, it is stale the moment your data changes, and it turns a content problem into a machine-learning project.

Fine-tuning is for form, not for facts. It is the right tool when you need consistent structure, house style or a narrow output format, and the wrong tool when you need the system to know today's price list.

A model has no memory of you. Anything that feels like memory is a system storing something and re-supplying it. That is a design decision with retention and deletion consequences — which is precisely why Module 6 treats it as a governance control rather than a feature.

1.3 Model, workflow, agent

These three words are used interchangeably in the market and mean quite different things. The course uses the distinction Anthropic draws, because it is the one that maps to cost and risk:

Agency is a dial rather than a switch, and every notch along it trades predictability for flexibility while adding latency and cost. Anthropic's own guidance is unusually direct about this, given their commercial interest: find the simplest solution possible, and increase complexity only when needed.

The managerial version: an agent is what you use when you genuinely cannot enumerate the steps in advance. If you can draw the flowchart, build the flowchart. A system that decides its own steps will also decide steps you did not anticipate, and you will discover them in production.

Most enterprise value sits in workflows. Most enterprise disappointment comes from buying agents.

1.4 The economics that should shape your plan

Two forces set the terms of every AI decision you will make, and they point in opposite directions.

Capability rises unevenly and unpredictably. Nobody, including the labs, can tell you reliably what will be possible in eighteen months. Plans that depend on a specific future capability are bets, and should be labelled as such.

Price falls fast and predictably. This is the more useful half. At a fixed quality bar, the cost of inference has been falling by roughly an order of magnitude per year — an analysis widely cited since 2024, and one that has broadly held since. Concretely: capability comparable to the frontier models of 2023, which cost tens of dollars per million units of input text, is available in 2026 for a small fraction of that. Three forces compound to produce it: algorithmic efficiency, cheaper hardware, and aggressive competition including open-weight models.

This asymmetry — unpredictable capability, predictable price — also tells you how to sequence. Build the parts that do not depend on future capability (the data movement, the integrations, the governance) now, because they are the slow parts and they do not get cheaper on their own. Defer the parts that depend on capability you do not yet have.

1.5 The jagged frontier

The most important research finding for a manager in this field is not about what models can do. It is about the shape of what they can do.

Fabrizio Dell'Acqua and colleagues at Harvard ran a field experiment with more than seven hundred Boston Consulting Group consultants. On tasks inside the model's competence, consultants using AI produced work of substantially higher quality — up to around 40% better on some measures — and produced it faster. On a task that looked similar but sat outside the model's competence, consultants using AI performed worse than the control group without it.

The researchers named the boundary the jagged technological frontier: capability is not a straight wall with everything easy on one side and hard on the other. It is an indented coastline. Tasks that appear equally difficult to a human sit on opposite sides of it, and there is no reliable way to tell from the outside which is which.

Set that beside a second finding. Brynjolfsson, Li and Raymond studied more than five thousand customer-support agents given an AI assistant. Average productivity rose about 14%, but the distribution is the story: the largest gains, above 30%, went to the least experienced workers, while the most experienced gained little. The tool distributed the tacit knowledge of the best performers to everyone else.

Read together, the two studies give you a delegation rule:

You cannot delegate to AI by category. You can only delegate by tested task.

"Use AI for marketing" is not a decision — it is an aspiration that will straddle the frontier and produce both of the results above at once. "Use AI to produce the first draft of product descriptions, reviewed by a category manager, measured against last quarter's conversion" is a decision, and it can be evaluated.

The second consequence is subtler and matters for how you staff: because AI compresses the gap between novice and expert, the scarce skill shifts. It moves away from producing the work and towards specifying what good looks like and detecting when the output is wrong — which is judgement, and which is where Module 9 picks the thread up.

1.6 What to stop saying

A short list of phrases worth retiring from your meetings, because each hides a decision:

Exercise — Explain it to a sceptic

Time: 45 minutes. Produces the artefact for this module.

Write one page explaining your organisation's main proposed AI use case to an intelligent, sceptical colleague who does not work in technology — your CFO, a clinician, a plant manager.

Constraints, each of which enforces something from this module:

1. No metaphors of understanding, thinking or learning. If you need one, you have not identified the mechanism.
2. Name what goes in and what comes out. Precisely. Which text, from which system, producing what.
3. Say where the knowledge comes from — training, retrieval, or the context you supply.
4. State where this task sits relative to the frontier, and what evidence you have for that placement.
5. Name one thing that would make it fail, and what would happen next.

If you cannot complete point 5, you do not yet understand the use case well enough to fund it. That is a useful thing to discover on one page rather than in month four.

Self-check

1. A colleague reports that the system "made up a customer reference number." Which property of the technology explains this, and why is "make it stop hallucinating" not an actionable instruction?
2. Your team proposes fine-tuning a model on five years of support tickets so it can answer questions about current policy. What is wrong with the plan, and what would you propose instead?
3. Give an example from your own work of two tasks that look equally difficult to a person but probably sit on opposite sides of the jagged frontier.
4. A vendor's proposal describes an "autonomous agent." What single question tells you whether an agent is warranted?
5. A use case is rejected today because inference costs five times what the process is worth. What should happen to it, and when?

Further reading

• Anthropic, Building Effective Agents, 2024 — the workflow/agent distinction and the case for simplicity.
• Fabrizio Dell'Acqua et al., Navigating the Jagged Technological Frontier, Harvard Business School Working Paper 24-013, 2023.
• Erik Brynjolfsson, Danielle Li and Lindsey R. Raymond, Generative AI at Work, NBER Working Paper 31161, 2023.
• Martin Zinkevich, Rules of Machine Learning, Google, 2016 — written for engineers, but Rules 1 to 3 are management reading.

Why this module exists

Executives are told the problem is hype and the solution is scepticism. That advice is useless, because it supplies no method. It only changes the mood in the room — and a sceptical executive with no method makes exactly the same decisions as a credulous one, just more slowly.

This module treats the market as an economic system with knowable properties. Three forces explain almost all of the behaviour you are seeing, and none of them is stupidity. Once you can name them, you can evaluate a claim in minutes instead of quarters, and you can explain your reasoning to a board without sounding like a pessimist.

2.1 What the numbers actually say

Four findings frame the field. Take them together, and take their limits seriously — a course that quotes failure statistics uncritically is committing the error it is warning about.

Gartner, June 2025. More than 40% of agentic AI projects will be cancelled by the end of 2027, driven by escalating costs, unclear business value and inadequate risk controls. Gartner also names the supply-side behaviour — agent washing, the relabelling of existing chatbots and robotic process automation as agents — and estimates that of the thousands of vendors selling agentic AI, roughly 130 are real. Limitation: this is a forecast, not a measurement, and it is drawn substantially from a poll of self-selected webinar attendees.

MIT Project NANDA, July 2025. Roughly 95% of enterprise generative AI pilots produced no measurable business return, against thirty to forty billion dollars of spending. Limitation: "no measurable return" partly measures how few organisations set up measurement in the first place. That is a real finding, but it is a finding about measurement discipline as much as about the technology.

McKinsey, State of AI. The large majority of firms now use AI somewhere, yet only around 39% report EBIT impact at enterprise level, and the strongest correlate of impact is not model choice or vendor — it is fundamental workflow redesign. Limitation: self-reported attribution of profit to a technology is among the least reliable numbers in management research. Treat the ranking of factors as more robust than the level.

FactSet, Q1 2026. Of the 498 S&P 500 companies holding earnings calls, 337 mentioned "AI" — 68%, the highest in a decade against a ten-year average of 103. And companies that mentioned it outperformed those that did not over the following period. Limitation: correlation with share price is not causation, and the composition of the mentioning group is skewed towards technology.

Read the four together and one reading survives all the caveats:

The industry is not failing at AI. It is failing at placement, measurement and follow-through — while the market pays for the word.

That last clause is not cynicism, it is the FactSet data. Once saying the word is rewarded, everything downstream is people responding correctly to a price signal.

2.2 Force one: the demo stopped costing what the system costs

For every enterprise technology before this one, building a convincing demonstration was roughly as expensive as building the thing. You could not demo an ERP without an ERP. You could not fake a warehouse management system in a conference room; the pallets either moved or they did not. The demo was therefore evidence, because producing it required having solved the problem.

A language model severs that link. An afternoon and a well-crafted prompt produce something nearly indistinguishable from a working system, because in both cases the output is a paragraph of confident text.

The demo used to be evidence. Now it is a costume.

Notice who this disarms, because it is counterintuitive. A CFO can read a profit-and-loss statement. An operations director can walk a floor and tell you within ten minutes whether something is real. A CTO can read an architecture diagram and find the lie in it. But nobody in that room, at any level of seniority, can look at a chat window producing fluent paragraphs and tell you whether it will hold up on Tuesday against four thousand real messages.

Seniority normally buys pattern recognition. Here it buys almost nothing — and the pretence that it does is how expensive decisions get made quickly.

The practical response is not to refuse demos. It is to insist that a demo is the bottom of the evidence ladder, and to state out loud what would move it up.

2.3 Force two: you are buying in a lemon market

In 1970, George Akerlof asked a question about used cars that turned out to be about a great deal more: what happens to a market when the seller knows the quality and the buyer does not?

His answer runs as a mechanism, and it is worth following step by step because your own instincts are in it:

1. Buyers cannot distinguish good from bad, so they will only pay a price reflecting average quality.
2. Sellers of genuinely good goods, worth more than the average, decline to sell at that price and exit.
3. Average quality therefore falls, so the price buyers will pay falls further.
4. More good sellers exit. The market unravels toward the lemons.

Akerlof shared the Nobel Prize for this in 2001. Now place Gartner's estimate beside it — roughly 130 real vendors among thousands claiming agentic capability. That is not a scandal, and it is not a moral failing peculiar to this industry. It is the predicted equilibrium of a market in which making a claim is free and verifying one takes a quarter.

You are the buyer in that market. And here is the uncomfortable part: your instinctive defences — pay the average, hedge, run a small pilot with a small budget — are the textbook-correct response to information asymmetry, and they are precisely the behaviour that produces underfunded pilots that never leave the sandbox. Rational individual caution aggregates into the 95% statistic.

Akerlof did not end his paper with outrage. He ended it with remedies, and there were three:

You cannot fix an information-asymmetric market by complaining about vendors. You fix it by becoming cheap to verify — a theme Module 7 turns into a scorecard.

2.4 Force three: the career arithmetic is asymmetric

Keynes wrote the line in 1936, about investment committees, and it has not aged:

Worldly wisdom teaches that it is better for reputation to fail conventionally than to succeed unconventionally.

Count the payoffs honestly inside your own organisation. An AI project that fails is a project that failed; everyone's failed, the market is hard, next item. Not having one, in 2026, is treated as a personality trait. Nobody has been called into a board meeting to explain a pilot. Plenty of people have been called in to explain the absence of one.

This is not a feeling. Two surveys make it measurable:

• Dataiku's survey of chief executives found that 74% believe they could lose their job within two years if they do not deliver measurable AI gains.
• WRITER, with Workplace Intelligence, surveyed 2,400 employees and C-suite leaders in April 2026: 75% of executives said their own company's AI strategy is "more for show" rather than genuine internal guidance, naming public relations and investor relations as the reason it exists. Thirty-nine percent had no formal plan for turning any of it into revenue.

Three quarters, admitted, by the people who commissioned the strategy.

Stack the three forces and the behaviour stops looking like madness and starts looking like an equilibrium: claims that are free to make and expensive to verify, evaluated by people who structurally cannot verify them, inside a system where being conventionally wrong costs nothing.

The leadership consequence is the useful part, and it is small and local. You cannot change the market. You can change what is rewarded in the one room you control — which is why Module 9 treats incentives as a governance instrument rather than a soft topic.

2.5 The evidence ladder

Here is the method the module promised. Every claim — from a vendor, a consultant, or your own team — sits on one of five rungs. The rung determines the size of commitment it justifies.

Two rules make this operational.

Rule one: name the rung out loud. Not as an accusation — as bookkeeping. "This is a rung-one claim, which is fine at this stage; here is what would take it to three." It converts a sales conversation into a shared workplan, and vendors who cannot climb the ladder disqualify themselves without an argument.

Rule two: pre-registration is what separates rung four from rung one. A pilot whose success metric is chosen after the results are in is not a pilot. It is a demonstration with a longer runway, and it will be interpreted favourably by whoever sponsored it. Write down the metric, the baseline, the sample and the decision rule before anything runs, and have someone who is not the sponsor hold the document.

2.6 Reading a claim in the meeting

Four questions, in order. They take about two minutes and work without any technical background.

1. "What is the denominator?" — 40% better than what, measured over how many cases? A percentage without a base is decoration.
2. "Whose data was it on?" — Yours, theirs, or a public benchmark? Benchmark performance transfers to your documents far less reliably than anyone hopes.
3. "What happened to the cases it got wrong?" — A vendor who cannot describe their failure modes has not looked. This question separates rungs one and two from three and above faster than any other.
4. "Who else has stopped using it, and why?" — Ask for a reference that churned. The refusal is itself information.

Exercise — Put a live proposal on the ladder

Time: 45 minutes. Produces the artefact for this module.

Take the most recent AI proposal that reached your desk — vendor or internal, it does not matter.

1. List its load-bearing claims. The three or four that, if false, would change your decision. Ignore the rest.
2. Place each on the ladder and mark the rung.
3. Find the weakest load-bearing claim — the one carrying the most weight from the lowest rung. This is your project's actual risk, and it is rarely the one on the risk register.
4. Write the single question that would move it up one rung, and send it today.
5. Draft the pre-registration for the pilot you would run: metric, baseline, sample, decision rule, and who holds the document.

Keep the ladder. It applies unchanged to the vendor scorecard in Module 7 and to the evidence dimension of the capstone rubric.

Self-check

1. A vendor reports "a 40% improvement." Name the two questions that most efficiently establish what that means.
2. Why does individually rational buyer caution aggregate into the 95% pilot-failure statistic?
3. What single procedural step distinguishes a pilot from a demonstration, and why must it come first?
4. Your team says a competitor "has already deployed this." What would you need to see to place that claim above rung two?
5. Which of Akerlof's three remedies is most available to you as a buyer this quarter, and what would you do with it?

Further reading

• George A. Akerlof, The Market for "Lemons": Quality Uncertainty and the Market Mechanism, Quarterly Journal of Economics, 1970.
• John Maynard Keynes, The General Theory of Employment, Interest and Money, Book IV, Chapter 12, 1936.
• Gartner, Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, June 2025.
• MIT Project NANDA, The GenAI Divide: State of AI in Business 2025, July 2025.
• FactSet Insight, Highest Number of S&P 500 Earnings Calls Citing "AI" Over the Past 10 Years, Q1 2026.

Why this module exists

Most organisations do not have an AI problem. They have a placement problem.

The failure mode is rarely that a model could not do the job. It is that a model was assigned a job that a database query, a scheduled script, or a single rule could have done more cheaply, more reliably, and without a governance review. The result is a system that costs more, breaks more often, and cannot be explained to an auditor — doing work that was never hard.

This module gives you a repeatable test for that decision. It takes about ninety seconds per step, requires no technical background, and produces two artefacts you can put in front of a board.

3.1 The wall and the window

A building needs walls and it needs windows.

Brick is cheap, boring and utterly dependable. Put a load on it and it holds, every time, in the same way. Glass is expensive, beautiful, and does the one thing brick cannot: it lets what is outside come in.

Determinism is your load-bearing wall. A model is your glass.

Nobody argues about this in construction. In software we have started building load-bearing walls out of glass, because glass photographs better — and then we are surprised when the building settles.

The useful question is therefore not "can AI do this?" Modern models can do a great deal, including much they should not be trusted with. The useful question is "is this a wall or a window?"

The naming problem

What makes a model genuinely irreplaceable is narrower and stranger than most executives assume. State it as a rule:

You can only write a rule for a category you have already named.

Consider a real example. An online retailer's return rate rises four points in two weeks. The reason sits in four thousand free-text support messages, expressed like this:

• "Small fits."
• "Runs narrow."
• "Tighter than usual."
• "Had to send back for the next size."

Three of those four sentences share no words at all. You cannot write a pattern-match for a synonym you have not thought of — and you will not think of it, because if you already knew why returns had risen you would not be searching.

This is the boundary:

Rules answer the questions you have. Models find the questions you do not.

Determinism handles what you can name. A model earns its place where naming is the problem itself.

3.2 Questions 1–3: does a model fit?

The first three questions establish whether the shape of the work matches what a language model is for. They are about the problem, not the budget.

Question 1 — Is the input unstructured?

Free text, speech, images, a PDF someone scanned at an angle, a handwritten delivery note. If the input already has columns and types, you do not have a model problem — you have a query.

The trap: data that looks unstructured because it lives in a bad system. A CSV export with inconsistent column names is structured data with a cleaning problem. Fix the pipe, do not hire a model to read the mess.

Question 2 — Can the branches be enumerated in advance?

If you can write the complete list of possible outcomes on a whiteboard, write them in code instead. A finite branch set is a rule engine wearing a costume.

"Approve, reject, or escalate" is three branches. That is a rule. "Summarise why this customer is unhappy" has no enumerable branch set at all. That is a model.

Question 3 — Is the output language?

A summary, an explanation, a draft, a classification into fuzzy categories, a translation. If the output is a number, a date, or a true/false value, be extremely suspicious of any model standing near it.

Scoring. Three "no" answers: write code. Two: still write code. One "no": the case is arguable, and you should be able to state the argument in a sentence.

3.3 Questions 4–5: is it worth doing?

The first three questions tell you a model can do the work. They say nothing about whether you should deploy it. Two further questions decide that, and they are the ones most often skipped.

Question 4 — What does being wrong cost, and can you take it back?

Sort every candidate step on two axes: the cost of an error, and its reversibility.

A misclassified support ticket is a shrug. A mistoned collections email to your largest account is a phone call from your chief executive. Note the shape of the answer: it is never "do not use AI here." It is "do not use AI unsupervised here." The model still does the work; a named human signs.

This is what an approval gate is for, and Module 5 designs them properly.

Question 5 — How many times must this judgement be made?

Four thousand tickets justify a model. Twelve tickets a month justify an afternoon and a coffee — and you will learn more reading them yourself than any summary would tell you.

Rule of thumb. If one person could clear a month's volume in an afternoon, you do not have an AI problem. You have an afternoon.

This question kills more proposals than the other four combined, and it kills them honestly. It is also the question your finance director will ask first, so it is better to arrive with the answer.

3.4 The arithmetic of chained steps

There is a harder reason to keep models out of load-bearing positions, and it is multiplication.

When steps are chained, their reliabilities multiply. They do not average.

A step that is correct 95% of the time is excellent performance for a language model on a judgement task. Chain them:

Think of connecting flights. Every leg is 95% on time, which sounds fine. Book five legs and you have roughly a three-in-four chance of making the wedding. Book twenty and you should have driven.

This is why placement is not an aesthetic preference. Every step handed to a model moves that step from 1.0 to 0.95-something, and those numbers compound along the whole chain. A deterministic step is not merely cheaper — it is a 1.0 in the product. It dilutes nothing downstream.

Two design consequences follow, and you should be able to state both:

1. Shorten model chains. Prefer one model step doing a well-specified job over five model steps reasoning their way along. Length is risk.
2. Put deterministic checks between model steps. A rule that validates the model's output before the next step converts an unbounded error into a caught one.

There is also the unglamorous cost, which tends to be what actually kills a project in month four: a database query answers in milliseconds for a rounding error, while a model call answers in seconds and bills per unit of text, every time, forever.

3.5 The opposite mistake

The test cuts both ways, and teams fail on the other side of it just as expensively.

Somewhere in your organisation, a team maintains forty pattern rules for the phrase "runs small." Then sixty. Then someone adds a second language. Then the person who wrote them leaves, and nobody dares delete any, so the file only grows.

A rule list that grows every week is a model with a worse interface, no evaluation set, and one maintainer who is quietly updating their CV.

If a team is hand-maintaining a taxonomy of human phrasing, they have already built a bad model. Buy a good one.

A useful diagnostic: plot the maintenance curve. If the number of rules needed per month is flat or falling, rules are the right tool and the domain is genuinely enumerable. If it rises without converging, the domain is open-ended and you are paying salary to approximate a model.

3.6 Where the test says yes: customer engagement

Executives often assume this test is an argument against AI in customer-facing work. It is the opposite — customer engagement is where the three shape questions most often return a clean "yes," because customers arrive expressing themselves in language you did not anticipate.

Run the test across a customer journey and the pattern is consistent:

Notice the last two rows sitting side by side in the same conversation. The eligibility decision and the message drafted about it belong to different technologies. Most disappointing "AI customer service" projects fail precisely because they hand both to the same component.

3.7 The bill of materials

Nobody calls their car a "GPS car." The GPS is one component among hundreds; it happens to be the one you look at, so it does not get to name the vehicle.

Yet a four-step automation with one model step routinely gets funded, staffed and reported as "the AI project." That gap between what a system does and what it is called has acquired names — Gartner calls the vendor version agent washing; the US Securities and Exchange Commission calls the investor version AI washing and has fined firms for it.

The discipline that prevents it is mechanical:

1. List every step. Not the goal — the steps. Almost always between four and seven.
2. Label each one: movement, rule, integration, or judgement on unstructured input.
3. Defend every judgement label aloud, one at a time.

If you cannot say in one sentence why a step needs a model, the step does not need a model.

3.8 How to defend the answer

The most common objection to this test is political rather than technical: will saying "most of this is not AI" make my proposal look unambitious?

The experience is the reverse. Stating the line yourself converts you from someone selling a technology into the person in the room doing the arithmetic. A sentence that has never lost an argument:

"Three of these four steps are ordinary engineering, and we built them that way deliberately. One step reads four thousand sentences no rule can catch — that is the step that needed a model. Had we used a model for the other three, you would be paying more for a system that is less reliable."

The proposals that die in the room are the ones where the honest answer is "well, AI is more flexible."

Exercise — Label your portfolio, then build your no-list

Time: 45–60 minutes. Produces the artefact for this module.

Part A — The labelled portfolio. Take every AI project, pilot and vendor demo currently live in your organisation. For each one:

1. Write the steps. Not the goal — the steps.
2. Label each step: movement, rule, integration, or judgement on unstructured input.
3. Write one sentence of justification for every step labelled judgement.
4. Compute the fraction: model steps ÷ total steps.

Part B — The no-list. List the things you have decided not to apply a model to, with one line each on why, referencing which of the five questions decided it.

A yes-list proves you complied with pressure. Only a no-list proves you evaluated. When a board sees four proposals turned down on stated grounds, the fifth — the one you are asking them to fund — stops sounding like enthusiasm and starts sounding like a finding.

What good looks like. Most portfolios come back between 10% and 30% model steps. If yours comes back at 80%, you have either an unusual business or an unexamined deck. If it comes back at 0%, check Question 1 again — you may be under-using models on genuinely unstructured work.

Self-check

1. A process step takes a structured order record and decides whether the order exceeds a credit limit. Which question disqualifies a model, and why?
2. Your team says a step "needs AI because the rules keep changing." Which failure mode might this be, and what evidence would distinguish the two?
3. A vendor proposes a nine-step autonomous agent. Assuming a generous 95% per step, what is the expected end-to-end success rate, and what would you ask them to change?
4. Give an example from your own organisation of the naming problem — where you cannot write the rule because you do not yet know the category.
5. Why is "do not use AI here" almost never the right output of Question 4?

Further reading

• Martin Zinkevich, Rules of Machine Learning: Best Practices for ML Engineering, Google, 2016 — Rule #1: "Don't be afraid to launch a product without machine learning."
• Anthropic, Building Effective Agents, 2024 — on finding the simplest solution and the workflow/agent distinction.
• Gartner, Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, June 2025 — on agent washing and misapplied use cases.
• MIT Project NANDA, The GenAI Divide: State of AI in Business 2025 — on the share of pilots producing no measurable return.

Why this module exists

The gap between a working prototype and a deployed system is almost never the model. It is integration: where the data lives, what it costs to move, who owns the system of record, which team's roadmap you are now on, and what breaks when any of it changes.

Executives who cannot picture this consistently underestimate delivery by a factor that ruins roadmaps — and, more damagingly, cannot tell the difference between a project that is late and a project that is impossible.

This module gives you the picture. You will not build anything. You will be able to ask the four or five questions that surface the real cost before you commit to a date.

4.1 The four layers

Every AI-enabled process, however it is marketed, decomposes into four kinds of work. You met these labels in Module 3; here they become an architecture.

Two observations that change how you read a proposal.

The cost is not where the attention is. In most enterprise deployments, the judgement layer is a small fraction of the build and the overwhelming share of the discussion. Movement and integration consume the schedule, because they touch systems you do not control.

Each layer fails differently, so each needs a different control. A rules failure announces itself. A movement failure is silent — the number is simply yesterday's, and everyone acts on it confidently. A judgement failure is worse still, because the output is fluent. Module 5 designs for this; here, note that "monitoring" is not one thing but four.

4.2 What an API actually is

An API is a contract between two systems: if you ask in exactly this form, I will answer in exactly that form. Nothing more mystical than that.

Three things executives should take from the definition, because each has appeared in the post-mortem of a late project:

"We have an API" and "we can integrate" are different claims. The first says a door exists. The second says the door is wide enough, opens often enough, and admits the data you actually need. The questions that distinguish them:

• What is in it? Systems frequently expose 20% of their data through an API and keep the interesting 80% inside.
• How often may we ask? Rate limits turn a five-minute job into an overnight one.
• Who authorises? Service accounts, permissions, and whether the API can see what a given user is allowed to see.
• What happens when it changes? Versioning and deprecation notice. Every integration is a standing maintenance obligation on someone else's release schedule.

Integration is a relationship, not a task. The right question to a vendor is never "do you integrate with SAP" — it is "which objects, in which direction, at what frequency, and what happened the last time SAP changed them."

Every boundary is a governance boundary too. Each hop where data leaves a system you control is a place where Module 6's residency, transfer and retention questions attach.

4.3 Tool use, and the direction that matters

Modern AI systems do not only produce text; they can be given the ability to call things. The model emits a structured request — "look up order 4471" — the surrounding system executes it against a real API, and the result comes back into the conversation. This is tool use, and it is what separates a chat interface from a system that does work.

The Model Context Protocol (MCP) standardises how tools are described and offered to a model, so that a capability built once can be exposed to different systems without bespoke glue each time. Treat it the way you would treat any interoperability standard: valuable because it reduces lock-in and integration cost, not because it is intelligent.

The design principle underneath is worth more than the technology, and it is the one to carry into every architecture review:

The model asks the pipeline for the number. The pipeline never asks the model whether one number is larger than another.

Direction is a decision. When a model calls a deterministic tool, you get the model's flexibility at the edges and the tool's exactness at the core — arithmetic stays arithmetic, policy stays policy, and the model handles the language around them. Invert it, and you have put a probabilistic component inside your load-bearing wall, with the reliability consequences Module 3 quantified.

A practical corollary for vendor conversations: ask which side of each boundary the decision is made on. "The agent checks eligibility" and "the agent asks the eligibility service" are different systems with the same sentence.

4.4 Retrieval, fine-tuning, or better instructions

Almost every "make it know our business" request resolves to one of three answers. Choosing correctly saves months.

The default is retrieval. It keeps the source of truth where it already is, produces citations — which matter enormously for both trust and Module 6's audit obligations — and updates the moment the underlying document does.

Retrieval quality, however, is mostly a content problem rather than an AI problem, and this is the finding that surprises teams most. If your policies live in six conflicting versions across three shared drives, retrieval will faithfully find the wrong one. The work is chunking, permissions, freshness and deduplication — unglamorous information management that no model fixes. Budget it explicitly, because it is usually the true critical path.

4.5 Where your data lives decides the architecture

Two distinctions carry most of the weight.

Systems of record versus systems of engagement. Your ERP, LIMS, EHR or core banking platform is a system of record: authoritative, change-controlled, slow to modify, and correctly protected by people whose job is to say no. Systems of engagement — portals, inboxes, chat — are where people meet the work. AI belongs, almost always, in the engagement layer reading from the record layer. Proposals that require writing into a system of record should be scoped as a different, slower project with different approvers, and they usually are not what the value depended on anyway.

Move the data, or move the computation. If data cannot leave a jurisdiction or an environment, you do not send it to a model — you bring a model to it. This is the point at which Module 6's residency obligations stop being a constraint on the design and become the design.

That produces a small deployment ladder:

The economics have shifted the calculus here. Because smaller open-weight models have become genuinely capable at narrow tasks, "run it yourself" is no longer synonymous with "accept much worse quality" — for a bounded job such as redacting identifiers or classifying a document type, a small local model is often the right answer on both cost and compliance. The rule of thumb: frontier models for open-ended judgement, small local models for narrow, high-volume, sensitive steps.

4.6 Build, buy, or assemble

Most build-versus-buy discussions omit the option that fits the largest number of enterprise cases.

• Buy a complete application when the process is standard and not a source of advantage. Payroll, expenses, service-desk deflection.
• Build only where the process itself is the advantage, and be honest that you are taking on a permanent maintenance obligation.
• Assemble — the missing third option — when you already own most of the pieces. The movement layer exists in your data platform. The rules live in systems of record. The integration points are already built for other purposes. What is missing is a judgement step and the governance around it.

Assembly is usually the fastest route to a working system, and it is under-proposed for a simple structural reason: nobody sells it to you. Module 3's bill-of-materials discipline is what reveals it — once the steps are labelled, you can see how many you already have.

4.7 The questions that surface the real cost

Five questions, in this order, applied to any proposal. They take twenty minutes and routinely move an estimate by a factor of two.

1. Which systems does the data pass through, and who owns each one? Ownership means a roadmap and a queue, not just a name.
2. What is the slowest hop? Batch windows and rate limits set your latency ceiling regardless of how fast the model is.
3. Where does data cross a boundary — vendor, jurisdiction, network? Each crossing is a governance item and a failure point.
4. What has to be written back, and who approves writes to that system? Read-only projects and write-enabled projects are different projects.
5. Which pieces do we already own? This is the assembly question, and it is the one nobody asks first.

Exercise — Draw your integration map

Time: 60 minutes. Produces the artefact for this module.

Take the workflow you labelled in Module 3 and draw it as an integration map.

1. Draw every system the data passes through, in order, left to right. Not conceptual boxes — the actual systems, by name.
2. Label each hop with its layer: movement, rules, integration, judgement.
3. On each hop, record: who owns it, whether an API exists, the frequency it supports, and the slowest window.
4. Circle every boundary crossing — vendor, jurisdiction, network.
5. Mark the deployment decision for each judgement step: vendor API, your tenancy, or local.
6. Underline what you already own.

Then answer one question in writing: what is the slowest hop, and does the value case survive it? If the answer is no, you have saved a quarter.

Self-check

1. A vendor says their product "integrates with your ERP." Name three questions that establish whether that is true in a way that matters.
2. Why does the direction of a tool call — model calling the service, versus service calling the model — change the reliability of the system?
3. A team proposes fine-tuning so the assistant "knows our current pricing." What is wrong, and what is the alternative?
4. Under what circumstances does a data residency obligation stop being a constraint and start being the architecture?
5. In your own estate, name one process where the assembly option is available and has not been proposed.

Further reading

• Model Context Protocol specification and documentation, 2024–.
• Anthropic, Writing Effective Tools for AI Agents, 2025.
• Martin Zinkevich, Rules of Machine Learning, Google, 2016 — Rules 2 and 4, on infrastructure before modelling.

Why this module exists

"Agentic" has become a category label rather than a design decision. Systems are described as agents the way software was once described as cloud — as a statement of modernity rather than of architecture.

This module treats autonomy as what it is: a set of choices, made step by step, each with a cost. How much independence at which step, guarded by whom, failing into what, and evidenced how.

The output is a specification. Not a diagram of boxes, but a document precise enough that a vendor could build against it and an auditor could read it.

5.1 Autonomy is a dial, not a switch

The first mistake is applying one autonomy setting to a whole process. Real designs vary it step by step.

Two rules that come from watching this go wrong:

Most of the value is at levels 2 and 3. They capture the labour saving — the drafting, the assembly, the reading of four thousand messages — while keeping a human on the consequence. Levels 4 and 5 add modest additional efficiency and a great deal of risk surface.

Most incidents come from a step being set at 5 because the demo worked. A demonstration exercises the common case. Autonomy is priced by the uncommon one.

5.2 Approval gates are decision rights, made explicit

A gate is not a checkbox added for comfort. It is an organisational decision right that already exists — someone in your company is already accountable for this class of decision — written into the system so that it survives automation.

That framing does real work. It tells you who the approver must be (the person who holds the right today, not whoever is free), and it tells you when a gate is missing (when the system takes an action nobody currently has the authority to take unilaterally).

Four rules cover almost every case, and they compose:

The fourth is the one most often neglected and most often fatal. A gate that requires the approver to log into a new system will be batched, rushed at the end of the week, and eventually delegated to whoever has time. Convenience is not a nicety here; it is the control.

The override test

The hard question, and the one that connects this module to Module 6:

Can the approver actually change the outcome?

Three sub-questions establish it:

1. Do they see the inputs the system used — not just its output?
2. Do they have time at real volume? Four hundred approvals a day at thirty seconds each is three and a half hours. If nobody has that time, the gate is fiction.
3. Has anyone ever overridden it? Pull the number. A gate with a 0% override rate over months is either a perfect system or a rubber stamp, and it is not a perfect system.

A gate that fails the override test is worse than no gate, for two reasons. Operationally, it creates false assurance — everyone believes the output was reviewed. Legally, as Module 6 shows through the SCHUFA reasoning, a nominal human step does not remove a decision from the automated-decision rules. You carry the obligation and get none of the protection.

5.3 Design the failure path first

Systems without a designed failure path do not fail gracefully. They fail silently, which is worse, and silent failure is the usual reason a promising pilot is quietly abandoned six months later — not because it broke loudly, but because trust drained without anyone being able to point at an incident.

For every step, answer four questions before deployment:

1. What does wrong output look like here? Be specific. Not "an error" — "an appeal letter citing the wrong policy section," "a summary that omits the complaint."
2. Who notices, and how? A person, a validation rule, a downstream system, or nobody.
3. How quickly? Same minute, next day, next quarter, never.
4. What happens next? The recovery path, and who owns it.

Two patterns are worth building in by default.

Deterministic validation after judgement. The cheapest reliability improvement available: a rule that checks the model's output before it moves on. Does the drafted letter reference a policy section that exists? Does the extracted date fall in a plausible range? Is the total equal to the sum of the lines? These catch a large share of failures at almost no cost, and they convert an unbounded error into a caught one.

A designed escape hatch. Every workflow needs a path for "this case is not like the others." Without one, the system will handle unusual cases badly rather than declining them. Instruct the system to escalate on low confidence or on inputs outside its defined scope, and — critically — make sure the escalation queue has an owner. An escalation queue nobody reads is a silent failure with extra steps.

5.4 Traces and spans: the evidence layer

This section introduces vocabulary you will be held to in vendor conversations, so it is worth being precise rather than approximate.

A trace is the complete record of one run of a workflow, end to end — one denial processed, one quote produced, one ticket answered. It is the unit you look at when someone asks what happened to this case?

A span is one timed step inside that trace. Retrieving the policy document is a span. The model call that drafts the letter is a span. The approval is a span. Each span records when it started, how long it took, what went in, what came out, and whether it failed.

Spans nest. A trace is not a flat list but a tree: the drafting step contains the retrieval it triggered, which contains the two database queries the retrieval made. That structure is the whole point — it is what lets you answer which part was slow or wrong, rather than only that the run was.

Traces serve three masters at once, which is why they are the highest-return piece of infrastructure in this entire course:

The minimum trace schema:

Note the retention consequence: traces contain the data the system processed. They inherit its residency, retention and deletion obligations, and they are frequently forgotten in the data map. Include them in the Module 6 control map explicitly.

5.5 Reliability engineering for chains

Module 3 established the arithmetic: chained step reliabilities multiply. Five steps at 95% is 77%; twenty is 36%. Three design moves follow directly.

Shorten the model chain. Prefer one model step doing a well-specified job over five model steps reasoning their way along. Every additional model step is another multiplication by a number below one. Length is risk.

Interleave deterministic steps. A rule between two model steps is a 1.0 in the product and, if it validates, it truncates error propagation. The strongest workflows alternate: judge, check, act, check.

Set the acceptance threshold before launch. Decide in advance what performance makes this worth deploying — and what performance triggers rollback. Negotiating that number after the results are in is how systems get deployed at levels nobody would have approved in advance.

One further point, often missed: measure the end-to-end rate, not the per-step rate. Vendors quote per-step accuracy because it is flattering. Your customer experiences the product of the chain.

5.6 Where customer engagement fits

Module 3 showed that customer-facing work is where the shape test most often returns yes. Design adds a caution: customer-facing steps almost never belong above autonomy level 3.

The asymmetry is that a customer interaction is both irreversible and reputationally amplified. A wrong internal summary is corrected in a meeting. A wrong message to a customer is screenshotted.

The pattern that works: the model does the reading, the retrieval and the drafting — the parts that consume the agent's day — and the human does the sending. That typically removes 70–80% of handling time while leaving every outbound communication signed by a person. It is less impressive in a demo than full automation, and it is the version that is still running a year later.

Exercise — Write the specification

Time: 90 minutes. Produces the artefact for this module.

Take the workflow you labelled in Module 3 and mapped in Module 4, and specify it.

1. Step table. Every step, its layer, its autonomy level, and one sentence on why that level.
2. Gate specification. For each gate: the rule (threshold, counterparty, content, channel), the named approver, the channel they already work in, and the expected volume in minutes per day.
3. Override test. For each gate, answer the three sub-questions. If any fails, redesign the gate or lower the autonomy level.
4. Failure table. For each step: what wrong looks like, who notices, how fast, recovery path.
5. Escape hatch. The condition that routes a case out, and the named owner of that queue.
6. Trace schema. Which fields you will record, and their retention period.
7. Acceptance criterion. One measurable claim with a baseline, a date, a threshold and a rollback action.

The specification is complete when someone who was not in the room could build against it and disagree with it. Vagueness is what makes a document unarguable, and unarguable documents are how bad systems get approved.

Self-check

1. Why is autonomy assigned per step rather than per process?
2. A gate exists, an approver is named, and the override rate has been zero for six months. What do you conclude, and what do you do?
3. Your vendor reports 96% per-step accuracy across a seven-step agent. What is the end-to-end figure, and what would you ask them to change?
4. Name one step in your own workflow where a deterministic check after a model step would catch a realistic failure.
5. What is the retention obligation on your traces, and who currently owns it?

Further reading

• Anthropic, Building Effective Agents, 2024 — workflow patterns and when to stop adding autonomy.
• Module 6 of this course, on the legal status of human oversight that cannot change the outcome.

Why executives get this backwards

The instinct in most organisations is to treat AI governance as a gate at the end: build the thing, then send it to legal.

That sequence guarantees the worst outcome. By the time a system exists, its data flows, its retention behaviour and its decision boundaries are already fixed in code — and the cheapest fixes are no longer available. Governance applied at the end can only say no.

There is a better framing, and it is the organising idea of this module. Compliance obligations for an AI system are not one thing. They are three separate obligations that attach at three different points, and they are frequently confused:

Almost every governance failure traces to answering one of these three and assuming the other two came with it. A team gets a lawful basis for the data and forgets that the decision needs contestability. Or it builds a beautiful human-review process and never discloses that the draft was machine-generated.

Hold the three apart. The rest of this module works through each.

6.1 GDPR: the data obligation, and one decision trap

Lawful basis is not a formality

Under the GDPR, every act of processing needs a lawful basis (Art. 6). For AI projects the realistic candidates are contract necessity, legitimate interests, and consent — and the choice has consequences you will live with.

Legitimate interests is the workhorse, but it requires a documented balancing test and it grants the individual a right to object. Consent is often the wrong instrument for workplace or operational systems: it must be freely given, and it can be withdrawn, which means building a system whose lawful basis can evaporate on a Tuesday.

Health data needs a second key

This is where diagnostics, insurers, employers and anyone touching wellbeing data get caught. Health data is a special category under Art. 9. Special-category processing is prohibited by default and requires both an Art. 6 basis and a separate Art. 9 condition — explicit consent, healthcare provision, public health, or a member-state law among them.

Two keys, not one. A great many "AI wellbeing" and "AI triage" proposals fail at this step, and they fail before any model is chosen.

Purpose limitation is the quiet killer of AI projects

Data collected to deliver a service may not be freely repurposed to train a model on. Purpose limitation (Art. 5(1)(b)) and the fairness and transparency principles mean the question is not "do we hold this data?" but "did we tell people we would use it for this?"

The practical consequence for a roadmap: the training-data conversation belongs at the start of the project, not at the end. Retrofitting a lawful basis onto a corpus that has already been assembled is one of the most expensive mistakes available.

Data minimisation as an engineering instruction

Art. 5(1)(c) requires that data be adequate, relevant and limited to what is necessary. Read as an engineering instruction it means: strip identifiers before the model sees the text, wherever the task does not need them.

Most language tasks do not need to know who the person is. Detecting that a customer is describing a sizing problem does not require their name, address or account number. Masking personal data before inference is not merely a control — it materially reduces the scope of everything else in this module.

Article 22, and why a rubber stamp will not save you

Art. 22 gives individuals the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them. Where such decision-making is permitted, safeguards must include the ability to obtain human intervention, express a point of view and contest the decision.

Executives routinely assume the fix is to place a person in the loop. The Court of Justice narrowed that escape route considerably in SCHUFA (C-634/21, December 2023), holding that a credit-scoring agency's automated score was itself automated decision-making where the score substantially determined whether a lender would contract with the individual.

The lesson generalises well beyond credit:

If the human in the loop cannot realistically change the outcome, you do not have human oversight. You have a rubber stamp — and the automated-decision rules still apply.

This connects directly to workflow design. An approval gate is only a real control when the approver has the information, the time and the authority to decide differently. Module 5 designs gates that meet that standard; here, note the legal consequence of gates that do not.

DPIAs, transfers and erasure

• DPIA (Art. 35). A data protection impact assessment is required where processing is likely to result in high risk — which covers systematic evaluation based on automated processing, large-scale special-category processing, and systematic monitoring. Most substantive AI deployments in regulated sectors will need one. Do it early; it is a design tool, not paperwork.
• International transfers. Where the model runs matters. Sending personal data to an API endpoint in another jurisdiction is a transfer and needs a transfer mechanism. This is the single most common reason serious organisations choose to run smaller models on their own infrastructure.
• Erasure. The right to erasure is straightforward for a database row and genuinely hard for a trained model. The defensible architecture keeps personal data in systems you can delete from, and keeps it out of training corpora unless you have both a basis and a plan.

6.2 HIPAA: who you are determines what you owe

HIPAA confuses non-US executives because it is narrower than they expect and stricter than they expect at the same time.

It is narrower because it does not regulate health information generally. It regulates protected health information (PHI) held by covered entities — health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically in connection with certain transactions — and by their business associates.

It is stricter because once you are in scope, the obligations flow down contractually to everyone you hand data to.

The three questions that decide your position

1. Are you a covered entity, a business associate, or neither? A software vendor processing PHI on behalf of a hospital is a business associate and is directly liable for much of the rule set. A wellness app selling to consumers may be neither — and then finds itself governed by other consumer-protection law instead.
2. Do you have a Business Associate Agreement with every vendor touching PHI? This includes model providers. If a language model API will see PHI, that provider is a business associate and a BAA is required. "We use the enterprise tier" is not the same statement as "we have a BAA."
3. Is the data actually PHI, or can it be de-identified first? This is the highest-leverage question in the module.

De-identification is the strategic move

HIPAA offers two routes to de-identified data, which is then outside the rule:

• Safe Harbor — removal of eighteen specified identifier types (names, geographic subdivisions smaller than a state, all date elements more specific than year, contact details, record and device numbers, biometric identifiers, full-face images, and any other unique identifying number or code), with no actual knowledge that the remainder could identify the individual.
• Expert Determination — a qualified statistician documents that the re-identification risk is very small.

For most AI work on clinical free text, Safe Harbor style redaction before inference converts a hard problem into a manageable one. This is the same instruction the GDPR gives through minimisation, arrived at from a completely different legal tradition — which is exactly why it belongs in your control set rather than in a jurisdiction-specific checklist.

Minimum necessary, and the Security Rule's current state

The minimum necessary standard requires limiting PHI use and disclosure to what is needed for the purpose. Applied to AI, that is an argument against sending whole records to a model when a field would do.

On the Security Rule: the administrative, physical and technical safeguards in force today remain those of the 2013 rule. A significant modernisation was proposed — the notice of proposed rulemaking published on 6 January 2025, with comments closing 7 March 2025, would remove the "addressable" category, mandate multi-factor authentication, require asset inventories and network maps, and strengthen business-associate oversight. As of August 2026 no final rule has been issued, and the projected date for final action has moved to 2027.

The planning consequence is worth stating plainly to a board: the direction of travel is known even though the deadline is not. Organisations building the proposed controls now are buying optionality cheaply; organisations waiting for certainty will implement under time pressure.

6.3 The EU AI Act: find your tier, then find your date

The AI Act regulates by risk tier, and by your role — provider, deployer, importer or distributor. Most enterprises are deployers of someone else's system, which carries a lighter but real set of obligations.

The tiers

The timeline actually in force

This is where most 2026 course material is wrong, because it moved recently.

The original schedule put standalone high-risk obligations at 2 August 2026. A political agreement on the digital omnibus in May 2026, which entered into force in late July 2026, deferred them:

Two management conclusions follow:

1. The transparency obligation is live today. If customers talk to something machine-generated, or you publish synthetic content, that is a present obligation, not a future one — and it is cheap to comply with if designed in, awkward if retrofitted.
2. The high-risk deferral is time to build, not time to wait. Conformity assessment, technical documentation and logging are not things you assemble in a quarter. An organisation treating December 2027 as distant is making the same mistake organisations made with GDPR in 2016.

6.4 Frameworks that make this operational

Two voluntary frameworks turn the obligations above into something you can run and audit.

• NIST AI Risk Management Framework — a voluntary US framework organised around four functions: Govern, Map, Measure, Manage. Its value to an executive is structural: Govern is the standing organisational capability, while Map/Measure/Manage repeat per system. If you need a way to explain why you need both an AI policy and a per-system process, this is it.
• ISO/IEC 42001 — a certifiable management-system standard for AI, structured like ISO 27001. Its value is commercial as much as ethical: it produces an artefact an enterprise customer's procurement team recognises, which shortens sales cycles.

Neither is law. Both are increasingly what enterprise buyers and insurers ask for, which makes them a competitive question as well as a compliance one.

6.5 The control set that satisfies most of it at once

The efficient move is to notice how much overlap exists between regimes and implement against the overlap. Eight controls carry most of the load:

1. Data residency and processing location — know and pin where inference happens. Satisfies GDPR transfers, supports HIPAA, simplifies sector rules.
2. Identifier masking before inference — strip personal and health identifiers on the way in. Satisfies GDPR minimisation and the spirit of HIPAA minimum necessary; often converts PHI into de-identified data entirely.
3. Purpose binding — each system records what it may use data for, and training use is a separate, explicit decision. Satisfies purpose limitation.
4. Approval gates with real authority — a named human who can see the input, change the output, and whose decision is recorded. Satisfies Art. 22 safeguards and AI Act human-oversight expectations.
5. Traces — an immutable record of what was sent, what came back, which version of the system produced it, who approved it. Satisfies AI Act logging, evidences DPIA claims, and is the only way to answer "why did it do that?" months later.
6. Retention and deletion — defined lifetimes for inputs, outputs and traces, and a deletion path that actually works. Satisfies erasure and minimisation.
7. Disclosure at the interface — tell people when they are interacting with, or reading output from, an AI system. Satisfies AI Act Art. 50, live now.
8. A system inventory — one list of every AI system, its tier, its owner, its data, its jurisdiction. Everything above is unenforceable without it, and no regulator conversation survives its absence.

6.6 Shadow AI: the exposure you have not inventoried

Every organisation in this course already has AI in production. Not all of it is sanctioned.

Staff paste customer emails, contracts, patient narratives and source code into consumer chat tools because those tools are useful and the sanctioned path is slower. Each paste is potentially a transfer, a purpose-limitation breach, a PHI disclosure without a BAA, or a trade-secret disclosure.

Prohibition alone does not work; it converts visible usage into invisible usage. The pattern that does work has three parts:

1. Measure it before you legislate. Network and expense data will tell you what is actually in use.
2. Provide a sanctioned path that is genuinely faster than the unsanctioned one. Convenience is the control.
3. Make the rule specific to data class, not to tools. "Never paste customer identifiers or patient data into any external tool" survives the arrival of the next product; a list of banned domains does not.

Exercise — Build a control map for one workflow

Time: 60–75 minutes. Produces the artefact for this module.

Choose one real workflow from the labelled portfolio you built in Module 3 — ideally one that touches personal data.

Step 1 — Separate the three obligations. For this workflow, write one paragraph each on the data obligation, the decision obligation and the disclosure obligation. If any is "none," say why.

Step 2 — Complete the control map. For each of the eight controls, record the current state, the target state, and a named owner. Not a team — a person.

Step 3 — The override test. Find the human in your workflow who is supposed to provide oversight. Ask three questions: Do they see the inputs the system used? Do they have time to review at the real volume? Has anyone ever overridden it? If any answer is no, you have a rubber stamp, and both your legal exposure and your quality assurance are weaker than your documentation claims.

Step 4 — Name the tier. State which AI Act tier this system occupies, which role you play, and the date that applies. Write the sentence you would say to a regulator.

Self-check

1. A colleague says, "We have consent, so we can train on this data." Which two principles might still block it?
2. Your vendor says its enterprise plan is "HIPAA compliant." What single document do you ask for, and what do you check inside it?
3. Under what circumstances does putting a human in the loop fail to remove a system from Art. 22 scope?
4. Your recruitment team wants to use the internal document-summarisation tool to rank job applicants. Which tier did the system just move into, and what changed?
5. Which of the eight controls would you implement first in your organisation, and what is your argument for the sequence?

Further reading

• Regulation (EU) 2016/679 (GDPR), Arts. 5, 6, 9, 22, 35 — and the EDPB guidance on automated decision-making.
• CJEU, SCHUFA Holding, C-634/21, 7 December 2023 — on when a score is itself an automated decision.
• Regulation (EU) 2024/1689 (AI Act), Annexes I and III, Arts. 6, 26, 50 — read alongside the 2026 omnibus amendments to the application dates.
• 45 CFR Parts 160 and 164 (HIPAA Privacy and Security Rules); HHS guidance on de-identification methods.
• HHS Office for Civil Rights, HIPAA Security Rule NPRM, 6 January 2025 — the proposed modernisation, still pending as of August 2026.
• NIST, AI Risk Management Framework 1.0, 2023.
• ISO/IEC 42001:2023, AI management systems.

Why this module exists

You are buying in the lemon market described in Module 2. Ordinary procurement instincts — issue a requirements document, compare feature matrices, negotiate on price — perform badly there, because the feature matrix is exactly the artefact that is free to fabricate.

Worse, the standard process actively selects for the wrong vendor. A long requirements list rewards whoever is most willing to tick boxes, and the honest vendor who writes "partial" loses to the one who writes "yes."

This module rebuilds procurement around verification. The method is not more scepticism; it is a different sequence.

7.1 Fit, value and risk are three questions

Collapsing them into one number hides the trade-off you are actually making, which is usually "we accepted more risk because it scored well on fit."

Fit is about your estate and your processes. Does it connect to the systems in your Module 4 integration map, at the frequency the slowest hop allows? Does it work the way the process actually runs, including the exceptions? Fit is the dimension most likely to be assessed optimistically, because vendors demonstrate the happy path and your process is mostly exceptions.

Value is about a quantified baseline. Not "improves productivity" — the specific number, today, that this is supposed to move, and by how much. If you cannot state the baseline, you cannot evaluate value from any vendor, and the entire exercise collapses into preference. This is why Module 10's metrics work must start before procurement, not after.

Risk has three components that behave differently:

• Regulatory — the Module 6 analysis: where data goes, what decisions are made, what must be disclosed.
• Operational — what happens when it is wrong, unavailable, or changed underneath you.
• Concentration — how much of your operation depends on one supplier, and what your position is when they reprice.

Score them separately. A vendor that is excellent on fit and value but unacceptable on regulatory risk is not an 8 out of 10; it is a no. Some dimensions are gates, not weights, and deciding which in advance is half the discipline.

7.2 A pilot that decides something

Most AI pilots do not fail. They succeed ambiguously, which is worse, because ambiguity is resolved in favour of whoever sponsored the pilot.

The fix is procedural and takes an hour. Pre-register the pilot before anything runs:

Three failure modes this prevents:

Cherry-picked samples. If the sample is chosen after the vendor has seen the data, you are measuring their selection ability. Include the awkward cases deliberately — the ones your team finds hard. That is where the frontier is.

The moving metric. Without a pre-agreed number, "it wrote good letters" becomes the finding. Good is not a metric.

The sunk-cost close. A decision rule written in advance is the only defence against the argument that you have already invested three months.

One further design note: run the baseline arm. Where you can, have a comparable set handled the current way over the same period. Without it you cannot separate the tool's effect from the effect of paying attention to a process for the first time in years — which is real, large, and not something you need a vendor for.

7.3 Total cost of ownership

Four cost categories. Most business cases include the first and discover the others.

Two questions that reveal more than a spreadsheet:

"What does this cost at ten times today's volume?" Consumption pricing means your costs scale with your success. A business case built on pilot volumes can invert at production volumes. Ask for the curve, not the point.

"What does it cost to keep this working for three years?" Model versions change, upstream APIs change, your processes change. Somebody maintains the evaluation set and re-tests. If no name is attached to that, the true answer is that quality will drift downward until someone notices.

Set against these, note the counterweight from Module 1: at a fixed quality bar, inference prices have been falling by roughly an order of magnitude per year. Do not sign a long agreement at today's consumption rates without a repricing mechanism — you would be locking in the most rapidly deflating input in your stack.

7.4 Lock-in and exit

Ask the exit questions at the start, when you have leverage, rather than at renewal, when you have none.

• Where do your prompts and configurations live, and can you export them in a usable form?
• Where do your evaluation sets live? These are the most valuable asset you will build — a curated set of cases with known-good answers, representing years of accumulated judgement about your domain. Losing them means starting quality measurement from zero with the next vendor.
• Where do your traces live, and can you take them?
• Is the model swappable, or is the platform bound to one provider? Given the pace of the market, being unable to change model is a real cost.
• What survives termination? Specifically: for how long can you read your own history?

7.5 The contract terms that matter

Beyond ordinary commercial terms, six clauses are specific to this class of system.

For anyone in scope of Module 6, add the data processing agreement and, where protected health information is involved, the business associate agreement. "We are compliant" is a marketing sentence. The document is the control.

7.6 Reference calls that produce truth

A reference supplied by a vendor is a rung-two claim (Module 2) until you have selected it yourself. Four questions produce more signal than an hour of general conversation:

1. "What did you have to build yourselves that you expected to be included?" This surfaces the true scope boundary better than any statement of work.
2. "What surprised you in month four?" Month one is onboarding enthusiasm. Month four is when the real behaviour appears.
3. "What is your override rate, and has it moved?" Applies Module 5's test to someone else's deployment.
4. "What would you not buy again?" Almost everyone answers this honestly, because it is not a question about the vendor.

And the one request that separates serious vendors from the rest: ask for a customer who stopped using the product. The refusal is itself information; the willingness is a strong signal; and the call, if it happens, is usually the most useful hour of the entire evaluation.

7.7 The scorecard

Two rules, and the second is the one that does the work.

Rule one: gates before weights. Some criteria are pass/fail — data residency, a required certification, the availability of a business associate agreement. Apply them first and eliminate. Do not let a strong score elsewhere buy a way past a gate.

Rule two: set the weights before you score anyone. This is the single most effective de-biasing step available in procurement, and it costs nothing. Weights chosen after you have met the vendors will, reliably and unconsciously, be the weights that favour the vendor you liked.

A workable structure:

Score 1 to 5 with a written justification per cell. The justifications, not the total, are what you will defend in six months — and writing them is what exposes the cells where you have no evidence at all.

Exercise — Complete the scorecard

Time: 90 minutes across two sittings. Produces the artefact for this module.

Sitting one, before you look at any vendor.

1. Write your gates. Which criteria are pass/fail, and why.
2. Set your weights, and have someone else sign off that they were set first.
3. Write the pre-registration for the pilot: metric, baseline, sample, duration, decision rule, custodian.

Sitting two, after the pilot.

1. Score two real options — and make one of them the assembly option, even if nobody has proposed it.
2. Write the justification in every cell. Cells you cannot justify are the questions for your next vendor call.
3. Write the one-paragraph recommendation you would sign your name to, including the strongest argument against it.

Self-check

1. Why should weights be set before vendors are scored, and what goes wrong when they are not?
2. Which criteria in your organisation should be gates rather than weighted dimensions?
3. What is the difference between a pilot and a demonstration, expressed as a single procedural requirement?
4. Why is the evaluation set the asset to protect in a contract, and where does yours currently live?
5. Your business case assumes pilot-level consumption. What question tells you whether it survives production?

Further reading

• George A. Akerlof, The Market for "Lemons", 1970 — the remedies section, read as procurement design.
• ISO/IEC 42001:2023, AI management systems — as a certification signal in vendor assessment.
• Module 6 of this course, for the regulatory gates that precede scoring.

Why this module exists

If everyone can buy the same capability from the same providers on the same day, capability is not advantage. It is table stakes arriving on a schedule.

This is the module where the course stops being about deployment and starts being about whether any of it makes you money that a competitor cannot also make. The answer is yes — but almost never at the layer where the investment is being announced.

8.1 Capability commoditises

Jay Barney's resource-based view gives the standard test for a sustainable advantage. A resource must be valuable, rare, inimitable and non-substitutable. Apply it honestly to "we use a frontier model":

One out of four. The model layer fails the test comprehensively, and the economics from Module 1 explain why: at a fixed quality bar, price falls by roughly an order of magnitude a year. Anything whose advantage rests on access to capability is standing on the fastest-deflating asset in the stack.

This should be liberating rather than deflating. It means you do not have to win the model race, and the enormous capital being spent there is being spent on your behalf by other people.

8.2 What actually survives the test

Five categories pass, and each is something you already own or can build.

Proprietary process knowledge, in a usable form. How your business actually decides — which claims are worth appealing, which customers get flexibility, what a good technician's note contains. This exists today in people's heads, which is why it is inimitable and also why it is inaccessible. The act of writing it down so that a system can use it is the value-creating step, and it is not a technology project.

Records of past decisions. A decision archive — what was approved, on what evidence, and what happened next — is rare, valuable and hard to copy, because it can only be accumulated in real time. Competitors cannot buy your history. Note that Module 5's traces are precisely this, produced as a by-product of running the system.

Distribution and installed base. Unchanged by AI, and increasingly the decisive factor: capability arriving equally to everyone raises the relative value of already having the customers.

Integration depth and switching costs. A system woven into a customer's workflow, holding their configuration and history, is defensible in a way that a clever feature is not. This cuts both ways — it is also the reason Module 7 spends so long on your own exit terms.

Regulatory position. Certification, approvals, and demonstrated compliance are rare and slow to imitate by construction. In regulated sectors, Module 6's control set is not a cost centre; it is a barrier to entry that you are permitted to build.

And the one everybody claims: data. Data is an advantage only under specific conditions, which is why the next section is about telling the difference.

8.3 A flywheel is not a data lake

Most claimed data advantages are inventories. A flywheel has four properties, and all four must hold:

1. The data is generated by your operation and cannot be purchased.
2. Using the product produces more of it — the loop closes automatically rather than through a project.
3. More of it makes the product measurably better — with a demonstrated relationship, not an assumed one.
4. Better product attracts more usage, which returns to step 2.

Break any link and you have a large, expensive archive. The most commonly broken link is the third: organisations accumulate volume long past the point where additional volume improves anything. Ten years of tickets is not ten times better than one year; it is one year of signal and nine years of drift.

Two diagnostic questions:

• "What would we do differently with ten times the data?" If the answer is vague, you do not have a flywheel.
• "Does using the product create labelled examples automatically?" The Module 5 trace — human edits and overrides captured as a by-product — is the cheapest flywheel available, and most organisations discard it.

8.4 Industry structure

Porter's five forces still work; AI changes their inputs. Run your industry through this table rather than reasoning from the technology.

The row that catches people is supplier power. Adopting AI at scale creates a dependency on a small number of providers whose pricing, model behaviour and terms can change with limited notice. Module 7's swappability and exit terms are a competitive instrument, not an administrative detail.

The row that matters most is the last one. Feature parity arrives quickly; operating-model change does not. McKinsey's finding that workflow redesign is the strongest correlate of profit impact is a strategy finding, not an implementation one: the durable gap is between organisations that redesigned the work and organisations that added a tool to the existing work.

8.5 Where to lead and where to follow

Most organisations get this exactly backwards. They lead where capability is commoditising — a chat assistant, a summarisation feature, a copilot in the product — and follow where advantage compounds, because that part is slow, political and unglamorous.

A rule to invert it:

Lead where the asset compounds and cannot be bought. Follow where the capability arrives on a schedule.

Following is not passivity. It is a decision to spend the same money on the thing that will still be yours in three years.

8.6 Reading a competitor's move

When a rival announces something, apply Module 2's ladder before your board applies its adrenaline.

1. What rung is this? A press release is rung one. A named customer with a number is rung three.
2. What is the bill of materials? Module 3's discipline, applied from outside: how much of what they announced is plumbing they already had?
3. Which layer did they invest in? If it is the commoditising layer, their advantage has an expiry date. If they are capturing process knowledge or building a regulatory position, that is the serious signal.
4. Would their claim survive our five questions? Often the announcement describes a use case that fails Question 5 on volume, which tells you it is positioning.

The most common correct conclusion is: this is a signalling move, and the appropriate response is not to match it. The FactSet finding from Module 2 — that the market rewards the word — means you should expect a high ratio of announcement to deployment, and should not let that ratio set your capital allocation.

Exercise — Write your advantage thesis

Time: 60 minutes. Produces the artefact for this module.

One page. Four parts.

1. The asset. Name the specific thing AI makes more valuable in your business. Not a capability you can buy — an asset you have or can accumulate. Run it through the four VRIN tests in writing.
2. The mechanism. How does it compound? Where does the loop close, and what would break it?
3. The moat. Why can a well-funded competitor not have this within eighteen months? If the honest answer is that they could, say so — that is a finding, and it should redirect your investment.
4. The falsification clause. What evidence, observed within a year, would prove this thesis wrong? Name the observation and the date you will check.

Part four is what makes it a thesis rather than a hope, and it is the part most likely to be omitted. It is also the top band of the capstone rubric's evidence dimension.

Self-check

1. Apply the VRIN test to the single largest AI investment currently proposed in your organisation. What does it score?
2. Your team claims a data advantage. Which of the four flywheel conditions is weakest, and what evidence would settle it?
3. In your industry, name one entry barrier AI lowers and one it raises.
4. Where is your organisation currently leading that it should be following?
5. What would have to be true, within twelve months, for your advantage thesis to be wrong?

Further reading

• Jay B. Barney, Firm Resources and Sustained Competitive Advantage, Journal of Management, 1991.
• Michael E. Porter, Competitive Strategy, 1980 — five forces, read against a technology shock.
• McKinsey, The State of AI — on workflow redesign as the strongest correlate of EBIT impact.

Why this module exists

Most AI programmes bolt a tool onto the bottom of an unchanged organisation chart and are then surprised that nothing structural improves. Meanwhile the strongest empirical correlate of AI-attributable profit impact, across every large survey, is not model choice or vendor selection. It is fundamental workflow redesign.

That finding is usually read as an implementation lesson. It is a structural one. This module supplies the theory that explains why, and an instrument for acting on it.

9.1 Firms exist because coordination is expensive

Start with a question that earned a Nobel Prize: why does your company exist at all?

Everything it does could in principle be bought from the market — accounting from a firm, sales through agents, production from contract manufacturers. So why keep all those people inside, with salaries and the overhead of managing them?

Ronald Coase answered this in 1937: firms exist because using the market is expensive. For every task you would otherwise have to find a supplier, negotiate, contract and monitor. He called these transaction costs. When they exceed the cost of coordinating the work internally, the firm grows; when the balance flips, it shrinks. The boundary of your company is drawn not by your product but by the price of coordination.

Two earlier figures complete the picture. Frederick Taylor, in 1911, separated the knowledge inside work from the person doing it and wrote it down — making craft knowledge portable and therefore manageable. Max Weber explained why bureaucracy was winning: files, hierarchies and written rules were the only way to process information reliably at scale with the technology available.

Put their shared discovery in current language: management is an information technology. Every layer on your chart is an answer to an information problem. How does the truth on the ground travel up? How does the decision at the top travel down? Who needs to know what, and who must approve what?

Middle management was invented for exactly this: compress information from below and carry it up, unpack decisions from above and distribute them down. We have paid salaries for that for a century, because for a century a human was the only available router.

This has never been static. The telephone made the multi-branch firm possible. ERP systems in the 1990s turned "the person who compiles the inventory report" into a query screen — and produced precisely the delayering debate we are having again now.

The pattern is consistent: as moving information got cheaper, the layers built to move it got thinner. But deciding, taking responsibility and building trust never got cheaper.

9.2 Transport and judgement

That distinction is the instrument. Hold it precisely:

Now bring it down to one person's day. A scene from a distribution business, anonymised but real in outline.

A regional manager sits down at nine on Monday. Three windows are open: the sales export from the ERP, weekend messages from six field representatives, and the weekly report template headquarters expects at three. The next five hours go into moving numbers into the template, distilling a summary out of scattered messages, and calling to verify two lines that do not match last week. At three, the report goes out.

At half past three the real work lands: the region's largest customer wants payment terms extended from sixty days to ninety. That decision requires knowing the customer, knowing the sector's cash position this quarter, and answering "is this customer bluffing or genuinely in trouble?" with instinct built over years. The manager gives it twenty minutes, at the most tired hour of the day.

Which earns the salary — the five hours or the twenty minutes? Everyone knows the answer. But the architecture of the day says the opposite. The salary is paid for judgement; the hours go to transport.

Inside one box on the org chart sit two different jobs, one newly cheap and one newly more valuable, crammed into the same calendar. The promise of AI is not to delete the box. It is to hand the five hours to a machine and move the twenty minutes to the best hour of the day.

9.3 The layer audit

The instrument. For every box in your function, four questions:

Question four is the honesty test. There are legitimate answers — more customer contact, faster decisions, work currently not done at all, capacity for growth without hiring. There is also a legitimate answer that says the role shrinks. What is not legitimate is presenting a headcount reduction as a redesign and being surprised when the organisation resists it. People are extremely good at detecting which one is happening.

9.4 Operating models

Where does AI capability live? Four answers, with honest trade-offs.

The hybrid is the most common right answer, and it only works if you write down which decisions are central and which are local. A defensible split:

• Central: which data may go where, the control set from Module 6, the platform and its traces, vendor gates, the evaluation-set standard.
• Local: which processes to attack, the priority order, the acceptance criteria, and who approves what within their own decision rights.

The failure to specify this is the single most common structural cause of stalled programmes: a centre that believes it owns prioritisation and business units that believe they do.

9.5 Roles, capability and the scarce skill

Module 1 established that AI compresses the gap between novice and expert on tasks inside the frontier. That has a direct consequence for what you should be hiring and developing.

If producing the first draft is cheap, the scarce skill moves to two places:

Specification. The ability to state precisely what good output looks like — the standard, the exceptions, the edge cases. This is what turns a vague ambition into the acceptance criterion of Module 5, and it is rarer than it looks. Most organisations discover, on their first serious deployment, that nobody had ever written down what a good version of the work actually is.

Detection. The ability to notice that fluent output is wrong. This is domain expertise, and its value rises rather than falls — but it is deployed differently, on review rather than production.

Three practical implications:

1. Do not remove the training ground. If juniors historically learned judgement by doing transport work, automating all of it removes the path by which your future seniors are made. Design the replacement deliberately — review rotations, deliberate exposure to hard cases — or you will discover the gap in five years.
2. Promote the specifiers. The people who can articulate the standard are now more valuable than the people who can execute it quickly.
3. Buy the platform, build the knowledge. Module 8's conclusion, applied to people: the durable asset is your process knowledge in usable form, and only your people can produce it.

9.6 Incentives, or why good governance dies

Everything in this course fails if the incentive structure punishes the behaviour it requires.

Module 2 named the asymmetry: failing conventionally is free, and succeeding unconventionally invites suspicion. Inside an organisation this produces a specific pathology — nobody kills their own project. The evaluation is written by the sponsor, the pilot succeeds ambiguously, and the portfolio fills with systems that no one believes in and no one will stop.

Four mechanisms change the payoff, and all four are within a single leader's authority:

Separate the proposer from the measurer. The person who pre-registers the pilot metric should not be the person whose budget depends on the result. This is not distrust; it is the same principle as separating trading from settlement.

Put the no-list in the pack, not the appendix. Make the decisions not to use AI a standing agenda item with named reasons. This converts "I killed my project" from a confession into a deliverable.

Reward falsification explicitly. When someone produces the evidence that stops a project before it burns a year, say so in the forum where promotions are discussed. Once. Everyone will remember.

Make the sentence sayable. The single practical test of an organisation's AI culture is whether a mid-level manager can say "we checked, and it doesn't need a model" in a meeting without their voice rising at the end. If they cannot, your governance is decorative regardless of what the policy says.

Exercise — Run the layer audit

Time: 90 minutes. Produces the artefact for this module.

1. List every role in your function. Roles, not people.
2. For each, estimate the transport/judgement split. Estimates are fine; precision is not the point, and asking the people doing the work produces better numbers than guessing.
3. Answer questions 2, 3 and 4 for each: are decisions recorded, is the loss information or trust, and what happens to reclaimed time.
4. Mark the highest-judgement role and ask whether anything currently captures what it knows. This is usually the most important finding.
5. Choose one transport block to remove this quarter — and check first whether it needs a system at all. Roughly a third of transport work turns out to be producing something nobody uses.
6. Write your operating-model split: three decisions that are central, three that are local.

Self-check

1. Why is "management is an information technology" more useful than "AI automates tasks"?
2. In your own week, which block is transport and which is judgement — and which one gets your best hours?
3. A role scores 65% transport. What are the three legitimate answers to "what happens to the reclaimed time," and which applies?
4. Which role in your function would cost you trust rather than information if it vanished, and what currently captures its knowledge?
5. Could a manager two levels below you say "we checked, and it doesn't need a model" in a meeting without hesitation? What would change that?

Further reading

• Ronald H. Coase, The Nature of the Firm, Economica, 1937.
• Frederick W. Taylor, The Principles of Scientific Management, 1911.
• Erik Brynjolfsson, Danielle Li and Lindsey R. Raymond, Generative AI at Work, NBER, 2023 — on the compression of the novice–expert gap.
• McKinsey, The State of AI — workflow redesign as the strongest correlate of impact.

Why this module exists

Every preceding module produced an artefact. This one assembles them into a plan that survives three separate hostile reviews — finance, legal, and a change of priorities — and that a board can approve without having to trust you.

The difference between a roadmap and a wish list is that a roadmap states what is being sequenced against what, what it costs, how you will know, and what happens when it does not work.

10.1 Sequencing

The instinct is to sequence by value: biggest prize first. That is wrong for a programme in its first year, and the reason is organisational rather than technical.

Sequence against two axes.

Readiness means: the data exists and can be moved (Module 4), the decision rights are clear (Module 5), the governance path is walkable (Module 6), and there is a named owner with capacity. Any one of those missing turns a high-value project into a long one.

Then a second criterion that most plans omit: evidence value. Your first deployment is buying two things — a business result and organisational belief. In year one, belief is often worth more, because it determines whether anything else gets funded.

That argues for a first project that is:

• Boring. Nobody's reputation is attached to a nightly report landing correctly.
• Fast. Weeks, not quarters. Momentum is a resource.
• Measurable against an existing number. So the result is not a matter of opinion.
• Owned by someone who wanted it. A volunteer sponsor outperforms a mandated one every time.

10.2 Three horizons

A structure that survives contact with a board because each horizon has a different question.

Ninety days — does this work here?

• One system live, at autonomy level 2 or 3, with a measured result against a baseline.
• The governance baseline from Module 6: system inventory, processing locations, masking, traces, one control map completed.
• The labelled portfolio and no-list published internally.

Twelve months — does it work at portfolio scale?

• Three to five systems in production, each with gates that pass the override test.
• The evaluation set established as a corporate asset, in your systems.
• Vendor decisions made through the Module 7 scorecard rather than ad hoc.
• The first layer audit completed and one structural change made.

Thirty-six months — does the organisation look different?

• Structural redesign of the layers identified in Module 9.
• Advantage thesis from Module 8 either evidenced or falsified, with capital reallocated accordingly.
• Compliance position converted from cost to commercial asset where the market rewards it.

Be honest that horizon three is a direction, not a plan. Anyone presenting a detailed thirty-six-month AI plan is presenting fiction, and a board that has read Module 2 will know it.

10.3 Funding models

Each model produces a predictable pathology. Choose knowingly.

The recurring problem in all three is the plumbing. The movement layer, the trace infrastructure, the evaluation-set discipline and the control set benefit everyone and belong to no one's business case. If you fund only what has an attributable return, you will not fund them, and every subsequent project will pay for their absence.

The practical answer used by most organisations that get past year one: fund the platform centrally as infrastructure, fund the use cases locally against their own numbers. Then defend the platform line at budget time using the same argument as networking or identity — it is not a project, it is a precondition.

10.4 Metrics your CFO will accept

Four families, in ascending order of credibility.

Three disciplines make the difference between a number and an argument.

Baseline before deployment. Measured over a period long enough to contain normal variation. If you have not baselined, you cannot claim anything, and the honest move is to say so rather than construct a comparison afterwards.

Name the counterfactual. What would have happened anyway? Volumes change, seasons change, and paying attention to a process for the first time in five years improves it on its own. Where you can, keep a comparable group running the old way for the measurement period. Where you cannot, say explicitly that you cannot — a stated limitation survives scrutiny; an unstated one destroys credibility when found.

Convert "hours saved" into something that appears in accounts. This is where most AI business cases die. Hours saved are real but they are not money until they become something: fewer contractors, absorbed growth without hiring, a backlog cleared that was costing revenue, or faster cycle time that changes a customer outcome. State which. If the honest answer is "the team has more slack," say that too — it may still be worth funding, but it is not a saving and your CFO will know.

10.5 The board conversation

Module 2's finding, applied: boards rarely want AI. What they want is evidence that the company is not being quietly disrupted while they are not looking. "What is our AI strategy?" is the phrasing available to them for that anxiety.

Answer the literal question and you present a technology roadmap into a conversation about exposure, and lose. Answer the real one and you get to choose the technology.

Bring four things:

1. The exposure analysis. Where the cost structure is vulnerable if a competitor halves their cost to serve; which processes break first at double volume; what would have to be true for this to be existential rather than a margin question. None of these sentences contains the word AI.
2. The labelled portfolio and the no-list. The no-list is the credibility instrument. A yes-list proves you complied with pressure; only a no-list proves you evaluated. Four projects declined with stated reasons make the fifth sound like a finding rather than enthusiasm.
3. One shipped thing. However small. Strategy is what people ask for when they cannot see anything.
4. One number you would be embarrassed to get wrong. A single measurable claim with a date. This is Akerlof's guarantee, issued by you about yourself, and it converts you from the person with opinions into the person with a forecast.

Expect three questions and have the answers written:

• "Are we behind?" — Answer with the Module 8 asset analysis, not with a vendor comparison.
• "What if the technology changes?" — Answer with the Module 1 economics: capability is unpredictable, price is predictable, so we are building the slow parts that do not depend on either.
• "What is the risk?" — Answer with the Module 6 control map and a named owner per control. Vague reassurance here is what triggers a second, worse meeting.

10.6 Designing for the budget cut

Every plan should state what happens when it is cut by 40%, because eventually one will be. A portfolio that degrades gracefully has three properties:

The plumbing survives. Movement, traces and the control set are the last things to cut, because everything else depends on them and they are slow to rebuild.

Projects are separable. A programme where five systems depend on one another fails entirely at the first cut. Independent systems fail individually.

Each system has a manual fallback. Module 5's rollback action, at portfolio level. If a system is switched off, the work still happens — more slowly. A workflow with no manual path is an operational risk disguised as an efficiency.

Write this section into the plan explicitly. Boards read it as maturity, and it is the section you will be most grateful for.

Exercise — Assemble the roadmap

Time: 2 hours. Produces the artefact for this module and the input to the capstone.

1. Write the exposure section — three paragraphs, no mention of AI.
2. Place your portfolio on the value/readiness matrix. Identify what is blocked on readiness rather than on technology, and name the specific blocker.
3. Choose the first project using the four criteria in 10.1. Defend the choice on evidence value, not only on return.
4. Write the three horizons, with specific deliverables at ninety days and twelve months and a direction at thirty-six.
5. Choose a funding model and write one sentence on the pathology you expect and how you will detect it.
6. Write the metric block: baseline, claim, counterfactual, and how hours convert into something that appears in accounts.
7. Write the degradation section: what survives a 40% cut, and what the manual fallback is.
8. Write the one number you would be embarrassed to get wrong, with a date.

Then present it in ten minutes to a colleague briefed to play a hostile CFO, and write down the question you could not answer. That question is your next week's work.

Self-check

1. Why should the first project be selected partly on evidence value rather than purely on return?
2. Which funding model does your organisation use, and which pathology is already visible?
3. Your business case says "saves 3,000 hours a year." What must you add for a CFO to accept it?
4. What is the counterfactual for your flagship project, and can you actually hold one?
5. If your budget were cut 40% next quarter, which part of your plan would you protect, and why that part?

Further reading

• McKinsey, The State of AI — on workflow redesign, and on how few organisations measure at all.
• MIT Project NANDA, The GenAI Divide, 2025 — read specifically as a warning about measurement discipline.
• Modules 3, 6, 7, 8 and 9 of this course, whose artefacts are the inputs to this plan.

The brief

Produce a board-ready twelve-month AI adoption plan for your own organisation — or, if you would rather not work with internal material, for Vantis Diagnostics, whose case file is below.

The capstone is deliberately assembled rather than written from scratch. If you completed the module exercises, you already hold every component. If you skipped them, this is where that becomes apparent, and the honest response is to go back rather than to write around the gaps.

Target length: eight to twelve pages. Shorter is better than padded; a board reads the first page and the numbers.

The Vantis Diagnostics case file

Vantis Diagnostics is fictional. It is a composite built to exercise every regime this course covers, and any resemblance to a specific company is coincidental.

The company. Laboratory diagnostics group headquartered in Utrecht, Netherlands. 2,400 staff. Three business lines: routine clinical testing for Dutch and Belgian hospitals; a specialty oncology panel sold across the EU; and a US subsidiary in Massachusetts performing clinical lab work for regional health systems. A patient-facing results portal operates in both regions.

The numbers. Group revenue €410m, EBIT margin 9.2%, down from 12.4% three years ago on payer pressure and reagent costs. The US subsidiary is 28% of revenue and 41% of the margin problem.

The pressure. The board has asked for an AI strategy by the end of the quarter. A competitor announced an "AI-native diagnostics platform" at a trade show six weeks ago; nobody at Vantis has been able to establish what it does.

The candidate projects, as they arrived on the director's desk:

Known constraints. The US billing system exports once nightly and cannot be queried more often without a licence change. EU patient data may not leave the EU under current group policy. Two payers account for 61% of denied revenue. The two payer relationship leads hold knowledge captured in no system. The trailing twelve-month denial overturn rate is 31%; roughly 4,200 denials a year fall below the appeal threshold and are written off, worth about €2.1m.

What is not in the file. Deliberately: you will have to state assumptions. Doing so explicitly, and marking which ones your plan is sensitive to, is part of what is assessed.

Assessment rubric

Each dimension is scored 1 to 4. A pass requires 3 or better on every dimension — deliberately strict, because a plan that is excellent on seven dimensions and weak on governance is not a plan you can execute.

A worked example of the difference

Take the economics dimension for the Vantis denials project.

Band 2 (asserted). "The vendor licence is €120k per year and we expect strong returns from improved denial recovery."

Band 3 (evidenced). "Three-year TCO of €640k: €360k licence, €90k inference at projected volume, €140k integration, €50k internal ownership at 0.2 FTE. Against a baseline overturn rate of 31%, the pilot reached 39% on 500 denials, worth €1.3m annually in recovered revenue."

Band 4 (falsifiable). As band 3, plus: "At 10× pilot volume, inference rises to €310k and TCO to €1.02m — still positive, but the margin narrows from 2.0× to 1.3×, so volume growth is the sensitivity to watch. The plan assumes the vendor's consumption pricing holds; the contract includes a repricing review at 18 months, and Module 1's cost trend suggests we should expect to renegotiate downward rather than up. If overturn is below 34% at 90 days, we roll back to manual drafting and the €140k integration spend is written off — that is the loss we are accepting to find out."

The third version is not longer because it is padded. It is longer because it contains the two sentences a board actually needs: what would change the answer, and what we lose if we are wrong.

How to use the rubric before you submit

Score your own draft honestly, dimension by dimension, and write the sentence that would move each 3 into a 4. Most plans arrive at 3s. The distance between a 3 and a 4 is usually one sentence per section — the sensitivity, the counterfactual, the rollback trigger — and adding those six sentences is the highest-value hour in this course.

Self-assessment questions

1. Which section of your plan would collapse first under hostile questioning, and what evidence would fix it?
2. What is the single measurable claim you are prepared to be judged on in twelve months, and who holds you to it?
3. What did you decide not to do, and what specific change would reverse that decision?
4. Which assumption in your plan is load-bearing and unverified? What is the cheapest way to test it in the next thirty days?
5. If you were replaced tomorrow, could your successor execute this plan from the document alone? If not, what is missing is not detail — it is decision rights.

Where to go next

The artefacts you have built are not one-time deliverables. They are instruments with a cadence:

The course ends here. The portfolio review does not.

Why an appendix like this exists

A surprising share of expensive AI mistakes are vocabulary failures.

Someone says "agent" meaning a scripted workflow. Someone hears "training" and budgets for a machine-learning project when they needed a search index. A vendor says "we log everything," a buyer hears "we can reconstruct any case," and both leave the room satisfied and wrong.

This appendix defines every term the course relies on, in one place, in the sense the course uses it. Where a word is genuinely contested in the market, that is stated rather than hidden.

A. How the machine works

B. Systems and architecture

C. Observability and reliability

D. Governance

E. Commercial and strategic

Terms this course deliberately avoids

Three words appear constantly in the market and are not used as load-bearing terms here, because they carry more heat than meaning.

"Intelligent." It describes an impression, not a capability. Replace it with what the system does: reads unstructured text, classifies into fuzzy categories, drafts language.

"Autonomous," used unqualified. Autonomy is a level assigned per step, not a property of a product. Ask which level, at which step, with which gate.

"AI-powered." True of a four-step workflow with one model call and of a system that is entirely a model. It is the phrase the bill of materials exists to unpack.

Self-check

1. A vendor says "our agent handles denials end to end." Which two terms in section B would you ask them to pin down, and what would each answer tell you?
2. Explain the difference between a log and a trace to a colleague in one sentence each.
3. Your team reports "the model call was slow." Which unit of observability would locate the actual cause, and why does nesting matter?
4. Which two documents does a model provider need to sign before it may process European health data on your behalf?
5. Give an example from your own organisation of something described as "AI-powered" that the bill of materials would show to be mostly not.