Start with the outcome: Oracle India’s Vivek Gupta on taking AI from pilot to production

Ask Vivek Gupta, Senior Director and Head, Technology Cloud, Oracle India on what separates the Indian enterprises making real progress with AI from those still stuck in pilots, and his answer has little to do with models or GPUs. It begins with a simpler question: what outcome are we trying to achieve? “My first and foremost suggestion to every customer is to look at outcomes before they start driving their AI journey,” he says. “Then comes technology.”

It is a deceptively plain piece of advice, and it lands at a moment when India’s AI story is changing. The demo cycle is ending, and the harder work of production has begun.

The demo cycle is over
For the past two to three years, artificial intelligence has been a fixture of the Indian boardroom agenda. Pilots have multiplied, proofs of concept have been showcased, and almost every large enterprise can point to a promising model somewhere in the business.

The more revealing question now is a harder one: who can turn AI into a reliable, governed system that improves a customer journey, a supply chain, a fraud workflow or a public service every single day?

The numbers suggest that gap is wide. A NASSCOM/EY survey found that roughly 60% of Indian CXOs expected AI to disrupt their businesses within three years, yet only about 25% had deployed AI solutions. Intent is clear. Execution is the bottleneck.

The timing makes the question urgent. India’s public AI infrastructure is scaling rapidly, and the country’s data-centre footprint is expanding fast, creating the physical foundation to run AI workloads closer to Indian enterprises and their users. Add India’s sheer scale, its digital public infrastructure, a deeply multilingual user base, heavily regulated sectors such as banking and insurance, and one of the world’s largest concentrations of global capability centres, and the country becomes an unusually demanding environment for AI. It is also, arguably, an ideal global proving ground for production-grade enterprise AI.

Start with the outcome, then choose the technology
Gupta’s observation from those roundtables is consistent: AI becomes mainstream where a customer can define a very clear outcome first. Technology comes second.

That shift, he argues, is what separates production systems from isolated pilots. Production AI must work with real enterprise data, and it must operate under clear controls. “Control is very, very important,” Gupta says. He means control over security, over cost, and over the value and outcome the system delivers, whether that is process automation, bottom-line savings or top-line growth.

It also reframes what a technology vendor is selling. “The question is becoming less about access to a model, more about whether organisations can deploy AI responsibly and at scale,” Gupta explains. Models are plentiful, and choosing among them is genuinely difficult. “It’s not a GPU or model problem,” he adds. “We are trying to solve real-world business problems with AI.”

Model flexibility, without losing the platform
One of the most consequential decisions facing CIOs is how much model choice to preserve without fragmenting the foundations underneath: identity, data, observability and cost control.

Gupta’s position is pragmatic. Different use cases call for different models, and Oracle’s stance is to support AI in whatever form customers want. The discipline lies in keeping the surrounding controls consistent. Whichever model an enterprise selects, the identity layer, the network boundary, the audit trail and the guardrails should behave the same way.

This is where he sees the durable priority for enterprises as the landscape keeps shifting: “Make AI useful, manageable, and connected to the systems where decisions are made.” In other words, treat the model as a replaceable component and the enterprise platform as the lasting investment.

Take AI to the data, not the data to AI
A recurring theme in Oracle’s pitch is data gravity. Rather than copying business data out to suit a model’s needs, Gupta says organisations should run AI where the data and the business process already operate.

For customers on Oracle Database 26ai, that means AI embedded within the database itself, so teams do not have to move data to satisfy a model. “Rather than taking the data to AI,” he says, the aim is to let the AI work in place, with established access policies still applying. Oracle AI Database can support AI agents’ natural-language access to structured business information, with customers controlling which users and which agents can see which data.

The broader trend he sees is a move from standalone experiments toward applications connected to live enterprise data workflows and business context. Governance is becoming central, and data architecture is becoming more open and distributed, connecting data across clouds, on-premises environments and the edge instead of demanding a single location.

Choosing where AI runs
For Indian enterprises, the question of where AI should run is rarely academic. Latency requirements, data location, sector regulation and existing investments all shape the answer, and the right deployment model will differ between, say, a private bank, a manufacturer and a government agency.
Oracle’s distributed cloud approach is built around that reality. Customers can run AI services in the public cloud, across multicloud partnerships, in dedicated or customer-owned data centres using

Oracle’s hybrid stack, or at the edge where data location and latency matter most. “The practical aim,” Gupta says, “is to let organisations use AI where the data and business process already operate rather than forcing them into a model.”

