Most AI strategies are software procurement plans with better typography

The giveaway is not that the presentation names vendors. It is that the only commitments anyone can point to are things a vendor can deliver.

A familiar enterprise AI strategy begins with a landscape of opportunities. Then come the platform comparison, architecture diagram, security requirements, training plan and rollout calendar. The document may be thorough. It may have costed options and sensible controls. It may even be an excellent procurement plan.

But when the board asks what the business will do differently after the purchase, the answer often changes register. The vendor will enable teams. Employees will become more productive. The organization will innovate faster. Someone has described the capabilities the company expects to acquire without specifying the decisions the company is willing to make.

The distinction matters because buying software is a transaction. Changing how an organization produces value is a commitment that cannot be outsourced in the same way.

I am not arguing against procurement. A well-run procurement process protects money, data, continuity and negotiating power. I am arguing that the purchasing document and the strategy document should be able to disagree. If buying the preferred platform is still the right choice when the organization refuses to change any of its work, someone should be able to explain why.

The most revealing column is the one the vendor cannot fill

Imagine a proposal for an AI assistant used by a claims operation. The vendor promises integration, multilingual answers, access controls, analytics and a service-level agreement. Those promises can be tested and written into a contract. They say little about what happens when the assistant recommends a claim outcome.

Will a claims specialist still review every case? Which cases can be routed directly? Who owns a wrongful rejection? Does the organization intend to reduce waiting time, improve consistency, increase throughput, or change its service promise? What will it stop doing if the new process works?

These are not configuration details waiting for the implementation partner. They are business decisions. A company can buy the assistant while leaving every one of them unanswered. In that case it may have purchased a faster drafting step inside an unchanged and potentially more expensive process.

The 2025 McKinsey global AI survey reports associations between workflow redesign, governance and reported value. It is survey evidence, not a randomized demonstration that redesign always causes returns. Still, it is a useful warning against treating installation as the same event as organizational change.

A more recent NBER study of AI diffusion, using a nationally representative US business survey, found that 18% of firms reported AI use in at least one business function during November 2025–January 2026, while 57% of adopting firms used it in no more than three functions. These are adoption measurements, not financial outcomes. They show why the word 'adopted' can conceal very different operating realities.

Strategy begins with a choice that can disappoint a supplier

I would ask every AI proposal to name one business decision that must change even if the chosen product works exactly as advertised.

That decision could be to retire a redundant approval, stop producing a report nobody uses, move responsibility for exceptions to a different team, change how a customer dispute is resolved, or refuse automation where the correction cost is too high. It should be consequential enough to create disagreement. If the answer is merely 'train everyone on the tool,' the proposal has described enablement, not the intended business change.

This is the non-purchasable commitments test. Put the product away for ten minutes. Ask the accountable business owner to finish four sentences:

1. We will change this unit of work, not simply accelerate its visible subtask.
2. We will change this decision right or operating rule, with a named owner.
3. We will stop, reduce or reallocate this existing activity if the new process performs.
4. We will reverse or constrain the change if these observable harms or costs appear.

A strategy can pass this test and still be wrong. The point is not to certify success. It is to expose where the organization, rather than its supplier, is actually making a bet.

The UK government's 2025 procurement policy note on AI recommends supplier disclosure and proportionate due diligence for relevant public contracts. That is procurement guidance for public bodies, not a private-company strategy standard. It demonstrates an important boundary: even responsible buying rules principally tell you how to acquire and assess a service. They cannot decide which organizational outcome deserves to exist.

Three ledgers, not one business case

I would replace the usual single 'AI investment' line with three connected ledgers.

The supplier ledger records what the company is buying: product capabilities, deployment scope, data handling, service levels, price, dependencies, failure recovery, version-change rights and exit provisions. Procurement and security should own the accuracy of this ledger. The vendor can be held accountable for its promises.

The operating-change ledger records what the company must do: process steps removed or redesigned, human review obligations, decision authority, training time, escalation paths, accountability for harm and the destination of any released capacity. Business and operations owners sign this ledger. No supplier can sign it on their behalf.

The evidence-and-exit ledger records the alternative being compared, the unit of outcome, full operating costs, quality and risk boundaries, review date, and the person who can stop the investment. Finance, evaluation and risk functions challenge the assumptions. The sponsor does not get to convert a failed test into a success simply by choosing a more flattering metric afterward.

Consider an illustrative customer-service deployment. A vendor might reduce draft-writing time by four minutes. If the new workflow requires five extra minutes of review, the total service becomes slower. If the tool improves quality in one case category but creates expensive exceptions in another, the right investment may be a narrow deployment rather than a company-wide contract. These figures are hypothetical; they are not results from a field study.

