When AI Leaves the Lab: Gowrav Shekar on AI, Judgment and Building for Consequence

AI has become easier to demonstrate than to institutionalize.

A prototype can impress a room quickly. A pilot can show promise. A model can produce answers that look confident enough to move a discussion forward. For many organizations, early visibility creates a feeling that progress has already begun.

The real test begins after that feeling fades.

Once a system enters a live business environment, it has to deal with incomplete data, users who may take time to trust it, processes designed long before AI entered the conversation, and decisions that carry real consequences. A wrong answer may affect cost, time, compliance, customer experience or institutional trust.

The harder question is whether an organization can carry the responsibility of using AI well. The work now is increasingly about deciding which decisions AI should influence, how much weight the system should carry, and where human judgment must remain visible.

Gowrav Shekar, Head of Technology and AI Practices at Adani AI Labs, works in that space.

His work spans application engineering, artificial intelligence and operations research. In such environments, AI has to move beyond a promising demo and become part of how decisions are actually made. Gowrav begins from a simple but demanding question:

“Start with what is the decision which you want to move out from the current way of operating to the AI way of operating.”

A lot of AI work becomes clearer when seen through that sentence. The starting point is the decision to be improved. Once that decision is named clearly, the workflow, ownership, risk and success measure become easier to examine.

Production as Proof

Gowrav’s approach to AI was shaped long before AI became the center of the technology conversation.

At Volvo, he worked on embedded software for truck ECUs. Release cycles were long. A feature could take nine to twelve months before reaching production. Once software entered the field, fixing a mistake became difficult and expensive. An error could lead to recalls, operational disruption, financial cost and loss of trust.

Engineering in such environments leaves an imprint. You begin to think beyond normal conditions: where a system can bend, where it can break, how early failure can be detected and how much damage can be contained before it spreads.

AI brings a different version of the same problem.

Earlier software gave builders a clearer sense of predictability because the same input, under the same conditions, was expected to behave in the same way. AI offers a more fluid reality. Context changes, users behave differently, new data enters the workflow, and a model that looks stable in testing can still surprise the team once it is used every day.

Gowrav captures the shift clearly: “Production has become basically part of the validation loop.”

In practical terms, production becomes the place where deeper validation begins. The system has to be watched after deployment. Failure modes have to be understood before scale. Business value has to be measured beyond technical performance. Trust has to be earned through continued use, rather than declared at launch.

AI is often celebrated for what it can generate. Gowrav is more interested in what it can survive.

The Decision Before the Model

Gowrav begins with the decision.

Before a project starts, the questions are practical and sequential. Which decision needs to improve, and why does the current process fall short? If the AI gives a poor answer, can the mistake be reversed, and what will it cost? The workflow, ownership, business value and data quality all need to be examined before the technology choice becomes meaningful.

Large organizations can produce endless AI use cases. Every team has friction. Every department can ask for a pilot. Every process can appear ready for automation. The discipline lies in choosing the right problem and understanding whether the organization is prepared to absorb the solution.

A poorly framed AI project can look impressive for a while. The model may work, the demo may succeed and the pilot may show promise. The weakness appears later, when users resist the workflow, data fails to match the real context, economics become difficult to defend or ownership disappears after go-live.

Gowrav’s builder instinct is practical: define the decision, understand the workflow, examine the data, clarify the economics, and choose the technology after that.

Speed matters only when the system can carry discipline with it.

When Live Still Means Unfinished

Procurement became one of the clearest examples of how Gowrav thinks about enterprise AI.

A large procurement process can involve hundreds of pages of documentation. An RFP may run into 200 or 300 pages. Vendors may respond with 600 or 700 pages covering technical capability, delivery approach, past experience and supporting evidence. Human evaluators then score those responses across several criteria.

Time is the visible problem. A single technical evaluation can take two to three weeks. The harder problem is rationale: why one vendor received a particular score, whether the evaluator was strict or generous, and whether the number reflected evidence or habit.

Gowrav’s team built an AI-supported technical bid evaluation system to read documents, compare responses with requirements, assist scoring and capture rationale. The product went through months of development and user acceptance testing.

The harder test came during adoption. Some business users wanted to wait for more integrations before using it widely. Documents still had to be uploaded manually, so the hesitation was understandable.

Gowrav saw another side of the problem. The system needed exposure to more RFPs, contract types and evaluation patterns. With human oversight built into the process, controlled production use could reveal what a closed testing environment could never fully show.

His distinction is sharp: “It is not really operational. It is just live.”

A system can be live and still remain outside the real rhythm of the business. Operational value begins when the business owns the system after go-live, measures whether the original decision has improved, and keeps refining the workflow around it.

