How to Convert Your AI Capability Into AI Returns
I read something this week that made a light go off — not because of what it said, but because of what it confirmed.
Jiaona Zhang, Chief Product Officer at Laurel and a Stanford product management lecturer, described what she’s calling the hottest new role in AI: the AI Ops job. Her framing: “I think every company should be hiring for this AI workflows role. It’s the new Biz Ops.”
The light that went off wasn’t about career advice for new grads. It was recognition. I built that function — about a decade ago, for a different automation wave.
If you read the previous post in this series, you know the numbers: enterprise AI spend projected at $2.52 trillion in 2026, and — per PwC’s 2026 Global CEO Survey of 4,454 chief executives — 56% reporting no measurable return on it. I wrote about why the gap exists — integration failure, the happy path trap, the Klarna cautionary tale. What I didn’t name directly was the structural fix. This is it.
The two benefits that keep getting confused
AI delivers two fundamentally different kinds of value, and they are routinely conflated.
The first is personal amplification: AI makes individuals faster. Writing, research, document review, analysis — tasks that used to take hours take minutes. This benefit is real, well-demonstrated, and available to anyone willing to learn the tools. When a CEO spends an afternoon with an AI assistant and gets three hours of work done in forty-five minutes, this is what they’re experiencing. It’s genuine and not trivial.
The second is workflow automation: AI replaces or substantially transforms multi-step organizational processes — the kind of work that requires coordinated effort across systems, departments, and handoffs. This benefit is also real, but it is harder, slower, and requires a fundamentally different organizational investment than buying more seats on a platform.
Here’s where the ROI gap lives: most organizations are getting the first benefit and expecting it to produce the second.
When a CEO sees AI double their personal productivity, the natural instinct is to buy tools for the whole workforce and expect the benefit to scale. But individual productivity gains don’t automatically become process improvements. A team of faster individuals still has the same handoffs, the same bottlenecks, the same systems that don’t talk to each other. The speed gain sits inside each person’s daily tasks and doesn’t flow through to the business’s operating results. Research confirms this pattern: according to Section.ai’s 2026 AI Proficiency Report, only 2% of knowledge workers are using AI for organizational-level automations. The other 98% are moving faster individually while the business results hold flat.
The structural answer Zhang is naming — and what it actually requires
Zhang’s point isn’t really about new grad hiring. It’s about the organizational function that doesn’t exist in most companies: people whose explicit job is to look across operations, identify where AI can transform actual workflows, and then implement those changes. Not advise on them. Implement them.
To make this concrete: take month-end close in a finance operation. An AI Ops team doesn’t deploy a general AI tool and hope the team figures it out. It maps the actual workflow step by step, identifies where AI can process high-volume, routine transactions reliably, builds explicit human review checkpoints for exceptions, and defines what success looks like at each stage. The result is a close cycle that runs faster and fails predictably — not a faster team running the same process.
Box CEO Aaron Levie signaled the same thing last month, posting about a new role they’re building: the “AI business automation engineer,” with a salary ceiling of $183K. “I expect most companies will have many flavors of this going forward,” he wrote.
They’re both describing the same missing layer. And I know what it looks like in practice, because I built a version of it.
The RPA precedent — already played out
When I led a process improvement group for a large finance and accounting operation, this is exactly what we built — under a different name.
We started with process improvement specialists whose job was to work alongside process owners, map how work actually flowed (not how the documentation said it flowed), and find opportunities to improve. When RPA entered the picture, these roles became the translators between operations and technology. We added a technical lead to handle infrastructure and governance, brought in offshore coding support for implementation throughput, and built relationships with IT for server space and version control.
We weren’t just buying automation software and turning it loose. We were running an organizational function whose explicit job was to convert automation capability into operational returns.
And here’s the detail that matters most: every single time we mapped a process for automation, we found process improvements to make first. Sometimes minor, sometimes significant. The automation was almost always the last step. The process work — understanding what was actually happening, not what the documentation claimed — was the real work.
The function was a Trojan horse for process improvement. The automation came after.
One design detail from that work applies directly to AI workflows and rarely gets the attention it deserves: exception handling. For every process we automated, we designed three failure tiers — what the automation handles on its own, when to pull in a human to clear an exception, and what we called the off-ramp: a clean signal that the process cannot continue, handing everything back to a person before something broke silently. Every AI workflow needs those same three questions answered before it touches production.
Organizations that built functions like this got durable ROI from RPA. Organizations that treated RPA as an IT project or left it to individual enthusiasm got bots that broke when something changed and nobody owned the fix.
Before treating AI workflow design as a direct RPA transplant, there is one structural difference worth naming: RPA is deterministic. Given the same inputs and rules, it produces the same output every time, and it fails loudly when it can’t proceed. AI is probabilistic. It handles unstructured data — PDFs, emails, natural language — that RPA couldn’t touch. But it generates outputs with a confidence it doesn’t always deserve, and it doesn’t stop when it’s wrong. An AI Ops team has to design confidence thresholds and validation checkpoints into every workflow — and the off-ramp matters more, not less, because the failure mode is quiet.
How you structure it matters
Zhang presents AI Ops as something an ambitious individual can create from scratch at any employer. That’s a reasonable starting point. As organizational design, it’s not the destination.
Three structural models exist in practice.
Centralized, within IT: A shared-service AI Ops team; IT owns infrastructure and governance; process specialists are deployed to business units as needed. Strong on institutional knowledge and governance, but risks becoming a bottleneck and losing domain depth over time.
Decentralized, within business units: Each function owns its AI capability, with IT support as required. High domain knowledge and faster deployment, but risks fragmentation — every department building its own infrastructure, no institutional learning, governance gaps.
Hybrid/federated: A small central team sets standards and handles cross-functional implementations; embedded AI workflow leads in each department manage the domain-specific work and escalate to the center when needed. This is the model that serious RPA programs evolved toward, and in my experience it’s the right template for most organizations.
My preference was always to put the process specialist as close to the process owner as possible. The central function matters for governance and knowledge-sharing. But the work that actually converts capability to returns happens at the intersection of process knowledge and domain expertise — and that only lives inside the business units.
The same gap, the same fix
The AI adoption cycle isn’t going to play out identically to RPA. The capability is more powerful, the potential upside larger. But the failure mode at the organizational level is structurally identical: deploying a capability without building the function responsible for making it work in the messy reality of operations.
The 12% of companies actually getting both top-line and bottom-line results from AI — what PwC’s 2026 Global CEO Survey calls the AI Vanguard — aren’t doing something exotic. They’ve built what successful RPA programs built: a dedicated function whose job is to close the gap between capability and deployment.
The question worth asking now isn’t whether to invest in AI. It’s whether you’re investing in the function that converts AI capability into organizational returns — or just buying more tools and expecting the math to work itself out.
Have you seen an AI Ops function work — or fail to materialize — inside your organization? I’d like to hear where the gap shows up in practice.