I recently attended a CIO briefing where the AI program looked, on paper, like a runaway success. The company had the numbers everyone wants to show the board. Thousands of employees were using generative AI every week. Draft cycles were shorter. Internal search was faster. Software teams were pushing more code into review. Sales operations had tripled the number of account summaries it could produce before quarterly business reviews.

The slide that got the most attention showed a steep rise in "AI-assisted work products." It was a beautiful chart. In my view, it was also incomplete. Once again, I found myself as the designated buzz-kill. This is becoming a pattern.

I asked a different question: What happened after those work products were created? Who reviewed them? How many came back for correction? Which exceptions required senior staff? Did legal, compliance, QA or other teams get busier as everyone else got faster?

The answers were vague. Some teams felt faster. Some employees liked the tools. Some managers believed the time savings were real. But nobody had measured what happened after AI handed its work to the next person or system.

That is the productivity problem CIOs should be watching. AI can make one task cheaper and faster while creating more review, verification and exception work downstream. If you measure only the person using the AI tool, you can declare a win while the enterprise absorbs the cost somewhere else.

AI moves work. It does not always remove it.

Where the work goes

Don't get me wrong: faster output can be useful. AI can remove friction, speed up first drafts and help people explore options faster. But every generated answer, recommendation or artifact that matters to the business eventually reaches a trust gate: someone or something has to decide whether it is good enough to use.

That is where the work often reappears.

In my AI architecture practice, I use AI to find things that won't work so I can get to the ones that will. What used to take me a few days per architecture candidate takes a few hours now.

The biggest measurement failure I see is that enterprises measure the person using AI, not the system absorbing AI's output.

That is useful acceleration.

The time saved at the first step is only part of the economics. If faster generation creates more review, correction or exception handling at the next step, the enterprise may simply have shifted the work to a more expensive part of the organization.

The work did not disappear

The biggest measurement failure I see is that enterprises measure the person using AI, not the system absorbing AI's output.

Follow me here.

A claims analyst may produce twice as many case summaries. That looks like a win until legal review slows down because the summaries require more validation. An AI tool may draft a contract clause in seconds, but legal still owns the risk. It may recommend a supplier, but procurement still owns the consequence. It may summarize a customer call, but account management still owns the relationship.

AI often shifts effort downstream. The user gets faster, but the reviewer gets busier. The front office creates more work for compliance. The development team increases throughput into QA without increasing quality. The support team closes more tickets while repeat contacts rise. If your metrics stop at the task boundary, you will miss the enterprise cost.

This is not a theoretical problem. It is how large organizations work. Every process has handoffs, exceptions, risk controls, approvals and trust gates. AI usually looks strongest on the routine case. AI usually looks strongest on the routine case. Enterprise cost often appears in the exceptions, where additional volume can create more review work.

Verification is part of the workload

The hardest part of AI adoption is not generating something. It is deciding whether the generated thing is good enough to use. That sounds obvious, but many business cases treat verification as if it were free.

Verification can include checking sources, testing code, reviewing security, reconciling data, obtaining approvals and handling exceptions. None of that is incidental overhead. In a production workflow, it is part of the cost of using AI.

CIOs should therefore be suspicious of any AI productivity claim that stops at the point of generation. Error rates matter. Rework matters. Exception handling matters. So do escalation volume, review time and the number of expert hours consumed before AI-generated work is actually safe to use.

Here is my blunt take: a lot of enterprises are celebrating throughput while creating a queue somewhere else. That is not transformation. It is a relocation of work -- sometimes to the most expensive people in the process.

Measure the handoff

The question CIOs should ask is not simply, "How much faster did AI make this task?" It is, "What happened at the next handoff?"

AI can make a worker faster and still make the enterprise slower.

Measure how much AI-generated work is accepted without material correction. Measure review time, rework, exception rates, escalations and queue time before the output becomes an approved decision, transaction, release or customer response. Those measures show whether AI actually removed work or merely pushed it downstream.

This is boring work. It requires CIOs and business leaders to map where AI hands work off, who owns the validation and whether downstream teams can absorb the additional volume. It also requires admitting that a tool can make an individual employee more productive while making the overall process less efficient.

Sorry to break some bubbles, but you might as well hear it from me: AI can make a worker faster and still make the enterprise slower. If you do not measure the handoffs, you will miss where the work went.

David Linthicum is a globally recognized thought leader, innovator and influencer in AI, cloud computing and cybersecurity. He has more than 30 years of experience in enterprise technology and, until early 2024, served as managing director and chief cloud strategy officer at Deloitte Consulting LLP.