“Don’t Let Humans Rubber-Stamp Your AI Agents”: Marsh’s AI Chief On What Enterprise AI Gets Wrong In 2026

In an exclusive conversation, Vijay Morampudi, who leads the Global AI Centre of Excellence within Marsh’s Global Capability Centre (GCC) and drives agentic AI orchestration for the firm’s Risk & Insurance business, on why AI strategy has to start with the business — not the model — and the rollback mechanism every enterprise deploying AI agents needs to build in.

If you’ve spent any time in enterprise AI circles, there’s a decent chance you’ve come across Vijay’s name. He leads the Global AI Centre of Excellence within Marsh’s Global Capability Centre (GCC), where he has spent the better part of the last few years turning AI strategy from a slide deck into something that actually runs inside one of the world’s largest risk management and insurance broking operations. Over a 22-year career spent squarely at the intersection of technology and business — a vantage point that’s made him a candid, occasionally contrarian voice on agentic AI, India’s AI ambitions, and what enterprise AI adoption actually looks like once the hype settles — Vijay has developed strong, hard-won views on where enterprises are getting AI right, and where they’re still getting it wrong.

In an exclusive discussion with Ankitt Y, Editor, ENN, he moves past the buzzwords to talk about what’s really working inside large enterprises, what isn’t, and where he believes all of this is headed next. Edited excerpts:

ENN: To start, could you walk us through your journey?

I’ve spent most of my career at the intersection of technology and business. I built foundational software during my undergraduate years, and over the last decade or so I’ve applied that grounding to real-world business problems — starting with machine learning, moving into deep learning, and more recently into agentic AI. For the last few years, I’ve been leading AI initiatives at Marsh’s GCC, building out our Centre of Excellence.

ENN: You’ve spoken about doing an “AI strategy reality check.” If you had to name one thing enterprise leaders are still getting wrong about AI adoption in 2026 — now that most of the pilots and PoCs are behind us — what would it be?

Understand how your company actually generates value, and what role your organisation plays in that larger business value chain. Learn that as a first principle. Once you understand how your business works, you look at it through the lens of how technology — in this case, AI — can enable that business to generate more value. You start with the business need, then bring in the technology to support it, and only then do you define your AI strategy.

Within that process, there are several things you have to get right. What’s your actual competitive advantage, and how do you build it? Where do you need partnerships instead of building in-house? What foundational elements do you need — your data, your institutional knowledge? And how do you make sure the system keeps improving over time — how do you build that feedback loop?

Technology is only one part of generating value. When you’re driving a large-scale transformation, a significant amount of effort has to go into change management — redesigning processes, redefining roles, and bringing your people along. You need to be clear about the new state you want your organisation to reach, and the change required to get there, before you lock in your AI strategy. Enterprises that start with that lens upfront tend to be far more successful against the goals they set for themselves.

ENN: You lead agentic AI orchestration for Risk & Insurance at Marsh. Could you walk us through how you decide what an AI agent gets to do autonomously versus where a human still has to step in — and why the line gets drawn exactly there?

Agents are typically designed to achieve a specific goal, and there are usually multiple paths to that goal. With a model behind them, an agent can explore different options and work out how to get there. That’s fundamentally how agents operate.

But look at it from an enterprise lens. Most enterprise workflows are standardised — a sequence of pre-approved steps, decisions and actions. So when you’re thinking about automating a workflow, the first thing you need to do is break it down: what are the steps, what are the decisions, and what are the actions you actually want the agent to perform?

I think about this along three dimensions. First, autonomy — can the agent make a decision without human review? Second, agency — can the agent take an action without a human approving it first? Third, authority — how much of that decision-making and action-taking power are you actually willing to delegate to the agent?

For every workflow, you need to work out which decisions and actions you’re comfortable handing over, and to what degree. One critical requirement: everything an agent does in an enterprise needs to be deterministic and traceable. You need to know exactly what steps the agent took, and whether those steps are aligned with your business objectives, your organisational policies and applicable regulation. Once you’ve mapped that out clearly, you can start delegating.

When we launch an agent, every decision it makes is reviewed, and every action it takes is approved by a human, to begin with. Once we’re confident the agent is consistently making the right calls, we gradually increase its authority so it can act with less oversight. But the environment an agent operates in changes over time — and if the environment shifts and the outputs start to drift, you need a way to pull authority back. Essentially, you need a rollback mechanism, so a human can step back in, review every decision again, and recalibrate the agent before you hand authority back. That’s one of the more important things to get right before you put agents into production at any real scale.