The financial ledger should not silently convert time saved into cash saved. A minute released becomes economic value only through a plausible path: additional accepted work, lower external spend, reduced overtime, improved service, or some other outcome the organization actually values. The ten-minute business-case test explains that value path. Here the additional requirement is to make the organization accountable for changing it.

The most dangerous gap may be between incentives and software

A technology can work and still fail to change the behavior that determines outcomes.

In a 2026 randomized field study in Indian garment factories, researchers tested a worker–management communication technology. The technology alone did not produce the measured improvements relative to the control group. Paired with incentives for HR managers to respond, it increased productivity by 5% and reduced absenteeism by 13%. This was not an AI deployment. It is evidence about complementary organizational incentives, not a numerical forecast for AI.

That distinction is precisely why the example matters. Technology procurement often makes the purchased capability highly visible while treating the people who must respond to it as background conditions. But the responsiveness of a manager, the authority of an employee and the incentive to resolve an exception can determine whether a technically useful system changes the outcome.

A theoretical 2026 NBER paper on chained automation likewise models work as interdependent steps. It is a model, not an observed company rollout. Its relevant insight is that value depends on the arrangement of steps across humans and machines, not simply the efficiency of a single exposed task. A purchasing plan normally prices the component. A strategy must account for the chain.

This is also why asking what a company can absorb is not a softer question about culture. It is a hard question about whether changes in authority, staffing, exception handling and measurement can become ordinary operations.

Rehearse the exit before signing the entrance

The easiest contract to approve is often the one whose exit is left vague. A platform can become embedded in prompts, evaluations, knowledge access, staff habits and downstream processes long before anyone measures whether it is still the best choice.

Before signing, I would run a small exit rehearsal. If the provider raises prices, changes the model route, fails a material safety requirement or simply stops meeting the business threshold, what can be moved? What data can be exported? Which human decisions can be restored? Which thresholds and audit records remain under the organization's control? How long would a safe reversal take?

This is not an argument for permanent multi-vendor complexity. Switching itself has costs. The point is to price dependency as a decision rather than discover it as an emergency.

The NIST AI Risk Management Framework provides voluntary governance, mapping, measurement and management practices. It does not prescribe my three-ledger test. My synthesis is that a contract's exit provisions and an operating model's ability to recover must be designed together. If the vendor promises a recovery capability that the organization has never rehearsed, the document describes an aspiration, not resilience.

The strongest objection: sometimes buying the tool really is the strategy

For a bounded, low-risk task with stable inputs, clear ownership and measurable value, buying a standard product may be the most rational strategic decision. Not every team needs to redesign its operating model. Requiring a transformation programme for a small productivity tool can destroy the economics of the purchase.

That objection is correct. The response is proportionality, not ceremony. A small deployment can have a short decision record: what problem it solves, who owns it, what costs and risks matter, and when to stop. A large cross-functional programme requires deeper commitments. The amount of strategy should scale with the consequences of being wrong, not with the number of AI features in the sales presentation.

A second objection is that vendors increasingly sell transformation services, not just licenses. They can map workflows, train teams and recommend new operating models. Good partners can materially improve the work. They still cannot exercise the customer's enduring budget authority, accept its legal accountability or decide which internal activity should lose resources. The distinction is not between smart buyers and shallow vendors. It is between delegable implementation and non-delegable ownership.

The board question I would put at the end

Before approving the next AI contract, ask the sponsor to show three documents: what the supplier must deliver, what the organization must change, and what evidence would make it stop.

If the first document is excellent and the other two are empty, do not call the presentation an AI strategy. Call it what it is: a potentially good purchase waiting for a business decision.

The typography may be better. The decision is still missing.

Sources and evidence boundaries

• McKinsey, The state of AI: How organizations are rewiring to capture value (March 2025). Global survey and reported associations; not causal proof of the three-ledger mechanism.
• Bonney et al., The Microstructure of AI Diffusion (NBER 35141, April 2026). US business survey on adoption scope; not measured ROI.
• Adhvaryu et al., Organizational Incentives and the Returns to Technology Adoption (NBER 35445, July 2026). Randomized field experiment with a non-AI communication technology; supports the importance of complementary incentives, not an AI effect size.
• Demirer et al., Chaining Tasks, Redefining Work (NBER 34859, revised September 2026). Economic model of interdependent tasks, not a measured rollout.
• UK Cabinet Office, PPN 017 Improving Transparency of AI use in Procurement (February 2025). Public-sector procurement guidance; applicability to private enterprises is an analogy.
• NIST, AI RMF Playbook. Voluntary risk-management guidance, not a certification of this article's framework.

The non-purchasable commitments test, three ledgers and exit rehearsal are Berk Bayri's proposed decision framework. The customer-service example is illustrative.