Engineering can create guardrails, audit trails and human-in-the-loop architecture. It can reduce risk and make the system safer to use. Yet engineering alone cannot create business ownership where the organization has not built it.

Many AI systems fade quietly. A pilot works, a launch happens, attention moves elsewhere, ownership weakens, and months later nobody can clearly say whether the decision has become better. That may be one of the least visible and most important failure modes in enterprise AI.

Data Has a Past

Gowrav’s years at Scienaptic Systems gave him a grounded view of data.

As Head of Engineering, he worked on AI-led credit underwriting products used by banks and NBFCs across India and the US. Credit decisioning is sensitive because the outcome affects real access. A model can influence whether someone receives credit, what terms they receive and how the formal financial system understands their risk.

Thin-file customers show why data needs care. Limited formal credit history can indicate weak financial behavior. It can also mean that a person lived outside systems that adequately captured financial behavior.

Gowrav explains the issue through survivorship bias. During World War II, analysts studied aircraft that returned from combat and examined the bullet marks on them. The visible damage seemed to show where reinforcement was needed. The missing evidence was with the planes that never returned. Available data carried only part of the truth.

Credit data can behave similarly. Bureau records show people who are already visible to the system. They say much less about those who were never included properly. When AI learns only from the visible population, historical exclusion can start looking like objective risk.

Gowrav’s larger lesson goes beyond credit.

“The data available to us is not the same as reality on the ground. It is only what an institution chose to collect, monitor and record.”

Data reflects the system that produced it. It carries old incentives, exclusions, missing context, process choices and human judgment. Builders have to understand how the data came into being before treating it as evidence.

The procurement example shows the same risk. Historical evaluation scores existed, yet those scores carried human subjectivity. Training directly on them could have passed old inconsistency into a system meant to create consistency.

Serious AI requires humility toward data because data is evidence with a history.

India’s Constraint Advantage

India is a demanding market for AI builders.

There are many languages, voice-first users, uneven connectivity, ordinary devices, tight economics, crowded workflows and wide variation in behavior. A system built only for ideal conditions will struggle here very quickly.

Gowrav sees these constraints as part of product thinking.

One example came from smart-meter installation. A computer vision system was being built to validate whether meters were installed correctly, whether the meter number matched the record, whether fuse checks were completed and whether the installation met required standards.

The first approach was to capture images in the field and process them on remote servers. Field reality changed the thinking. Installations were happening in remote areas. Connectivity could not be assumed. Technicians needed immediate feedback at the site. The solution had to run on a commodity Android phone and guide the technician in real time.

Gowrav captures the lesson clearly: “Constraints actually dictate the product thinking.”

Products built for India often have to become cheaper, simpler, multilingual, field-ready and resilient from the beginning. They have to work with limited bandwidth, ordinary hardware, impatient conditions and users who cannot wait for perfect infrastructure.

Those qualities can travel. Many markets outside the richest technology corridors face similar constraints. India’s strongest AI products may come from builders who treat constraint as product discipline.

The Talent Gap After AI Tools

AI tools have made building faster. They have also made weak understanding easier to hide.

Gowrav saw the risk during a hiring conversation. A final-year engineering student used an AI coding assistant for a basic data-structure problem. The tool produced largely correct code, but the function was never called, so the program produced no output.

Instead of reading the code and finding the gap, the candidate kept asking the AI assistant for another fix. More code appeared, while the basic issue remained.

The concern was the absence of a mental model.

A strong technologist can use AI to move faster. A technologist without a strong mental model can use AI to avoid understanding. As tools become common, the difference will become harder to hide.

For Gowrav, India’s AI skill gap goes beyond the shortage of data scientists, model builders or certified AI engineers. The deeper shortage is judgment. The gap shows up before the prompt. A young technologist has to frame the problem clearly, understand the domain, read the user’s workflow, reason through failure and know when AI adds value instead of complexity.

As AI makes implementation easier, the ability to know what should be built and recognize when it is wrong becomes more valuable.

Universities and industry need a stronger bridge. Students need exposure to messy problems, business constraints, domain experts and consequences. Classroom problems often arrive clean. Real AI work arrives with missing context, conflicting incentives and incomplete data.

Tool fluency will become easy to find. Independent judgment will remain scarce.

Leadership After Technical Mastery

Gowrav’s leadership philosophy has changed with scale.

Earlier in his career, technical mastery carried much of the weight: writing performant code, learning programming languages, understanding engineering principles and building products well. As responsibility widened, people, ownership and communication became equally important.

Gowrav puts it directly: “Technology is more of an accelerator rather than the solution.”

