Ask ten executives what they bought when they bought AI, and nine will answer in the language of speed. Faster drafts, faster code, faster analysis. That answer is not wrong. It is just answering a smaller question than the one their business is actually facing, and most boards are budgeting against it anyway.
The story everyone is telling
Every AI vendor sells efficiency, because efficiency is easy to measure and easy to sell. Time saved. Tickets closed. Words drafted, code shipped, output per person. Leadership buys the same story because it fits neatly into a line item: the same work, done faster, for less. The finance team can model it, the board can approve it, and everyone can point at a number next quarter.
It is not a false story. Work genuinely does get faster, and the savings are real enough to show up in a report.
But productivity only ever answers one question: how do you do the work you already do better? It takes the shape of the business as given and asks how to run it more efficiently. That is a legitimate question. It is just not the question this technology is posing.
The question underneath is what kind of business you are becoming while you optimize the one you have. Where will capability live? What will you own outright, and what will you rent, on terms someone else sets and can change? Who is accountable for an outcome when no person produced it? And how much of the value created will your business actually keep, rather than hand to a supplier or compete away in price?
Those are not technology questions. They are questions about the firm’s operating model, and almost nobody is budgeting for them.
What the demand side of AI actually is
Before going further, I want to define the term precisely because it does all the work in this argument and is routinely misused to mean a market segment.
The demand side of AI is the discipline of assembling supply-side components (models, tools, platforms, infrastructure) into a coherent operating model that fits how your business genuinely runs, and of holding the control points that determine who captures the value it produces.
It is not a buyer category. It is not procurement. It is not a technology function. It is the design and ownership of the system into which purchased capability is placed.
Three things that follow
Three things follow from that definition, and each is a position rather than an observation.
First, the demand side is a discipline, not a purchase. Nothing you buy produces it. It has to be built by named people with real authority inside your walls.
Second, nobody outside your walls can do it for you. Not because external help is worthless, since advisors and suppliers are essential, but because the raw material of the work is your workflows, your customer commitments, your judgment calls, your risk appetite, and your institutional knowledge. Those are not available to anyone else at sufficient resolution. An operating model you did not author is one you cannot govern, defend, or change.
Third, this is where the economics are decided. The supply side is largely settled in ways no individual enterprise can influence. The demand side is contested, largely unaddressed, and is where every dollar of return from this technology is either realized, transferred to a supplier, or lost to friction.
The rest of this piece defends those three claims.
The capability structure underneath the business
Start with what is actually changing, because the usual framing gets it wrong in a way that matters.
For most of the last thirty years, knowledge-work capability sat firmly on one side of the ledger. It lived in people. You hired them, paid them annually, trained them, promoted them, and lost some to competitors. Expertise walked in the door each morning and out again each evening. It was a labor cost, and nearly every management practice you have (headcount planning, performance reviews, succession planning, span of control) was built on that assumption.
AI changes that capability structure. Not simply the cost of the work: the structure of where the capability sits.
This is not a straight substitution of software for people. That framing is both wrong and strategically misleading, and it is why so many AI business cases fail to survive contact with reality. What actually happens is messier. Some work disappears. Some becomes dramatically cheaper. Some becomes more valuable precisely because far more of it can now be done. Judgment migrates toward specification, supervision, exception handling, and assurance. Entirely new work appears in the areas of orchestration, evaluation, and control.
Three tiers, three risk profiles
The result is a different production model for knowledge work, composed of three tiers that behave in fundamentally different ways.
Owned capability. Proprietary workflows, institutional data, evaluation systems, codified operating knowledge, the specifications that make a system do your work rather than generic work. This tier is an asset. It appreciates with use, compounds with investment, and cannot be bought by a competitor.
Rented capability. Models, compute, APIs, platforms, infrastructure. This tier is a service, accessed on someone else’s terms, at prices they set and change, with capabilities they can deprecate, restrict, or reprice.
Augmented human capability. People, but in different roles and with different leverage: defining the work, handling what the system cannot, owning the outcomes, and holding the judgment that cannot be specified.
Each tier has a distinct economic and risk profile, and confusing them is how firms end up surprised. Labor costs scale with headcount and move slowly and visibly. Compute costs scale with usage and can move sharply on a supplier’s pricing decision. Human capability degrades gradually through attrition you can usually see coming. A supplier can reprice or withdraw rented capability on contract terms. Owned capability is the only tier that becomes more valuable over time, and only if the firm retains the knowledge required to operate and improve it.
None of this is an argument against renting. Renting is mostly correct, and the alternative is usually a waste of capital. It is an argument that a shift in where productive capability is located warrants the seriousness a board applies to any other structural change in the business.
The question a board would ask about anything else
If a company announced it was moving a substantial share of its production capacity from owned facilities to leased ones, no board would treat that as an operational detail. It would ask about terms, dependencies, concentration, counterparty risk, pricing exposure, and the cost to reverse. A comparable shift is now underway in knowledge work, and most organizations track it as a decentralized software budget, approved on a per-department basis.
What determines the return
Deciding that capability now lives partly in systems and contracts rather than purely in labor is only the first move. It tells you what you are buying. It tells you nothing about what you will get for it.
The return is determined by the operating model wrapped around that capability.
An asset with no operating model around it produces activity, not returns. This is not unique to AI. A factory with no production system is a building full of expensive equipment. A trading desk with no risk framework is a way to lose money quickly and with great sophistication. The asset creates potential. The system around it determines whether that potential reaches the income statement.
This is the bridge between the two halves of the argument, and it is the connection most discussions miss. Capital allocation sets up the problem. The operating model answers it. Firms that get the first part right and the second part wrong will have restructured how they buy capability without changing what they get from it, taking on new dependencies, new cost volatility, and new governance exposure in exchange for a modest efficiency gain they could have had without any of it.
That failure mode is currently far more common than either outright failure or genuine transformation. It is also the hardest to detect, because every number in the report is true.
Where the return actually leaks
When AI fails to produce enterprise value, the cause is rarely the model. The value escapes through a small number of ordinary, well-documented mechanisms.
Isolated task acceleration. One step in the workflow gets faster while the end-to-end process remains governed by the same approvals, handoffs, and queues. The constraint sets throughput, and the constraint sat somewhere else.
The review and rework tax. Output rises, and the work of checking, correcting, and assuring that output rises with it. Net effort barely moves, but it moves to more expensive people.
Uncaptured capacity. Time comes back in small increments across many individuals and never aggregates into anything the business can spend on: no additional revenue, no reduced costs, no better service.
Supplier capture. Consumption pricing absorbs the gain. The firm is more productive and no more profitable.
Customer capture. Rivals compete the gain away. In markets where everyone gets the same efficiency at the same time, the surplus passes to the buyer as lower prices. This is entirely rational and entirely fatal to the business case.
Accidental architecture. Departments adopt overlapping tools without a composition rule. Two years later the firm has integration debt, duplicated spend, and a set of dependencies nobody chose.
Structure plus cost. The firm keeps the old roles, approval chains, and measures intact, then adds a new technology cost on top.
Two firms that got exactly what they measured
Consider how this looks in practice. A firm puts AI into a claims workflow. Drafting and summarization time falls sharply. Every adoption metric is green: usage is high, satisfaction is good, the pilot is declared a success and scaled. End-to-end cycle time does not change because no one touched the multi-stage sign-off above the drafting step. The firm bought speed and kept the queue.
Or take a professional services firm that accelerates proposal production. It now produces more proposals, of similar quality, at lower marginal cost. Win rate is unchanged because it was never a function of proposal volume. The firm has industrialized an activity that was not the constraint on its growth.
In both cases, the local efficiency is real, measurable, and auditable. The enterprise return is close to zero. Nobody stole anything. The value simply fell into the gap between a capability the firm now pays for and a system nobody was assigned to redesign.
Two stacks, and only one can be yours
To see where that gap sits structurally, separate what is happening into two stacks.
The first is the technical stack. At the bottom sit the chips. Above them, the data centers and the power to run them. Above that, the models. Above that, the tooling that lets you deploy, meter, secure, and monitor what those models are doing.
This stack is enormous and extraordinarily capital-intensive, and a small number of labs, chipmakers, and hyperscalers shape its economics. Competing at any layer costs billions, and the pace of change turns this year’s advantage into next year’s commodity. Most enterprises will not build durable advantage at the model or infrastructure layer, and such attempts are usually a misallocation of both capital and attention. The correct posture is to buy what you need, choose your dependencies deliberately, preserve switching options where they are worth their cost, and refuse to confuse technical novelty with business differentiation.
The stack that can be yours
The second stack is the one that can actually belong to you, and it is the reason two firms buying identical technology get entirely different results.
At its base sits specification: how work gets defined precisely enough that something other than a person can pick it up and do it. Above that sits organizational fit: the norms, the judgment calls, the customer knowledge, the risk tolerances, the things everyone knows and nobody wrote down. Above that sits accountability: who owns the outcome when a person did not personally produce it. Above that sits workflow architecture: the end-to-end process made explicit, rather than living in the heads of people who have been there long enough. And at the top sits value capture: how the improvement shows up in what you deliver, what you charge, and what you keep.
Call this your demand-side stack. It does not compete with the technical stack. It sits on top of it and determines what the technical stack is worth to you. That label describes the territory; it is not the name your firm should operate under. The operating name has to come from inside the business, and I return to why below.
It is also the only part of this that no vendor can sell you, because it has to be built around your business. There is no version available off the shelf, which is precisely why so little of it gets built.
Where the money actually goes
Now look at where the money goes. Most organizations concentrate AI spending overwhelmingly in the first stack: licenses, seats, tokens, pilots, platform fees. The second stack gets whatever attention remains after the tools are deployed, which is usually not much. The exact split is rarely measured, and any industry figure quoted for it deserves caution. The asymmetry itself is consistent enough across organizations to name plainly.
That asymmetry is the leak. The capability arrives and lands on workflows, job roles, incentives, and approval chains designed for the old cost of labor and never redesigned for the new one. The firm now owns something powerful and has nowhere for its power to go.
Components are not systems
This is where most enterprise AI programs quietly go wrong, and the mistake is subtle enough that intelligent people make it repeatedly.
Buyers walk in looking for a tool. They evaluate a shortlist of models or platforms, run a bake-off, negotiate a contract, and sign. Then they wait for the operating model to assemble itself around the purchase. It does not assemble itself, because nothing in the purchase was ever going to produce it.
A model is a component. A workflow tool is a component. A governance policy is a component. A training program is a component. None of them, alone or stacked in a procurement folder, is a system.
The kitchen test
Think about how you would actually renovate a kitchen. You do not buy the best refrigerator, the best stove, and the best faucet, set them down on the floor, and call it a kitchen. Someone has to decide the layout, run the plumbing and the wiring, work out where the plumbing conflicts with where you wanted the island, and take responsibility for whether the whole thing functions once it is installed. That person is not a supplier. The appliance manufacturers are excellent at appliances and have no view on your kitchen at all.
The appliances are supply side. The kitchen is demand side.
Nobody would confuse those two things when renovating a house. Yet that is precisely the confusion running through most enterprise AI programs today: a shopping list mistaken for a plan.
Someone has to be the system builder
The researcher Sangeet Paul Choudary, in Reshuffle, describes a category of firm that wins not by building the best individual component but by reengineering the entire system around it, taking on the financing, the integration, the risk, and the accountability that components alone cannot handle. He calls this a system builder. On the supply side it is already a recognizable and well-funded strategy. It is what the more sophisticated vendors are quietly becoming while they sell you tools.
What gets far less attention is that the same discipline must exist on the demand side, within the buying organization, or it does not exist at all.
Someone has to be the system builder for your business. If no one within your walls holds that role, you are not running your own system. You are running a system somebody else designed that happens to have your logo on the login screen.
This is the central claim of the piece, and it has a specific organizational meaning that is easy to soften into nothing.
The system builder is not necessarily a new title, and it is emphatically not a steering committee. It is a locus of authority. Whoever holds it must be able to redesign workflows across functional boundaries, set and enforce rules about what may connect to the operation, change measures and incentives, reallocate released capacity, and assign accountability for outcomes produced by systems. Responsibility without those rights is coordination theater, and coordination theater is the most common form this role currently takes.
“Isn’t this just enterprise architecture?”
A capable executive will push back here, and the objection deserves a direct answer. Firms have done process redesign, enterprise architecture, operating-model work, and IT governance for decades. Is this not the same discipline with new vocabulary?
It is the same lineage. It is not the same problem, for three reasons.
The clock changed. Traditional architecture assumed multi-year planning horizons over systems you owned, on roadmaps you set. Suppliers reprice, upgrade, deprecate, and redefine AI capability on release cycles measured in weeks. A planning cadence built for owned systems cannot govern a cost base that moves between planning cycles.
The control points moved outside the building. Historically, governance concerned systems inside your perimeter. Now suppliers increasingly set what gets measured, the thresholds at which decisions happen, and the boundaries of what a capability will do, and you inherit those choices as defaults. Governing your own systems is no longer sufficient, because products you do not control now make decisions that shape your operation.
Defaults harden faster than they can be reviewed. Traditional architecture had time to review a dependency before it became structural. Adoption now runs ahead of governance by default, and an unexamined setting becomes an architectural fact in months.
So: same lineage, materially harder problem, and one that now sits above the technology function rather than inside it. That is why it needs an executive owner rather than an architecture review board.
The five control audits
If the demand side is a discipline rather than a purchase, it needs to be specific enough to act on. This is the part that turns the argument into work.
Choudary identifies five forms of control that determine who holds power in a coordinated system: representation, decision, execution, composition, and governance. He uses them to analyze how power moves between firms. They work just as well turned inward, as an audit of your own operating model. Take any workflow where AI now touches the work, and ask five questions.
1. Visibility: who owns representation?
Who decides what the system can see, how the work is described, and what gets measured?
This sounds technical and is not. Representation determines what counts as a fact inside your organization. If the only view of how a process is performing comes from a supplier’s dashboard, measuring what that supplier chose to measure, then someone with a commercial interest in how it looks has authored your picture of your own operation.
The question is not whether you have data. It is whether you defined what the data means.
2. Decision rights: who owns the decision?
At the point where the work produces an output, someone or something determines what happens next. Increasingly, a system makes that determination, using default thresholds nobody has examined, rather than a person who could explain the reasoning.
Not every decision needs a human. Every consequential decision needs a named owner who knows it is theirs, understands the basis on which it is being made, and has the authority to change it.
3. Execution authority: who is allowed to act?
Once the decision is made, who or what carries it out, and where can the action be interrupted?
Systems that decide and execute in one motion are fast and give you no place to intervene. That may be exactly right for low-stakes, reversible work. It is rarely right for anything that reaches a customer, an employee, a regulator, or a financial account.
4. Architecture: who owns composition?
Who sets the terms for what is allowed to plug into your operation? Where is dependency acceptable, and where is the ability to switch strategically necessary?
Every tool adopted without a composition rule is a dependency acquired by accident. Multiply that across departments over two years and you have an architecture nobody chose. Dependency itself is not the problem; undecided dependency is.
5. Governance: who can set the rules and stop the system?
Who writes and enforces the rules for how all of the above operates? Who investigates failure? And who has the authority to halt a live system when commercial pressure favors leaving it running?
Governance is not a policy document. It is a functioning allocation of authority, and the test of it is whether someone can actually stop something.
Run these five questions across the handful of workflows where economic value or enterprise risk is concentrated. The answers produce an honest map of your operating model, including the parts currently held by a supplier. Some will be reassuring. Several will be a vendor’s name, an inherited default, or a blank.
The blanks are where your value is leaking. Not into anybody’s pocket, particularly. Into the gap between a capability you now pay for and a system nobody was assigned to build.
Name it yourself, before someone names it for you
There is a reason this matters now rather than in some comfortable future quarter, and it is not the usual appeal to urgency.
Suppliers are writing the vocabulary for this territory as you read this. Every major AI and infrastructure vendor already has a name for the system around the model, and every one of those names quietly positions their 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.
Why the words matter
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 answer the operating-model conversation within 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. Adopt a vendor’s framing for your own operating model without translating it into your own, and you have not adopted AI. You have adopted their business model and put your name on the front of it.
So name your own. “Demand-side stack” names the category, and a category name will not run your business. Give the thing you are building 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 stack is still forming, and you hold 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 so with real numbers, which 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 |
| Pilots launched | Share of the gain retained, versus passed to suppliers or customers |
| Theoretical hours saved | Exception, rework, and assurance rates after deployment |
| Model benchmark performance | Supplier concentration, switching cost, and time to switch |
| No supplier equivalent | Share of consequential decisions with a named accountable owner |
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.
Four decisions that belong to leadership
This is not an implementation agenda. It is the set of decisions that cannot safely be delegated to a technology program, because each one allocates authority rather than resources.
1. Name the system builder. Decide who owns the end-to-end operating model, and give that owner the rights required to change workflows, measures, and incentives across functional boundaries. The title matters far less than the decision rights. If the answer is a committee, the answer is nobody.
2. Choose the workflows 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 that someone identify the constraint before anything gets accelerated.
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 answer these four questions 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. Every model gets faster and cheaper on a schedule none of us controls, and betting your strategy on that curve is betting on the one variable you have no 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, and the competition there is largely settled in ways none of us can change. Your advantage will not come from admiring those components or from assembling more of them than your competitors do. It will come from the quality, coherence, and ownership of the system you place them in.
The demand side is contested, mostly unnamed, and largely unattended. It is also where every dollar of return on this technology is either realized, transferred, or lost.
That is the demand side of AI. Not the smaller story underneath the productivity one. The one that decides whether the productivity story was ever worth telling.