AI Transformation Is Still Transformation

Last week I argued that AI needs an architect: someone accountable for connecting an objective to the operating reality of a workflow. This briefing is about the playbook that architect runs across the enterprise. Most leadership teams have already done this before.

The distance between momentum and value shows up clearly in McKinsey’s 2026 State of AI survey. Eighty percent of respondents say AI has improved their own productivity. Thirty-seven percent report any contribution to their organization’s earnings, essentially unchanged from a year earlier. Individual momentum is real. Enterprise value arrives more slowly, and volume alone does not bring it.

Three shortcuts are often mistaken for a strategy. The first is counting activity: licenses issued, pilots launched, agents deployed. The second is hiring scarce AI talent and expecting it to carry the program. The third is buying the most capable tools. Each can be a sound investment. None of them decides what the work is for, who owns the result, or when the old way of working ends.

Those decisions belong to a discipline most organizations already know.

You Have Run This Playbook Before

Cloud migration is the closest recent parallel, and nearly every executive team lived through some version of it. The programs that delivered value shared a recognizable structure, the same one that AI transformation follows. In other technology like databases, or analytics tools, we can draft a similar transformation map.

None of these rows requires a new kind of executive. They require the decision rights, sequencing, and cost accountability that made cloud programs work, applied to a new class of system.

The technical though depth is real. MLOps reference architectures, the NIST AI Risk Management Framework, and stage-gate methods describe it well, and that detail belongs with your architects and risk teams. The executive layer is the playbook.

Value Lands When the Old Work Ends

The most important row in that table is the last one. Cloud savings arrived when the data center lease ended, not when the first workload moved. Until then, the organization paid for both.

I learned the same lesson leading big data and data science transformations at Optum. A new data platform created real value on its own: faster analysis, new capabilities, and questions we could not answer before. Much of the financial value arrived later, when we shut off the expensive legacy databases and workflows the platform replaced. Running old and new side by side was the most expensive state of the whole program.

AI follows the same pattern. Minutes saved in a contact center, hours saved preparing appeals, and faster clinical documentation are possible benefits. They become business value when leadership decides what changes as a result: staffing plans, overtime, service levels, turnaround commitments, or work retired from a legacy process.

Two disciplines follow directly. Name the work to be retired or redeployed before deployment. And never book the same released hours as both cost savings and new capacity. Time saved is evidence of a possible benefit. Converting it into a business outcome is a management decision.

This is where the ownership argument in Why AI Adoption Stalls in the Middle becomes concrete. The leader who owns the budget where savings land is the leader who has to retire the old work.

The Amendment: Behavior Keeps Changing

Here the analogy needs care. Cloud migration moved deterministic workloads. Once an application passed acceptance testing in its new environment, its behavior was generally consistent. AI systems are probabilistic, and that changes three parts of the playbook.

Acceptance testing never finishes. Models, vendors, prompts, and data change underneath a deployed system. Validation continues in service, and a material change reopens the decision that approved it. The inspectable checkpoints in AI Needs an Architect are how that validation stays practical.

Exploration is far cheaper. A migration had a finite application list. AI produces many more candidate uses, and most should be tested quickly and stopped quickly. Early decisions need to be lighter than a traditional gate, and the expected proof should rise with each commitment of money, users, data, or authority.

Some of what you deploy acts. A migrated workload executes instructions. An agent makes decisions across tasks. Like a new worker, it needs an owner, access limits, and visibility. That is the argument of Beyond Human-in-the-Loop, and it is the part of the playbook with no clean cloud precedent.

How the Series Fits Together

This playbook is the sequence that runs through the earlier briefings. The Four Pillars describe the conditions it needs. Why AI Adoption Stalls in the Middle covers the leaders who have to own it. The Trust Layer sets out what must be true before a use case scales. Beyond Human-in-the-Loop addresses controls for non-human work. AI Needs an Architect covers the design of each workflow inside it.

Start From Where You Are

If AI tools are already deployed, treat the next step like a migration assessment. Establish what is running, who owns it, what it costs, and what it is meant to replace. Address unacceptable risk immediately. Then put the next wave behind an explicit decision.

If you are still exploring, start with workflows where you can name the legacy work that would be retired or redeployed. That single requirement filters out most of the activity that never becomes value.

The four questions in AI Needs an Architect remain the right test for an individual workflow. At the portfolio level, three more belong in front of the executive team.

None of this requires waiting for a perfect operating model. The plan will change as you learn. Its job is to keep the objective, the owner, and the next commitment connected while it does.

Keep the momentum. Make the plan match the action.