Part three of three. The final question is who authors the rules around capability, how leadership measures the result, and who remains accountable.
The argument in brief
No firm writes all the rules its business runs on. What matters is knowing which ones it did not write, and whether it chose to accept them. This part sets out six questions that show where authorship sits, the measures leadership should require instead of what suppliers report, and the four decisions that cannot be delegated.
Part one broke down what the buyer actually brings to the deal. Part two built the system that a purchase has to sit inside before it does anything at all. However, it left one piece of that system unopened. And that is governance, the rules that run your operation even though somebody else wrote them. This part opens that piece: what those rules mean for what leadership should be measuring, and the decisions no technology program can make for you.
Governance: six questions about what you did not author
Every organization operates under rules it did not write and cannot change on its own. Those rules still govern, and they constrain which decisions you can author in the first place.
For any capability brought in from outside, six things have to be authored by somebody. The only question that matters is whether that somebody was you.
1. What it is for. What is this capability for, and what standard is it judged against? Part two’s one-sentence test answers this one: state the objective in the words of the phase contract, without reference to what the supplier says the product does.
2. What it may reach. What can it touch inside your operation, and under whose authority?
3. The unit you govern in. What unit does the organization budget, approve, and govern in?
4. The unit you are priced in. What unit does the supplier measure and charge for? If it is the unit you budget in, you have not written a budget. You have adopted the supplier’s meter and called it one.
5. What it does now, and how that moves. What does the capability do today, and who decides when that boundary changes?
6. The rules it enforces, and the evidence it leaves. What rules does it apply on your behalf, and what record does it produce that you could put in front of someone?
Each question returns one of three verdicts: authored, where you set the answer; inherited, where someone else sets it; or contested, where it is genuinely under negotiation.
Two rules govern all six, and without them the exercise is worse than useless.
A verdict is about who controls the dial, not where the dial is currently set. Where a counterparty can unilaterally change a term your operating model depends on, that dimension is inherited at any current setting. Tightening a limit and relaxing it are the same act, because both show the setting is not yours to make. Judging a dependency by its present setting understates the exposure exactly when the setting is favorable, which is when nobody looks.
The retailer in part two is the case. Its flat monthly fee looked like a settled term until the provider switched to a per-conversation charge. The pricing was inherited all along. The fee just happened to be favorable.
A verdict recorded without its reason is not an answer. I learned this the expensive way. The first time this was run end to end it returned five inherited and one contested, and read as six bare verdicts it said almost nothing. Everything anyone could act on was in the reasoning beside them.
And one thing has to be said clearly, because the exercise invites the wrong conclusion. An inherited dimension is not a defect. No organization authors all six, and trying to would be its own kind of failure. The claim is narrower: you should know where you stand across all six, and you should have decided rather than drifted into each answer.
Run these six for each outside capability in the value streams where economic value or enterprise risk is concentrated. The output is a profile, not a score, and it is deliberately diagnostic. It shows where authorship sits. What to do about an inherited rule is a redesign question, and redesign belongs with the person who owns the value stream rather than with the audit that found the problem.
Some answers will be reassuring. Several will be a supplier’s name, an inherited default, or a blank.
The blanks are not where value escaped. They are where it was never made.
Name it yourself, before someone names it for you
This matters now, not in some comfortable future quarter, and it is not the usual appeal to urgency.
The harness, this series’ term for that layer, is what gets taken first, and it gets taken one reasonable decision at a time. Each adoption of a supplier’s orchestration, credentials, approvals, or evaluations is sensible on its own. What accumulates is the set of rules describing how your business operates, sitting inside a product you do not control. It is the household in part one that took the subscription: the coffee is fine, and the routine now belongs to the machine.
Vocabulary is the leading edge of that. Most major AI and infrastructure vendors already have a name for the system around the model, and each name quietly puts the vendor’s platform at the center of it. NVIDIA calls its version the AI Factory, a name for the infrastructure layer that arrives with a full reference design for how you should build around it. Others have their own, further up the stack. The labels change; the assumption underneath does not.
This is not a criticism of vendors. Naming the system in terms that make you dependent on them is precisely what a good supplier does, and it would be strange if they behaved otherwise.
But it means someone will lead the operating-model conversation inside your organization, on their own terms, whether or not you show up. Language is not decoration here. The words your teams reach for determine the options they can see. If you adopt a vendor’s framing for your operating model without translating it into your own, you haven’t adopted AI. You have adopted their business model and put your name on the front of it.
So name your own. Not this series’ vocabulary either. My research uses “harness,” and suppliers use it now too, which is reason enough not to borrow it. Give the layer you build around what you buy a name that belongs to your business, defined in your terms, before the vendor’s term becomes the only one your people know how to reach for. It does not need to be clever. It needs to be yours, specific enough that two people in different departments mean the same thing when they use it, and durable enough to survive the next three product cycles.
Do that work while the layer is still forming, and you maintain your position in it. Wait, and you will be renting both the capability and the language required to think about it.
Measure the business, not the activity
Firms that treat this as a line-item efficiency play will keep measuring the wrong things, and they will do it with real numbers, which is what makes it hard to catch.
It is entirely possible to publish a strong AI efficiency report for three consecutive years while the operating model stays exactly as it was, the dependencies deepen quietly, and the capability you are paying for reaches the customer through the same approval chain it always did.
The distinction that matters is between activity where capability enters the tool and value where it reaches the enterprise.
| What suppliers report | What leadership should require |
|---|---|
| Seats and licenses deployed | Fully burdened cost per completed business outcome |
| Tokens or API volume consumed | End-to-end cycle time, not per-task time |
| Active users and adoption rate | Released capacity actually converted to revenue, margin, or service |
| Theoretical hours saved | Exception, rework, and audit rates after deployment |
| Pilots launched | Share of consequential decisions with a named accountable owner |
| Model benchmark performance | Share of the gain retained, versus passed to suppliers or competed away |
| Switching described as straightforward | Supplier concentration, switching cost, and time to switch |
| Headcount reduced | Revenue per full-time equivalent, counting both people and the systems doing their share of the work |
The claims firm from parts one and two would have looked good on the left: usage high, the pilot scaled. On the right, cycle time did not move.
A split runs through that right-hand column, and the split is the finding.
The first five aren’t measures you can bolt on. They are properties of how the work is designed and run, which is why better reporting on top of an unchanged operation can’t produce them. They require an end-to-end object to measure across and a definition of a completed outcome, which is exactly what the work operating model in part two was for. The last three are yours, and no operating model will produce them, because they concern what the firm holds and keeps, and where that leaves it, rather than how the work runs.
So the honest summary is that you cannot measure your way out of this. Five of the eight require the redesign first.
The specific measures will differ by business. The principle does not: count value where it reaches the enterprise, not activity where it enters the tool. And require the comparison to be made after review, rework, oversight, and switching costs are included, because that is where most business cases quietly fail.
Two kinds of organization, and they are not two stages
There is a real difference between firms here, and it is easy to describe wrongly.
One kind decides how what it buys connects to its own work. The other buys off the shelf and runs on whatever the supplier decided.
The tempting move is to call these two levels of maturity and put them on a ladder. That would be wrong, and the reason matters. These two are not separated by how far along a path a firm has traveled. They are separated by whether a decision was taken at all.
The second is not an earlier version of the first. It is where an organization ends up by not deciding. Nobody works their way into it and nobody chooses it, which is also why no maturity assessment will find it.
Across the three parts of the demand side, the difference comes down to one act. In what you can see, it is authoring your facts rather than inheriting them. In where capability lives, it is deciding your mix rather than accumulating one. In how fast you can absorb, it is building the capacity to change before committing against the capacity you assumed.
Put in one sentence: an operating model you did not author is one you cannot govern, defend, or change.
Four decisions that belong to leadership
These four decisions cannot safely be delegated to a technology program, because a program can carry them out but cannot make them.
1. Choose the value streams that matter. Concentrate redesign where economic value or enterprise risk sits, not where a demonstration is easiest. Refuse business cases built on fractional time savings spread across disconnected tasks, and require someone to identify the constraint before accelerating anything.
2. Name an owner for each. Decide who owns each value stream end to end, and give that owner the rights needed to change workflows, measures, and incentives across functional boundaries. Accountability sits with the whole, not its parts: an owner accountable for one step will optimize that step at the expense of everything around it, rebuilding the silo the exercise exists to cut across. If the answer is a committee, the answer is nobody.
3. Decide what the firm must continue to own. Determine which data, measures, decision rights, operating knowledge, and switching capabilities are strategic, and which dependencies are acceptable. Then hold the line deliberately. Dependency is not inherently bad. Undecided dependency is.
4. Measure retained value. Require management to show how AI changed revenue, margin, cost per completed outcome, risk, or customer value, after counting all new costs. Usage is evidence of adoption, not evidence of return.
The board’s role is not to choose models or approve pilots. It is to test whether management can account for these four decisions coherently, whether the answers are consistent with the firm’s strategy and risk appetite, and whether capital is flowing to the operating model rather than only to the tools.
The demand side is where this gets decided
The interesting question was never how fast the model is. Models keep getting more capable on a schedule none of us controls, and what they cost depends on terms someone else sets. Betting your strategy on that curve is betting on what you have least influence over.
The question worth a board’s time is whether anyone redesigned the business around the model to use it, who inside your walls is doing that redesign deliberately rather than by accident, and how the firm knows it is keeping the value that redesign produces.
That work has a home, and it is not the supply side. The supply side will keep producing extraordinary components faster than anyone can absorb them, on terms it sets and can change. Your advantage will not come from admiring those components, or from assembling more of them than your competitors. It will come from the quality, coherence, and ownership of the system you place them in.
Your half of this exchange is contested, mostly unnamed, and largely unattended. It is also where every dollar of return on this technology is either realized, transferred, or never made at all.
That is the demand side of AI. Not a footnote to the productivity story. The one that decides whether the productivity story was ever worth telling.