ENN: “Human in the loop” is often treated as the design principle that makes this safe. In a regulated, high-stakes field like risk and compliance, where does that balance between autonomy and oversight actually become hardest to get right?

“Human in the loop” is often talked about today as the default mechanism for ensuring compliance in regulated industries, and it’s a valid starting point — but there are side effects worth thinking through. How do you ensure humans are meaningfully reviewing thousands, even millions, of decisions and actions an agent is producing? It’s practically impossible for a person to review everything at that volume. What tends to happen instead is what I’d call rubber-stamping — approving without actually reviewing.

So my strongest recommendation is: don’t assume humans are going to meaningfully review everything, especially in a fast-moving environment where agents are generating millions of decisions a day. You have to deliberately design where that human control needs to sit, and just as importantly, what information you actually show the reviewer. Don’t dump everything on them and say “here are the hundred things I did, go approve it.” Instead, brief them: here’s what I did, here’s what’s clearly right, here’s what’s uncertain — and this is what needs your judgment. Give the human curated, high-signal information so they can focus on what actually needs their attention.

You also have to plan for what happens when your agents are stuck waiting on human input to move forward. That’s a real bottleneck, because you can scale agent infrastructure on demand, but you cannot scale people the same way. So you need to identify, workflow by workflow, where human review is genuinely required, and whether too many decisions are piling up waiting on the same human bandwidth. One thing that’s worked well for us: when a batch of agent outputs needs review, group the similar ones together and present them to the human as a set, so they can review and approve a category in one pass instead of one item at a time.

There’s a good real-world example of this going wrong: during a citywide power blackout in the US, a fleet of autonomous vehicles was designed to stop and wait for human approval whenever it encountered a traffic signal that wasn’t working. That’s a sensible rule in isolation — a human driver, seeing a dead signal, would naturally navigate around it using judgment the system didn’t have. But because the entire city lost power at once, every one of those vehicles hit the same failure simultaneously and queued up waiting for real-time human sign-off — and there simply weren’t enough people available to clear that queue in time. If the system had been designed to recognise “hundreds of vehicles are hitting the identical problem for the identical reason,” a human could have approved that situation once, and every vehicle facing it could have proceeded together.

That’s the deeper challenge: these failure scenarios get harder to navigate as your system becomes more embedded in a larger ecosystem. Even if your own system is well automated, if the environment around it isn’t, you can’t reliably handle the complex, edge-case scenarios. In that example, the cars weren’t integrated with the city’s traffic-infrastructure data — if they’d known the signals were down because of a citywide blackout, they could have made a different, better decision. That level of ecosystem integration fundamentally changes how these systems behave in the real world.

ENN: You’ve been vocal about India’s AI mission and the role of small language models. Do you think India’s AI future is better served by building sovereign, India-specific models, or by getting really good at applying global models to Indian problems? Where do you personally place your bet?

India is an extraordinarily diverse ecosystem — different languages, different backgrounds — and any solution we build has to work at billion-scale. We already have proof that this is possible: successful public digital infrastructure initiatives like UPI have given us the confidence to build systems that serve a billion-plus people’s needs.

On the technology side, most of today’s large models are trained on data available on the public internet, and the overwhelming majority of that is in English. India has a huge number of languages that don’t have anywhere near that volume of public data, so global models often don’t perform as well in those scenarios simply because the training data doesn’t exist at scale. What the government and India’s startup ecosystem are doing here is genuinely commendable — there are several programmes specifically building datasets for Indian languages, and I’ve seen a number of companies doing serious work on Indian-voice and Indian-language datasets. Building the right datasets is the first, and most important, step toward sovereign AI for a country like ours — alongside the compute and GPU infrastructure to actually train on them.

We’re already seeing smaller models, purpose-built for specific industries like healthcare, education and agriculture, producing strong results. It’s often less about model size and more about whether you have the right data. Large general-purpose models are excellent at answering broad, generic questions because they’re trained on a huge cross-section of how the world behaves — that’s genuinely valuable. But they have a real limitation: fundamentally, they’re doing next-token prediction, not causal reasoning. They can’t reliably explain why a particular cause leads to a particular effect, because that reasoning capability isn’t inherently built into how they’re trained.

For a specific industry problem, if you build the right dataset and combine it with explicit causal-reasoning techniques, a smaller, focused model — sometimes I call this “compound AI,” a combination of AI techniques rather than one large model doing everything — will often outperform a general-purpose model. Causal reasoning is the missing piece: today’s models predict what the next token is likely to be, but they don’t reason through how one action will actually affect different downstream scenarios. Combine the two, and you get materially better outcomes, particularly in areas like healthcare. For India specifically, the dataset layer is where we need to keep investing — that’s what will determine how fast we can move.

