“We already bought AI” sounds like a conclusion. It is often the beginning of a harder conversation: what changed in the work?

A signed agreement establishes commercial commitment. Licenses establish access. A model response establishes technical capability. None of those facts tells an executive whether a consequential workflow has changed, whether people use the new path, or whether the organization can operate it next month.

That distinction matters because adoption is broad while scaled value remains uneven. McKinsey’s 2026 state-of-AI research describes widespread use and a continuing gap in scaled impact. PwC’s 2026 CEO research also reports uneven business effects and emphasizes operating foundations. A separate PwC mid-year snapshot supplies more current context from a different sample.

Those studies do not use the same population or definitions. They should not be compressed into one universal number, and they do not prove that one management practice causes ROI. They do support a practical observation: access is no longer the only scarce fact. Operating change is.

My proposed frame separates four gaps. Each needs a different owner, budget, and decision.

Gap one: access

Access is the commercial and technical layer. The organization has approved accounts, a model endpoint, a platform, or an enterprise product. Procurement, security, architecture, and legal may have completed meaningful work to make that possible.

Access creates options. It does not create an operating capability by itself.

The failure mode is easy to recognize. Weak value evidence leads to more seats, another model, a larger commitment, or a new innovation fund. That response is sensible if product access is the actual bottleneck. It is wasteful if the blocked work has no process owner, no usable data, or no path through production controls.

The accountable owner at this stage is usually a platform, procurement, or technology leader. The decision is whether access is sufficient and appropriately governed—not whether the workflow is delivering value.

Gap two: working evidence

Working evidence is narrower than a demonstration and more useful than a promise. It shows a named user completing a bounded part of a real workflow with representative inputs, visible outputs, known constraints, and an agreed review method.

A working slice should answer concrete questions. Which systems are involved? What happens when the model is wrong or uncertain? Who can approve an action? Which exceptions remain human work? Where is the result recorded? What would cause the team to stop?

This is where general capability meets operating context. It is also where many “successful pilots” become ambiguous. A polished demo can prove that a product works under prepared conditions. It does not prove that the workflow survives real permissions, messy data, edge cases, review queues, and ownership boundaries.

The owner is a product or process leader working with a technical owner. The budget belongs against a bounded workflow and evidence plan, not an open-ended exploration.

Gap three: adoption

Adoption is not a training deck delivered after the build. It is the redesign of work around the capability.

Current research associates deeper workflow redesign with stronger reported results. That association is useful but not universal causal proof. The practical signal is more modest: putting AI into an unchanged process often leaves its hardest constraints untouched.

Real adoption requires decisions about roles, handoffs, escalation, incentives, and exceptions. A reviewer may need a new queue. A manager may need a new control. A security owner may need auditable logs. An operator may need permission to reject a recommendation. A technical team may need to own regressions after a model change.

If those decisions are absent, usage can rise while the old workflow remains the real system of record. The accountable owner is the business leader who can change the work, supported by technical, risk, and enablement owners. Adoption cannot be delegated entirely to the product vendor or implementation team.

Gap four: operating value

Operating value begins with a baseline and ends with an observed change that can be discussed honestly.

The measure differs by workflow. It might be cycle behavior, decision quality, exception volume, service capacity, risk exposure, cost, or revenue. The point is not to select the most impressive metric. It is to name the source, owner, review window, and attribution limits before the result is known.

Time saved in a controlled test is not automatically cash saved. Higher usage is not automatically better performance. A revenue movement may have several causes. Evidence-aware leadership preserves those limits instead of turning every favorable signal into AI ROI.

Sometimes the evidence supports expansion. Sometimes it supports a pivot. Sometimes it produces a defensible stop. All three reduce uncertainty.

Define the deployment unit

Before expanding spend, define one deployment unit:

  • one consequential workflow and named target users;
  • a business owner and a technical owner;
  • representative inputs and explicit system boundaries;
  • an evidence standard and review window;
  • an exception and escalation path;
  • an operating owner after the initial build; and
  • a stop condition.

This is ScottFelten.com analysis, not an industry standard or a performance guarantee. Its purpose is to move the conversation from “Do we have AI?” to “What are we changing, who owns it, and what evidence would justify the next decision?”

A bounded deployment makes missing ownership visible. It can end in a working solution, a pivot, or a defensible stop.

The next time someone says the organization has already bought AI, ask which gap remains: access, working evidence, adoption, or operating value. Then fund the responsibility that is actually missing.

If the answer is unclear, start with a bounded diagnostic—not another expansion of access.