Deloitte says 60% of enterprises have redesigned jobs around AI to at least a moderate degree. McKinsey puts fundamental workflow redesign at about a quarter of the firms outside its high-performer group. Both numbers are probably right. They aren't one number measured two ways. They are answers to two different questions, at two different thresholds, on two different populations.
The trouble starts later, and inside your own building. By the time findings like these reach an executive update, the distinctions that make them defensible have been sanded off. Moderate job adaptation, fundamental workflow redesign, and AI that actually moved the P&L arrive as a single word: transformation. Each is a different claim that needs a different kind of evidence. The reporting layer treats them as interchangeable.
That isn't usually anyone lying. It's a label doing more work than the evidence under it can carry.
Picture a common pattern. A platform team wires an AI coding assistant into stub generation, and what took an engineer most of a morning now takes minutes. Reported upward, it reads as a win, and the speed is real. But trace the request end to end. The security review, the schema validation, the staging sign-offs (the queue the work actually sits in) are untouched. No gate removed, no handoff automated, no decision right moved. One step got faster. The surrounding process did not change; the work just reaches the next unchanged queue sooner.
The risk isn't the optimism. It's what the label unlocks. Once that initiative is booked as "workflow redesign," it gets cited in the quarterly update, used to argue for a bigger license footprint, and marked done, without anyone establishing that the operating model changed.
A test you can run on any claim
You don't need the industry to agree on vocabulary to fix this. You need a test you can apply to any initiative in your portfolio, one that states what evidence would make the claim true, and what would falsify it. Three questions. They're independent; a yes to one doesn't buy you the others.
First, structural change. What in the process actually changed: which steps, handoffs, decision rights, or exception paths were permanently altered? The falsifier is blunt: if the same chain of human approvals and handoffs exists today as six months ago, the workflow wasn't redesigned, no matter how fast the individual steps now run.
Second, operational impact. Did the end-to-end result move: cycle time, throughput, quality, reliability across the whole transaction, not speed inside one step? A workflow can be genuinely rebuilt and still not move the end-to-end number. That's worth knowing, not hiding.
Third, economic value. After the fully loaded cost of delivering the outcome (inference, platform licenses, human exception handling, rework), is there a net benefit left?
The point of keeping these separate is that they describe genuinely different situations that reporting flattens into one. A team can rebuild the workflow and show no operational gain. It can post real savings from a narrow automation while redesigning nothing. It can know its unit economics cold while the process sits exactly as it was. Rolled into a single "transformation" figure, those three are indistinguishable, which is the whole problem.
The third question is where most reporting is thinnest. Deloitte found 71% of organizations track their total AI inference and API spend, but only 44% track cost per unit of work. Knowing the aggregate bill is not the same as knowing what one completed transaction costs, and without that, the economic claim is an assertion wearing a number. That gap is its own discipline; it isn't caused by the workflow being un-redesigned, and it needs its own answer.
Monday morning
Take one initiative logged as an "AI transformation." Skip the vendor slides. Ask the owner two things: which specific approval gates or handoffs came out of the process map, and what a completed transaction costs now versus before.
If the honest answer is that individual tasks run faster while the surrounding chain, the queues, and the unit economics are unchanged, keep the tool, bank the efficiency, and change the ledger entry from "workflow redesigned" to "task improved."
The distinction isn't bookkeeping pedantry. Your next investment decision rests on what you claim this one achieved. Enter a verified task improvement as proof of transformation, and you'll fund the next stage on a foundation you never actually built.