ENN: Coding agents and AI-assisted development are changing how technical teams work. Has developer experience inside your own AI Centre of Excellence changed over the past year, and what does your team do differently now compared to 18 months ago?

Enormously, over the last couple of years. I don’t think we’d be moving at anywhere near our current pace without these code-generation tools at this point — they’ve become core to how the team works.

That said, I still firmly believe humans are the key ingredient behind genuinely great solutions. Technology on its own doesn’t necessarily produce the best, most original innovation — it’s very good at what it already knows, but humans can think beyond that and imagine what’s possible next. So understanding the foundational concepts deeply still matters enormously, even as you use these tools to move faster. Equally important: understanding where these tools currently fail. When you’re building a product, you can’t assume it will be correct 100% of the time — you need to anticipate the failure modes and design the product to handle them.

Our productivity has genuinely gone up. I’ve always believed developer experience deserves the same attention we typically give customer experience, and these tools have made a real difference there. But here’s the more interesting question I’ve been sitting with: say a team can now finish in 70% of the time what used to take 100%. What do you do with that extra 30%? One option is to push the team to write more code, or clear a long-standing backlog of problems you hadn’t had the bandwidth to tackle before — that’s a legitimate, if fairly short-term, win.

The bigger opportunity, in my view, is to take your top performers’ newly freed-up 30% and redirect it toward genuine innovation — harder, more complex problems that are more valuable to the business, that you haven’t had the capacity to attempt before. You don’t need to go and seek separate business approval for this, because you’ve created that bandwidth from within your own team. Try two or three such initiatives over a quarter with your strongest people; even if only one succeeds, it can be a real differentiator. It also tends to be far more motivating for high performers than simply asking them to produce more of the same kind of work. The real question every leader should be asking is: how do you take the productivity gains from these tools and convert them into a different kind of innovation — one that makes people more engaged and gives the business a genuine competitive edge?

ENN: If we did this interview again two years from now, what AI capability do you think will have completely normalised, that most people today still treat as experimental?

The underlying technology is only going to keep improving, and I expect enterprises will keep finding new problems to apply it to rather than running out of ideas. To be clear, I wouldn’t recommend using AI productivity gains as a reason to downsize teams — the opportunity is to use that freed-up capacity to go after problems you couldn’t tackle before. Organisations that start asking “what can I now do that wasn’t possible earlier?” — and actually run three to five such bets — will likely find that one or two of them turn out to be genuinely transformative.

We’re already seeing this play out in some sectors. Private space-tech is advancing quickly. Drug discovery is a good example — it typically takes about a decade end-to-end, and I expect we’ll see at least some AI-discovered drugs enter clinical trials in the next year or so. Agriculture is another space where I expect meaningful movement. New categories of problems are opening up across the board.

My broader point: keep your fundamentals strong, because this is genuinely an opportunity for people and businesses to build deep expertise across multiple areas faster than ever before. Basic, surface-level knowledge is going to stop being a differentiator — it’ll become table stakes for everyone, at both the individual and business level. What will matter is real depth, and these tools are going to help us get there much faster if we use them well.

ENN: Twenty-two years into a career at the intersection of technology and business — if you were mentoring someone starting out today who wants to end up doing what you do, what’s the one skill you’d want them to build first, and what would you tell them to stop worrying about?

Throughout my career, my thinking has always started with understanding the problem properly — most people don’t spend enough time there. There’s a concept called design thinking: look at the problem from the user’s perspective first, understand whether it’s a real problem, and then work out the simplest way to solve it. Once you genuinely understand a problem, you usually find the simplest path to solving it. That’s the first skill I’d point to.

Second, since technology now handles a growing share of the execution, analytical thinking matters more than ever — the ability to understand what’s actually happening, where things could go wrong, and how to read results and data well enough to connect the dots and spot patterns before they become obvious. The people who can see those patterns early are the ones who end up shaping what happens next.

What I’d tell them to stop worrying about is how much raw or basic knowledge they have relative to their peers. That level of knowledge used to be enough to succeed; going forward, it’s just table stakes — this generation has grown up alongside these tools and already knows a great deal. What actually sets people apart is strong fundamentals combined with the ability to envision the future and act on it. Technology can help make that vision real — but you still have to bring the vision.

Edited for length and clarity. A video recording of this conversation will be published separately, and this interview will also appear in print this month.

India’s GCC Boom Is Making Landlords Rich, Not IT Firms