Most enterprise AI projects don’t fail loudly. There is no dramatic system crash or failed launch. They just quietly stop delivering: a pilot that never became a process, a governance layer added too late, an organization that kept asking how to move faster instead of asking what actually needed to change.
Nirmal Ganesh has watched this pattern repeat across industries for years. A software engineer by training, he spent nearly two decades in document technology, including leading the roadmap for Adobe Experience Manager Forms and helping triple the size of that business. At Box, where he currently leads the product strategy for Box Automate, his conviction is straightforward: AI-native processes are not faster versions of old ones. They are structurally different.
This conversation draws on Nirmal’s personal perspective and career experience across Cognizant, Adobe, and Box. He explains the two failure patterns he sees in nearly every organization, why the “supervised autonomy trap” is costing companies the ROI they were promised, and what it actually takes to build workflows that are not just faster, but fundamentally better.
The Wrong Question
1. Most enterprise leaders seem to be asking the wrong question about AI. What is that question, and why does it lead them astray?
The question I hear constantly is: how do we use AI to make our existing processes faster? And honestly, I understand why. It sounds practical. It sounds like progress. But it assumes the process you already have is the process you actually need — that AI’s job is just to accelerate it, even if the underlying logic is broken.
The question that changes everything is: what processes should we be running at all? That’s a harder question and most organizations skip it entirely. They bolt AI onto existing workflows, see maybe 10 to 15 percent improvement, and then scratch their heads wondering where the ROI went. I’ve watched a ten-step human process become four steps — not because anyone worked faster, but because entire categories of work stopped existing. That only happens when you redesign from scratch. Speeding things up doesn’t get you.
2. McKinsey data suggests 73% of AI deployments aren’t delivering expected ROI. From your experience on the ground, does that number hold up?
Honestly? It’s sad, and it tracks exactly with what I hear in customer conversations. The failures aren’t about the technology being immature, or the models not being ready. Those aren’t the problems. What I keep seeing is something quieter: a pilot that generated excitement and then just… stopped. A governance layer that got added six months too late. An organization that technically deployed AI and then watched it sit there.
What the data shows — and this part doesn’t get nearly enough attention — is that 77% of AI failures are organizational, not technical. The models are extraordinary. The architecture for enterprise AI deployment exists. What isn’t ready is the organization built around it. Nobody owns it. The workflows haven’t been rethought. And most companies have no clear definition of what success even means. That’s the gap nobody wants to discuss, because fixing it is a lot harder than buying a new tool.
3. The models are extraordinary and the architecture exists. If technology isn’t the problem, what is?
It’s the organizational work. What isn’t ready is how the company operates around the technology. No clear owner. Workflows that nobody has stopped to rethink. Governance that gets bolted on months after deployment. Teams still being measured on activity counts instead of actual outcomes. None of that comes in a software package, and none of it is easy to fix.
AI without an operational home becomes a permanent pilot. It sits in a proof of concept, generates a good demo, and then quietly goes nowhere. AI dropped onto a process that nobody has questioned just becomes a faster version of work that probably shouldn’t exist in that form anyway. The technology is the easy part. The hard part is the organization deciding to change how it actually runs.
Why AI Keeps Failing
4. One pattern that keeps emerging is AI with no “operational home,” technically deployed but never truly adopted. What does that look like inside a real company, and how can leaders recognize it early?
It looks like an impressive demo that never made it past the pilot stage. The team ran a proof of concept, results looked promising, there was genuine excitement — and then nothing. Six months later people are still doing the work manually. The tool exists, technically. Nobody’s using it because it was never actually wired into how work gets done.
The early warning sign is when the AI lives outside the workflow. If someone has to open a separate tool, log in somewhere else, copy results back into their main system — that’s not adoption. That’s a science project with extra steps. Real adoption looks different: the AI is just part of doing the work, not a detour from it. The other signal is when you ask who owns this deployment and nobody has a clear answer. If there’s no named owner, there’s no operational home. And without an operational home, it doesn’t matter how good the technology is.
5. What is the actual difference between automating a task and redesigning a workflow for an AI-first world, and why does that distinction matter for ROI?
Automating a task means taking one step in a process and making it faster. You add OCR here, a chatbot there. The rest of the workflow stays exactly as it was. And you get maybe 15% improvement on that step, because the friction between steps is completely untouched.
Redesigning a workflow is a different exercise entirely. You start from scratch and ask: if agents, systems, and humans are all participants in this process, what’s actually the best way to structure it? And when you do that honestly, you don’t just speed things up. You eliminate entire categories of work. The real bottleneck in most enterprise workflows was never any single slow step. It’s everything in between: the handoffs, the context that gets rebuilt from scratch at every stage, the manual decisions about where something goes next. When you redesign around agents, those costs collapse. A ten-step process becomes four steps. That’s not an optimization. That’s where the ROI actually lives.
6. The “supervised autonomy trap”: what is it, and why do organizations fall into it while believing they are being responsible with AI?
The supervised autonomy trap is what happens when you add so many human approval gates to your AI deployment that you’ve essentially rebuilt the manual process with extra steps. And the reason organizations fall into it is that it feels like the right thing to do. You’re being careful. You’re keeping humans in the loop. It seems responsible.
The problem is that procedural guardrails scale linearly with volume. The more you automate, the more approvals pile up. At scale you haven’t reduced work, you’ve added a layer on top of it. Industry research consistently puts the share of agentic initiatives that never reach enterprise scale somewhere between 70 and 80 percent. That number tracks with what I see in practice. The shift that actually works is moving from procedural guardrails to structural ones: governance built into the architecture itself rather than bolted onto the process as a series of review gates. Permission-aware agents. Confidence scoring. Audit trails by design. When governance is structural, it doesn’t grow with volume. It just works.
What Needs to Change
7. What is the difference between procedural guardrails and structural guardrails, and why does it matter particularly in regulated industries?
Procedural guardrails are human review gates. Every time the AI does something, a person checks it. That sounds safe. In practice it doesn’t scale, and in regulated industries it creates a specific kind of risk: the compliance depends entirely on people doing the reviewing correctly, every single time, under pressure, at volume. That’s not a governance model. That’s an assumption.
Structural guardrails are different. They’re built into the architecture itself. Permission-aware agents. Confidence scoring. Audit trails that are automatic and unified. Compliance boundaries enforced by design, not by a queue of people hoping nothing slips through. The difference in practice: imagine a financial services firm with 15,000 active vendor contracts and 22-day review cycles. As they redesign with agentic workflows, the audit trail becomes so complete that external auditors find it more thorough than the manual process. Not faster. More thorough. That’s what structural guardrails look like. The governance isn’t a workflow property. It’s a design property.
8. The primary bottleneck in most enterprise workflows isn’t the speed of any individual step. It’s the accumulated cost of handoffs, context reconstruction, and manual routing decisions. Why does that change where AI should actually be applied?
It changes everything about where you aim. Point AI at a slow step and you get a faster step. That’s it. The real cost in most enterprise workflows isn’t any single slow step — it’s everything in between. The handoffs. The context that gets rebuilt from scratch at every stage. The manual decisions about where something goes next. Fix those and you’ve actually changed the economics of the work.
That’s why the framing matters. Instead of asking “which step is slowest,” ask “where does information get lost, misrouted, or reassembled by hand.” Apply AI there. When you do, entire categories of work stop existing. I worked with a claims specialist who spent 80% of her time assembling documents. After the workflow was redesigned, she will spent 80% of her time actually evaluating claims. That’s not a 15% improvement on a task. That’s a fundamentally different job.
9. The “If This, Then That” model has run enterprise automation for decades. Why has it lasted so long, and what finally makes the case for moving past it?
It lasted because it worked. For a certain class of problems, deterministic rules-based automation is still the right tool — reliable, auditable, easy to reason about. If you know exactly what inputs you’ll get and exactly what outputs you need, rules handle it well. That hasn’t changed.
What has changed is our understanding of where the high-value work actually sits. Reading a contract and deciding whether it needs legal review. Pulling the right fields from an invoice that arrived in a format nobody anticipated. Routing an exception that doesn’t fit any rule you’ve ever written down. That’s judgment work. Rules were never going to handle it, no matter how sophisticated the ruleset got. The argument for moving past “if this, then that” isn’t that rules are wrong. It’s that the steps that matter most in your workflow — the ones where getting it right actually changes outcomes — were never going to be solved by rules in the first place. That’s where agents come in.
Getting Governance Right
10. How should companies decide which AI decisions genuinely need human review and which should be governed through architecture from the start, rather than review gates added at the end?
The framework comes down to two questions: what’s the cost of a wrong decision, and how recoverable is it? High-volume, low-risk, recoverable decisions should route autonomously. The agent will get some wrong. A human can correct them. The volume makes the ROI obvious. High-stakes, low-volume, hard-to-recover decisions need human judgment — but that judgment should be designed into the architecture, not added as a gate at the end when someone realizes they forgot to put a person in the loop.
The mistake I see most often is companies defaulting to human review for everything, then trying to figure out later what can be automated. That’s backwards. Start with the architecture. Think through where confidence thresholds matter, where dollar values create risk, where regulatory sensitivity kicks in. Build the human-in-the-loop for situations that genuinely need it. And one more thing people miss: autonomy is not an on-off switch. You can configure it differently for each step in a workflow, and you can adjust it as context changes. The workflow stays the same. How much you trust the agent at any given point doesn’t have to.
11. Many companies still treat AI governance as a compliance layer bolted on at the end of a process. Why does that approach undermine the governance itself?
Because governance bolted on at the end depends entirely on people doing the right thing, every time, under pressure, at volume. That’s not a system. That’s hope.
When governance is a design property it works differently. Agents inherit the existing permission model — they can only access what the user they’re acting on behalf of can access. Audit trails are automatic. Compliance boundaries are enforced by the architecture, not by someone remembering to check a box. The system won’t let the box go unchecked because the box isn’t optional. There’s also a scaling problem with end-of-process governance that doesn’t get talked about enough. It grows linearly with volume. The more you automate, the more compliance overhead you generate, which at a certain point starts eating the efficiency gains you were chasing in the first place. Structural governance doesn’t do that. It scales with the architecture, not with the workload.
12. What kinds of enterprise workflows are still better served by deterministic, rules-based automation rather than AI agents?
Any workflow where the inputs are fully predictable and the outputs are fully defined. Routing a form to the right department based on a field value. Triggering a notification when a deadline passes. Generating a standard document from a template with known variables. Rules handle all of that reliably, cheaply, and with complete auditability. There’s no reason to introduce an agent where a rule does the job perfectly well.
The philosophy I work from is a sliding scale. Not “replace rules with AI” but use each where it actually belongs. Some steps need to be deterministic and should stay that way. Others involve reading context, making a judgment call, handling something that doesn’t fit any predefined pattern — and that’s where agents earn their place. The real design challenge is getting those two things to live in the same workflow without fighting each other. That’s harder than picking one approach and applying it everywhere. But the workflows that get it right tend to be the ones that actually hold up at scale.
13. Three mistakes tend to come up repeatedly when organizations redesign roles around AI: measuring the wrong things, mishandling the human dimension of change, and trying to do everything at once. Which one derails the most transformations in practice?
Ignoring the fear. Most people expect a technical answer here, but the failure mode I see most often has nothing to do with technology.
Fear of job displacement is the number one barrier to AI adoption. And most organizations handle it the same way: they don’t. They announce the technology, run the deployment, and tell people what their new role looks like after the fact. By that point the resistance is already baked in. The organizations that get this right do it in the opposite order. They redefine the roles before the agents go live. They show people exactly what the agent will handle, what they’ll do instead, and why that version of the job is actually better. The claims specialist spending 80% of her time assembling documents wanted to evaluate claims. The attorney hunting through contracts for relevant clauses wanted to assess risk. When you redesign the work around what people actually came to do, they stop resisting and start advocating. That’s the line between a technology rollout and a real operating model transformation.
From Pilots to Scale
14. When it comes to measuring AI ROI, what metrics actually matter beyond activity counts like tasks completed, pages submitted, or buttons clicked?
The ratio of time your people spend on judgment versus assembly. That’s what actually tells you whether AI is changing the work or just sitting on top of it.
71% of organizations say their AI initiatives align with business goals. Only 31% have well-established metrics tied to KPIs like revenue growth, cost reduction, or customer satisfaction. Everyone else is tracking adoption: logins, workflow counts, features used. That’s activity, not transformation. If your AI program gets measured by how many people clicked a button, you will optimize for button-clicking, and nothing will actually change.
Think about a health system processing insurance claims. If they redesigned that workflow with agentic automation and measured what actually changed, it might look something like this: intake-to-first-review time dropping from 12 days to 18 hours, per-claim processing time falling from 25-40 minutes to under 4 minutes, and the share of claims requiring full manual review going from 100% to 23%. Those are business outcomes. That’s what ROI actually looks like.
15. At what point should an enterprise stop trying to build AI infrastructure internally and just integrate what already exists, and how do you think about that decision?
Buy the content foundation, build the business logic. That’s the rule of thumb I’d offer.
The content foundation — secure storage, permissions-aware AI, extraction, metadata, workflow orchestration — is not where you want your engineering cycles going. It’s extraordinarily hard to get right at enterprise scale, especially with the security guarantees compliance teams actually require. The organizations that try to assemble RAG pipelines, vector databases, chunking logic, and permissions-aware retrieval from scratch consistently underestimate what they’re taking on. It looks tractable until it isn’t.
Where you should be building is the domain-specific logic: prompts tuned to your document types, routing rules that reflect your actual business process, integrations with your specific systems of record. That’s where the competitive advantage lives. Nobody else has your process knowledge. That’s worth protecting and investing in. The other signal that you’ve already crossed the line: if your team is spending more time maintaining what they built than improving it, the build decision stopped making sense a while ago.
16. “Trust engineering”: what is it, and what does building that competency actually look like inside a company?
Trust engineering is the competency of designing governance frameworks for autonomous agents: permission boundaries, audit mechanisms, escalation protocols. It’s the organizational capability that turns a pilot into a platform.
In practice it looks like a team that owns one question: how much should we trust this agent, in this context, at this confidence level? They’re not writing code. They’re designing policy. They define the conditions under which an agent acts autonomously versus escalates to a human. They monitor agent performance and tune confidence thresholds over time. They build the organizational confidence to gradually expand what agents are allowed to do. This role doesn’t exist yet in most companies, but the market is already pricing in the gap. PwC’s research shows AI-fluent professionals now command a 56% wage premium over colleagues doing the same job without those skills. That number more than doubled in a single year. The skills gap is real and it’s widening fast.
17. After years at Adobe working on AEM Forms and the Document Cloud Platform, including helping expand the size of that business, how did that experience shape the way you think about where AI belongs inside enterprise workflows?
It gave me a deep respect for how complex document-centric work actually is. At Adobe I spent years watching enterprises wrestle with the same fundamental problem: the most important information in the business was locked inside documents, and getting it out required an enormous amount of human effort. Forms, contracts, invoices, applications — the content existed, but it wasn’t actionable. Someone always had to do something with it first.
What I kept coming back to was that the bottleneck was never the document itself. It was the gap between the document and the decision. Someone had to read it, pull out the relevant information, make a judgment call, and route it somewhere. That handoff — from content to action — is where work slowed down, errors crept in, and costs accumulated. That’s also the step AI can now handle well. When I came to Box and started building Automate, that experience shaped everything. The question I kept asking was: where does the document live, and what actually needs to happen to it? The answer to that question is where agentic automation starts to make sense.
18. What are the biggest mistakes companies make when moving from AI pilots to production-scale AI workflows?
Three things come up consistently.
First, trying to do everything at once. Pick two or three high-impact, well-scoped workflows. Prove real results. Let success create the pull for the next wave. The organizations that try to automate everything simultaneously end up with shallow deployments everywhere and deep impact nowhere.
Second, treating change as a one-time event. AI is redesigning work faster than most organizations can redesign around it. The ones winning here have built a standing transformation capability — a persistent team that monitors agent performance, identifies new opportunities, and manages the ongoing relationship between humans and agents. Not a project with a end date. A function that runs continuously.
Third, measuring the wrong things. If you’re looking at logins and workflow counts six months in, you’ve already lost the thread. Measure cycle time. Measure error rates. Measure the hours your people spend on judgment versus assembly. Those numbers tell you whether the work is actually changing. The others just tell you the tool got deployed.
Looking Ahead
19. What do enterprise AI workflows look like in five years, and what has to change between now and then for organizations to actually get there?
In five years, the organizations that got this right won’t be asking whether a human or an AI should handle something. That question will feel outdated. The real question will be: what’s the right participant for this step, given the context and the stakes? Agents, systems, and humans will be genuine collaborators in the same workflow. The audit trail will be complete. The governance will be structural. And the people in those organizations will largely be doing the work they actually wanted to do when they took the job.
What has to change between now and then is harder to package into a roadmap. Organizations need to stop treating AI as a technology rollout and start treating it as an operating model transformation. The two things compound differently. Every workflow you redesign generates data that makes agents better. Every successful deployment builds the organizational trust that makes the next one possible. Every role you redefine frees up capacity for the next transformation. The technology constraint is gone. The question now is whether the organization is ready to meet it.
20. Speaking in your own capacity, drawing on a career that spans Cognizant, Adobe, and Box, if you stepped back from all of it and looked at the AI transformation space as an outside observer, what is the industry still getting fundamentally wrong?
The industry is still selling AI as a speed story. Do the same things, faster. And that framing is quietly costing companies the ROI they were promised.
AI-native processes are not faster versions of old ones. They are structurally different. When you redesign a workflow for agents, you don’t just accelerate existing steps — you eliminate entire categories of work. The handoffs collapse. The context reconstruction disappears. The manual routing decisions stop being manual. What’s left is the judgment work, the work that actually requires human intelligence. The organizations that understand this are building something genuinely new. The ones that don’t are spending a lot of money to go 15% faster and wondering why the transformation never arrived.
After twenty years watching this pattern repeat across Cognizant, Adobe, and now Box, I’m convinced the gap isn’t technical. It’s conceptual. The technology has been ready for a while. What’s still catching up is how organizations think about what they’re actually trying to build. Closing that gap is the most important work happening in enterprise technology right now.
