The AI ROI gap: what the 29% do differently.

The shape of the gap

The 2026 round of enterprise-AI surveys all rhyme. Average per-company AI spend grew on the order of 65% year over year. The fraction of programs reporting meaningful ROI sits around 29%. The fraction that abandoned most of their generative-AI initiatives — paused, canceled, or quietly absorbed into the slide deck without renewal — climbed from 17% to 42% in 12 months. The 79% adoption-friction number is the gap between programs that shipped and programs that landed: a model in production that nobody downstream uses is not, in the spreadsheet sense, ROI.

What's striking is how little of the gap is explained by the model. The 29% don't have better LLMs than the 42%. They aren't on a different version of GPT or Claude. They aren't running a fork of an open-weight model nobody else has. The model layer is roughly equal across both groups — sometimes the stalled programs have more sophisticated model choices, because their procurement cycle let them lock in frontier contracts that a leaner program never had to negotiate.

The gap is upstream of the model. It's in how the program was scoped, who owned it, what it was measured against, and what the company was willing to redesign around it.

Why "more spend" stopped correlating with "more return"

For roughly 18 months between mid-2024 and the end of 2025, the prevailing playbook was to increase the AI budget and let demand find use cases. That worked when the marginal use case was novel — chatbots, code completion, drafting assistants — and when the bar for "ROI" was a comfortable productivity-survey number from the team using the tool.

The 2026 surveys are running into the second-order effect. Teams are no longer counting "I used the tool this week." They're counting whether headcount fell, whether unit cost moved, whether revenue per rep grew, whether cycle time on a named workflow dropped. On those metrics, productivity-survey numbers don't survive contact with the P&L. Reported time savings of 30% don't show up as 30% lower payroll. Reported throughput gains of 2x don't appear as 2x revenue per ops headcount. The CFO finally asked.

The 29% prepared for that question before the CFO asked it. The 42% are now retrofitting evidence — and discovering that retrofitting evidence is more expensive than building it in from the start.

Trait 1 — AI tied to revenue, cost, or risk outcomes

The first structural difference is what the program is measured against. The 29% group ties every funded initiative to one of three things: a revenue line, a cost line, or a named risk that has a quantifiable owner. The 42% group has a portfolio of "AI projects" whose success criterion is engagement, hours saved, or NPS from the team operating it.

Hours saved is the metric that aged worst. Hours saved are real for the person whose time was freed; they are not real on the income statement unless somebody made a structural decision about what to do with the freed hours. The 29% make that decision before the project starts. They reduce headcount, redirect to revenue-generating work, or lower the SLA the function is measured against. The 42% leave the freed hours where they were and watch them quietly fill back up with non-AI work that wasn't getting done before.

For document AI, this shows up cleanly. The programs that pay back tie extraction to cycle-time targets ("loan approvals in 1 business day", "claims to settlement in 4 hours") or to direct unit-cost targets ("cost per processed page below US$0.05 fully loaded"). The programs that stall measure "documents auto-extracted" without saying what auto means for the team that used to do the work, or what the company does with the saved minutes.

Trait 2 — Governance built before scale, not retrofitted

The second difference is that the 29% set up the boring parts — audit trail, model version pinning, evaluation harness, access controls, retention policy — before the program went broad. The 42% scaled first and are now retrofitting governance under regulatory or customer pressure, paying roughly 3–5x the cost they would have paid if these were in the original architecture.

Three governance elements separate the groups in practice:

• Audit trail tied to decisions, not just calls — every output has a replayable record of input, model version, prompt, intermediate steps, and final value. Without this, model regressions are invisible until a downstream owner escalates and you have nothing to compare against. We wrote up the schema we run at Cogneris for exactly this reason.
• A frozen evaluation set, refreshed quarterly — a few thousand documents or transactions with verified ground truth. Every model upgrade has to pass this set before promotion. Programs without one find out about regressions through customer complaints; the cost of that discovery path is what makes governance feel retroactively expensive.
• Tenant-level isolation and retention contracts — knowing which customer's data is in which trace, which model context, which sub-processor's logs. Programs that go broad without this find themselves unable to honor a deletion request, a sub-processor change, or a SOC 2 evidence ask without a multi-week scramble.

Governance feels like overhead the day before a regulatory audit. The day after is the day you wish you had built it in.

Trait 3 — The business owns the workflow, not the AI center

The third difference is organizational. The 29% have ops, finance, legal, or the operating function that owns the workflow holding the budget, the success metric, and the decision rights for the AI program inside that workflow. The 42% have a central "AI center of excellence" or a digital-transformation team running the program at arm's length from the function that does the work.

Centralized AI teams are useful for shared infrastructure — model access, eval tooling, observability, security review. They are systematically the wrong owner for a workflow whose success is measured in cycle time, exception rate, and policy compliance, because they can't move the parts of the workflow that aren't the AI: the queue design, the human review threshold, the downstream system, the policy itself.