A product works when people change how they work around it. Doing so requires business users who trust the system, leaders who own the outcome, engineers who understand why a trade-off was made, and teams with enough context to make good decisions when the leader is not in the room.

Gowrav draws a useful distinction between compliance and commitment. Authority can produce compliance. Commitment needs rationale. People need to understand the alternatives considered, the trade-offs weighed and why one path was chosen.

At senior levels, technology leadership becomes less about having the best answer and more about improving the judgment of the system around you.

Product Scars and AI Debt

Founder experience gives Gowrav’s AI thinking a useful realism.

At MyNxtDoor, he built a B2B marketplace for construction-material procurement using SMS, WhatsApp and email-led reverse auctions. The idea was strong. The need existed. Early transactions happened. Then user incentives reshaped the product.

Suppliers used the platform to discover buyers and then contacted them directly. The marketplace began functioning as a lead-generation layer instead of a transaction platform.

The lesson carries directly into AI product building. A product succeeds when logic, timing, incentives, trust and economics move together.

The same realism shapes his thinking about AI infrastructure. Large technology bets need more than ambition. Capex-heavy decisions have to be judged through return, depreciation risk, competitive pressure and long-term usefulness. Hardware can age quickly. Models can change. Market assumptions can shift. Ambition without economics becomes expensive belief.

AI also creates forms of debt that are harder to see than ordinary technology debt. Data debt builds when teams use historical records without understanding the incentives, exclusions and process choices behind them. Evaluation debt builds when a system is judged only through benchmarks, pilot metrics or controlled tests. Governance debt builds when ownership after go-live is unclear. Management debt builds when leaders reward speed without asking whether the organization can absorb what has been built.

At scale, governance debt is often the most dangerous because it becomes visible late. Data debt can be found when teams inspect the records. Evaluation debt becomes visible when pilot metrics fail to predict production behavior. Management debt appears when speed begins to outrun absorption. Governance debt often appears months after go-live, when attention has shifted and nobody is still asking whether the original decision has improved.

These debts compound. Unexamined data creates weak evaluation. Weak evaluation creates false confidence. False confidence leads to loose governance. Loose governance allows management to reward movement without absorption.

By the time the organization notices the problem, the issue is no longer technical alone. The system may be running, the dashboard may look healthy and the model may still meet technical metrics, while the business outcome remains absent. The dangerous version of AI debt appears when the technology looks healthy while the decision remains unchanged.

What Deployment Discipline Actually Requires

Several lessons emerge from Gowrav’s experience.

• Start with the decision being changed. A team that begins with model capability may build something technically impressive that the organization was never prepared to absorb.

• Treat production as a continuation of validation. AI systems treated as complete at go-live often face their hardest test after leadership attention has already moved elsewhere.

• Read data as institutional evidence with a history. Historical records carry the incentives, exclusions and process choices of the systems that produced them.

• Distinguish deployment from adoption. A system becomes valuable only when the business owns it, measures it and keeps improving the workflow around it.

• Measure business outcomes along with model health. A healthy model dashboard means little if the decision the system was built to improve has not become better.

• Let field constraints shape the product early. A solution that treats connectivity, language, device quality or user behavior as late-stage concerns may work in testing and fail in daily use.

• Explain rationale along with decisions. Teams make better decisions when they understand the trade-offs behind a choice, instead of only receiving the final instruction.

• Recognize that AI debt compounds across data, evaluation, governance and management. An organization that cannot read those debts together may mistake a technically clean deployment for a successful one.

• Taken together, these principles point toward a different definition of AI success: whether the decision became better, and whether it stayed better.

The Question After Capability

The global AI conversation still spends much of its energy on capability: larger models, faster inference, stronger agents, better benchmarks and cheaper compute.

Those advances matter. Capability tells us what AI can do. The more consequential questions come afterward. Which decision will actually improve? What failure can the organization tolerate? Who owns the workflow after go-live? Where did the data come from? Which human judgment should remain in the loop? What happens months later, when the excitement of launch has disappeared?

These are the questions that decide whether AI becomes real infrastructure or remains a promising experiment.

Gowrav Shekar’s perspective has been shaped by experiences that sit on different sides of that transition. Embedded systems gave him the discipline of failure modes. Credit AI gave him the warning that data can exclude while appearing objective. Founder-led products gave him the memory that user incentives can defeat product logic. Enterprise AI gave him the understanding that technology lands only when ownership, measurement, workflow and trust move with it.

The common thread is consequence.

The closer technology gets to real decisions, the more important it becomes to ask whether the organization has become better at making those decisions because the technology exists.

The real test of AI deployment arrives months after go-live, when the organization has to say honestly whether the decision it set out to improve has actually become better.