The takeaway for CIOs is to treat deployment as a per-workload decision driven by data sensitivity, regulatory exposure and latency, not a single enterprise-wide choice.

Measure AI by the workflow, not the token
As inference becomes a line item on the budget, many leaders are fixating on cost per token. Gupta pushes back firmly.

“The economics of AI should be measured per completed workflow, not by token cost alone,” he says. Token or inference pricing is an important input, but it does not reveal whether an AI process reliably delivers a useful business outcome.

A workflow-level view also forces honesty about everything surrounding the model. Beyond inference, organisations should account for data retrieval and preparation, agent steps, storage, integration, monitoring and any required human review. On the pricing side, OCI offers on-demand, pay-as-you-go inference based on the size of the request, as well as dedicated AI clusters with committed hourly capacity for steadier workloads.

His suggested yardstick is deliberately simple: “A practical measure is total monthly AI spend divided by successfully completed governed workflow outcomes.” A support organisation that automates a ticket-resolution flow, for example, should be able to say what each resolved case now costs, end to end.

Agents with guardrails, not agents with keys to the kingdom
As AI moves from answering questions to taking actions, the risks change. A string of publicly disclosed incidents of agents behaving unexpectedly has made governance a boardroom concern in its own right.
Gupta does not argue for slowing down. “This is a change that is inevitable,” he says. His argument is for precision: “Agents should receive only the data and actions needed for a defined task and no more.”

He outlines guardrails at three levels:

The first is access. Agents are connected to approved knowledge bases, data sources and structured data tools, and permissions are assigned through Oracle Identity and Access Management. Those permissions can be separated for agents, knowledge bases, data sources, sessions and endpoints, which allows least-privilege access instead of broad shared permissions.

The second is the network. Private endpoints keep model and agent traffic inside the customer’s own virtual cloud network, including connected on-premises environments where applicable.
The third is runtime behaviour. Oracle Generative AI Guardrails can detect prompt injection, moderate inappropriate content and catch personally identifiable information in both inputs and outputs.

Visibility matters as much as restriction. Customers using Oracle AI Data Platform can track agent identity, permissions, versions, integrations and logs. And high-impact actions, such as updating records or initiating a transaction, should be narrowly scoped and built with clear approval and review paths.

“This is how agents will become useful without becoming an uncontrolled access point for enterprise data,” Gupta says.

From prototype to production service
Taken together, Gupta’s advice amounts to an operating model for moving an agent from prototype to a controlled, observable and scalable service:

It begins by defining the outcome and its owner before any model is selected or capacity provisioned. The agent’s access is then scoped to the specific data and actions its task requires, enforced through identity policy rather than convention, and kept close to governed data so it works from live enterprise context instead of disconnected copies. The network path is isolated with private endpoints, and runtime guardrails screen inputs and outputs. High-impact actions get human approval, with agent identity, versions and activity logged for audit. Finally, cost is tracked per completed, governed workflow, with review effort and integration folded into the number.

None of this is glamorous, and that is the point. The gap between experimentation and measurable impact is rarely closed by a better model. It is closed by operational discipline.

Oracle’s bet: AI as part of the stack, not a layer on top
Oracle’s particular vantage point spans applications, databases and infrastructure, from core ERP and EPM to HCM, industry applications and core banking, all running on OCI. Gupta describes the vision as using AI across all three layers by connecting models to governed enterprise data, “rather than treating AI as a separate layer.”

In practice, that means a stack of capabilities: OCI Generative AI and OCI Enterprise AI services for model access, retrieval tools and hosted agents; Oracle AI Database for natural-language access to business data under existing policies; Oracle AI Data Platform for cataloguing, data preparation, analytics and role-based access control; and pre-built agents in business applications such as HCM.

Across all of it, OCI applies identity and access management, private networking, auditability and runtime guardrails. Customers can also build AI into their own applications through APIs or deploy managed agentic applications on OCI.

“The result,” as Gupta frames it, “is a consistent approach”: AI introduced into database-driven processes and applications while control is maintained over data access, network exposure and agent behaviour.

The bottom line for India’s CIOs
India’s AI moment will not be judged by the number of pilots launched. It will be judged by how many of them quietly become part of how the country’s banks, retailers, manufacturers and public services run every day, with controls that regulators, customers and boards can trust.

For CIOs, Gupta’s message distils into three questions worth asking before the next investment: What outcome are we buying? Where does the data live, and can the AI work there? And can we show, workflow by workflow, that it is governed and worth what it costs?

The organisations that can answer all three will be the ones that move India from the demo cycle to durable operational advantage.