How CLAIRE AI is transforming enterprise data
Vishwanath Belur has spent two decades taking enterprise products from inception to market. His sharpest warning about AI is not about jobs or hallucination — it is that a model can only ever give you what it already has.
Watch the full episode on YouTube
Executive summary
Vishwanath Belur is Senior Director of Product Management at Informatica, where he leads CLAIRE — the AI and metadata engine sitting at the centre of the company's Intelligent Data Management Cloud — along with its generative AI initiatives. He came to it through embedded systems, HP, an MBA at IIM Bangalore, a vertical detour into core banking at Infosys, and back into enterprise data management.
The conversation covers agents, hallucination, RLHF and the economics of enterprise AI. Three arguments carry it, and the third is the one that reframes everything else.
First: enterprise AI lives or dies on grounding. Let a model loose and it pulls from everywhere. Inside a company that is a defect, not a feature. "When it comes to enterprises, you need to say that, hey, your scope is this. Here is your metadata scope, or data scope, or your learning scope." He notes how quickly the vocabulary moved — "2024, we are talking about RAG, and no one speaks about RAG" — but the underlying job never went away.
Second: hallucination is a detection problem, not a volume problem. His analogy is a teenager: "they will throw a lot of information at you, which you probably don't know, but they will sneak in that 5% hallucinated content." The difficulty is not that models are wrong often. It is that they are right most of the time, so the wrong 5% arrives wearing the same confidence as the rest. His diagnosis of the cause is blunt: "AI models, they don't want to say no. They want to say yes."
Third, and the line worth keeping: "It can provide you with what it has. It can never provide you with what it doesn't have. What you don't have is the charter of the human beings."
That is not a comforting slogan about human irreplaceability. It is a precise boundary. Everything already represented in the training data is now cheap. The remaining human work is whatever falls outside it — which is why he thinks the correct response to AI absorbing your daily tasks is to move up, not to defend the old ground: "think of it as it is bringing up space for you to do something more."
The story
He is an engineer first — computer science at Bangalore University, then straight out of campus into real-time operating systems and embedded devices, the VxWorks world. Small, constrained, deeply technical.
HP came next, and with it his first sight of the enterprise at full scale — back when HP still contained servers, storage, ink and printers in one organisation. But the thing that caught his attention was not the technology. It was a role:
"We used to have product managers visiting us from the US and talking about the go-to-market, the financials... And I was very fascinated in terms of how can one person be able to handle the entire gamut of activities that are needed for taking the product from the inception into the enterprise."
That fascination sent him to IIM Bangalore for strategy and marketing, and into product management proper. At HP he built and launched his first new product — a predictive analytics offering, around 2011 — and learned inbound product management: being the face of the customer inside the building.
Then Informatica, where he describes seeing the full range of the job for the first time: build the business case, take it to the CPO for approval, build it, take it to market, operationalise it.
The detour worth noting is Infosys, because of what it taught him by contrast. His career had been horizontal — enterprise data management products that serve every industry. At Infosys he ran product for a core banking solution, which is vertical: one industry, all the way down. It put him in front of CIOs at ICICI, SBI and across emerging markets, at precisely the moment UPI launched and fintech in India reorganised itself.
Now he is back at Informatica on CLAIRE and generative AI — and candid about what actually keeps him up: "the thing which keeps me up in the night is the agentic data management now."
Key decisions
Decision 1 — Ground the system before you scale it
The single most important architectural choice in enterprise AI, in his telling, is deciding what the system is allowed to know. Grounding is what converts a general model into something an enterprise can trust, and it is what makes hallucination tractable — "hallucination can be easily grounded to the enterprise metadata."
Decision 2 — Stop training models, start solving use cases
The economics inverted. In 2023, enterprises assumed they would train models on their own data. Base models got good enough that the assumption died:
"Enterprises like it more because they don't have to invest time and resources now to train these people. The total cost of ownership of delivering an AI solution has dramatically come down."
What replaced training was agents built against specific business problems. He is emphatic that this is a better use of the same budget, because training was groundwork while an agent solves an actual end-to-end use case.
Decision 3 — Put a human at every critical action
He is direct about the failure mode that worries him in multi-agent systems, and the example is unnervingly concrete:
"A goal can involve calling five agents and three tool calls. And that could result in some actions being taken on your enterprise systems. Like in your CRM, a mail can go out from you to your customer saying, hey, your order is placed — when there is no order from the customer."
The mitigation is not clever architecture. It is a human checkpoint on anything consequential. He expects that to hold "for the next five years, at least."
Decision 4 — Choose where AI goes by product maturity, not by enthusiasm
Three different answers for three kinds of product:
- New product — AI-first from day one. "It doesn't make sense to do the whole nine yards and then flip it over like a year down the line."
- Mature, stable product — start from customer use cases and infuse AI as a copilot, with the objective of growing the user base by collapsing the learning curve.
- Flagship product — as much a marketing surface as a technical one.
He also widens what "copilot" means: not only a natural-language chat box, but in-context assistance — "you're doing some workflow, AI kicks in and says, can I take this over?" — offered as a suggestion.
Mental models
The teenager
The clearest model in the episode, and the reason evaluation matters more than enthusiasm. A teenager tells you a great deal you did not know, confidently, and slips 5% invention in among it. Your task is not to distrust everything. It is to locate the 5%.
Google Maps and the switched-off mind
His genuine worry is not job displacement. It is atrophy:
"When you use Google Maps, you switch off your mind."
Applied to AI, the concern is that knowing an answer is always available removes the reason to think. "That has reduced out-of-the-box thinking skills." He is careful to label this a hypothesis rather than a finding — "we will see the real impact of it in probably five years" — and he acts on it at home, pushing his son past "ChatGPT told us" toward actual research.
RLHF, borrowed from robots
He traces reinforcement learning back to humanoids, which learn three ways: from human-coded instruction, from environmental feedback, and from their own mistakes. A humanoid that meets a road hump has to work out how to cross it.
Enterprise AI inherits the same structure, with one substitution: "in the case of humanoids, the learning from mistakes happens on the ground, literally. But here it would be through the human feedback."
The agency spectrum
The most useful framework in the conversation. Autonomy is not a switch, it is a dial running from fully human to fully autonomous — and the right starting position is near the human end:
"Agency spectrum means that you start completely from the human and completely for the agent deciding, and the answer lies somewhere in between. And probably the answer lies somewhere closer to the human."
Where you sit depends on the blast radius. A documentation agent needs no human at all — it is knowledge management. A customer support agent needs a decision about how far it may go before a person intervenes. "Err on the side of caution at the beginning."
Informatica for AI, AI for Informatica
His shorthand for two halves of one sphere: using AI inside the products customers buy, and using AI internally to solve the company's own problems. His advice on sequencing is to start inside — though "sometimes it happens in parallel."
Frameworks
Framework 1 — The eval framework, and why it is now the PM's core job
This is the most concrete, most transferable idea in the episode. Asked what an AI product manager must master, his answer is not prompting or model selection. It is evaluation.
For each business area the product automates, identify the top 50 prompts users actually ask. For each, define the expected answer — and not one answer but a graded set: "what is like a worst case, best case, ideal case, aspirational case." Then rate the system's real answers against it.
His argument for why this matters is a governance argument:
"Earlier, we used to say the quality assurance team decides whether the product goes out of the gate or not. Now the answers to these — you hold the line based on your eval framework."
He goes further, making it the measure of the person: "the criteria for measuring AI PMs is going to be how well they come up with the eval framework and how strong the framework is."
The framework solves three problems at once: it sets your internal quality gate, it encodes competitive awareness (which use cases you must cover), and it captures how customers will really use the product. That last one is the classic failure he is designing against — "QA team tests on something and the customers actually use it on a completely different scenario, and it falls flat."
Framework 2 — Three questions before building an agent
He is visibly tired of agent-building as a mandate rather than a decision — "there's an enormous pressure from the top at the enterprise saying, hey, you need to build agents." His counter-sequence:
- What are the business drivers and use cases? Take your top three to five business challenges and ask whether they can be automated. Not: we should have an agent.
- What is the end goal, and which parts stay human? Establish the guardrails before the build, not after.
- Where on the agency spectrum does this sit?
Mechanics — planning, reasoning, orchestration — come after. "That's more of how you make it work, rather than the most important thing, which is what problems to solve."
Framework 3 — Innovation versus stabilisation, set by lifecycle
Asked how he splits energy between innovation and stabilisation, he calls it "more of an art than science" — then gives a genuinely usable rule based on where the product sits relative to crossing the chasm.
Before the chasm: roughly 70% innovation, 30% solving specific customer problems. You bend backwards for the early reference customers, accelerating roadmap items to get them live — with one constraint: "You have a strategy for the product. Don't lose sight of that." Bend, but only along the path you have already chosen.
After the chasm: it flips. Roughly 50–60% stabilisation and keeping customers happy, 30–40% innovation. The PM's job shifts from getting customers to production toward marketing and organisational strategy.
Where the chasm sits is company-specific — "some people say 500 customers, some say 50 million ARR, some say when your margins are like 80%."
Framework 4 — The four risks of enterprise AI
- Hallucination — mitigated by grounding to enterprise metadata
- Bias — inherited from training data. "Garbage in is garbage out." Mitigated by feeding trustable data
- Human–AI interaction — people asking "is it going to replace me?" and becoming blockers
- Security — the one he ranks highest. Enterprises are forming AI governance councils; banks now demand written commitments that their data and metadata are not used for training
Lessons
The three hard problems in enterprise data have not changed. Connectivity — especially the IT/OT divide, where the data lives in SCADA systems and on rigs. Replication — moving data from transactional systems to analytical ones in real time, which is what makes a bank's fraud SMS possible. And operationalisation — acting on either a single event (fraud) or an aggregate window (average sensor temperature above 50°C for thirty minutes, in predictive maintenance).
AI reaching operational technology is closer than it looks. Not three years out — "one, two years down the line." And beware the relabelling: "sometimes they call even the rule-based systems as AI."
The pace is the story. Google published 101 agentic use cases in March; within two months the same page had 601-plus. His summary of the market pressure is unsentimental: "if you're not talking about AI in your earnings call, your stock is going to be punished."
What actually distinguishes agentic from generative: planning and reasoning (including multi-agent orchestration, sequential or parallel), context awareness (it knows whether you want concise answers, whether you are a data engineer or a data scientist), and autonomy in involving humans only where there is ambiguity. Underneath all three: agents pursue goals, generative systems complete tasks.
Democratisation was the real unlock. Before transformers, AI sat with data scientists "sitting at the corner of the room" throwing models over the wall to data engineers, and words like classification and regression were "out of common man's reach." What changed was not only capability but access — and inside enterprises, internal GPT-style knowledge tools have collapsed the information asymmetry that used to define who could get things done.
Actionable advice
If you are a product manager in AI: build the eval framework. It is the inbound work that matters most, and increasingly the thing you will be judged on.
If you are being told to build agents: push back to use cases first. Top three business challenges, then ask what can be automated. Refuse to start from the technology.
If you are deploying an agentic system: place it near the human end of the agency spectrum and move deliberately. Put a human checkpoint on every action that touches a customer or a system of record.
If you are worried about your own thinking: treat the Google Maps effect as real. Do the research even when the answer is already offered.
If you are choosing where to put AI in a portfolio: new products AI-first; mature products via copilots aimed at reducing the learning curve; flagship products as the marketing surface.
Final thoughts
Asked to name the biggest disruptor coming, he gives the expected answer — agents, then AGI — and then complicates it with the honest caveat: "something we think is not going to be possible in the next two years might happen in the next one month."
But his closing argument is quieter, and better. He does not think AI replaces enterprise IT teams, because he watches those teams fail to keep up with demand every day:
"They cannot even solve 20% of what their business is asking for, because of the shortage of bandwidth... So now they are not going to be replaced. With those 10 people, they are able to do 50 people's worth of work."
That is the most grounded case for AI in the enterprise available, and it does not require believing anything dramatic. The constraint was never that people were doing unnecessary work. It was that there was far more necessary work than people to do it. On that reading, the transformation is a transfer of responsibility rather than a removal of people — with humans keeping the two things a model structurally cannot do: validating what it produces, and supplying what it never had.