The pattern that works is "shared platform, distributed builders". A small central team owns the LLM gateway, the audit-trail standard, the evaluation harness, and the security posture. The functional teams own the workflow, the prompts, the schema, the threshold, and the metric. The 29% structured the program this way from the start. The 42% are now re-orging into it, which is harder than it would have been to begin with.

Trait 4 — Treated as org redesign, not technology

The fourth and largest difference is what the program is, on the table of contents of the operating plan. The 29% treat AI rollout as a redesign of how the function works. The 42% treat it as software the function is asked to adopt.

Concretely, the redesign question is: what does the human in the loop do once the AI is running, and how is that role measured? Programs that don't answer this end up with a process where the AI does the easy 70%, the human does the hard 30%, and the human's role has not changed in any way that matters — same SLA, same headcount, same job description, same tooling. Throughput goes up modestly; cost doesn't fall; the CFO's question doesn't get a clean answer.

The redesign answer looks different in different functions, but the shape is the same. Three examples we've seen work:

In each row, the headcount and the metric move. The role moves up the value chain — toward policy, edge cases, and quality — and away from the routine work the AI is doing. Programs that don't redesign the role end up with the AI sitting next to a human who is still being measured on the routine throughput, and the team finds reasons to route around it. That's most of what the 79% adoption-friction number is actually measuring.

What this looks like specifically for document AI

Document AI is one of the highest-ROI categories of generative AI, when the four traits hold. Cycle time on document-bottlenecked workflows is highly compressible — 48 hours to 2.4 seconds is not unusual for a clean implementation. Unit cost on a per-page basis is clearly measurable, comparable, and small enough relative to loaded human cost that the savings show up in the first month, not the first year. Governance is well-mapped: document AI sits inside long-standing audit obligations (SOC 2, GDPR Art. 28, sectoral rules) where evidence is structured, expected, and exportable.

The failure modes when the four traits don't hold are correspondingly specific. A few we see often enough to call out:

• Pilot trapped on the cleanest 20% of documents — the program proves it on standardized templates, never extends to the long tail (handwritten margins, scanned exhibits, multi-language packets), and the headline savings number stays a headline. The redesigned role never materializes because the routine 80% was never fully absorbed.
• Auto-approve threshold set by the AI team, not the function owner — the central team picks a confidence cutoff that looks defensible technically but doesn't align with the function's risk tolerance. The function manually reviews everything anyway. ROI evaporates in the queue.
• No path from extraction to action — the model outputs JSON to a system that still routes manually. The work moved one keystroke earlier. We covered this one in "From extraction to decision"; it's the most common single failure pattern we see in document-AI ROI reviews.
• Unaudited model swaps — the provider ships a new model version, the extraction quality moves a few percent in unmeasured directions, the function feels regressions before the AI team sees them, trust collapses. Recoverable with the right eval harness; not recoverable without one.

The honest take

We don't get every customer through this cleanly. When we see one of the four traits missing on a first call — most often trait 4, the role redesign, sometimes trait 2, governance built in — we say so before the contract. The conversation we'd rather have early is the one where we describe what the function will look like in 18 months and whether the customer is willing to redesign toward it. That conversation tends to happen at the buyer level, not the AI-center level, which is why we lean toward selling into the function that owns the workflow rather than the central program.

It's also why our default commercial model is pay-per-page rather than annual commit. Pay-per-page forces traits 1 and 4: you can't keep paying for pages you're not processing, and you can't keep processing pages without a workflow that absorbs the output. Annual commits hide both signals for a year, and the year is exactly long enough for a stalled program to ossify. Customers who insist on annual commits up front are usually self-selecting into the 42%; the ones who pilot pay-per-page and graduate to volume agreements over six months tend to end up in the 29%.

The four traits are not novel as principles. They're what programs in any prior technology wave — ERP, CRM, RPA, cloud — had to do to land. What's new is how unforgiving the gap has become, because generative AI is cheap enough to scale a program that doesn't have them and expensive enough, in retrofit cost and trust, that the bill comes due within a year.

Closing thought

The 29% number is not an indictment of the technology. It's the technology's first honest survey. Every prior wave had a comparable gap; we're simply seeing it earlier and louder this time, because budgets moved faster than program design. The 29% who built the four traits in are seeing the unit economics the marketing always promised. The 42% who didn't are now doing the harder version of the same project — getting to the same place through a re-org and a retrofitted governance layer instead of through a clean start.

For the document-AI program design we use with customers — the routing, the audit trail, the role redesign, and the pricing model that keeps incentives honest — see our product page or talk to our team. We're happy to walk through what the four traits look like for a specific function, and where we'd push back on the program before we'd take the contract.