Why most enterprise AI pilots never make it to production — And what fixes that
Every CIO has a version of the same slide by now: dozens, sometimes hundreds, of AI pilots scattered across the business, each one promising. Few of them ever become systems the enterprise actually depends on. According to Bharat Chadha, Partner, Tech Consulting at Uniqus Consultech, that gap has a specific, identifiable cause — and it isn’t the AI model.
“The single biggest bottleneck is the data and context layer, and not the model,” Chadha says. Pilots tend to succeed because they run on curated, hand-picked datasets built to make the demo work. Production is a different animal entirely: the system now has to reach across ERP, CRM, documents and workflows in real time, while respecting permissions, business rules and regulatory constraints. The instant users can’t trust the source, quality or security of the data behind an answer, they quietly stop trusting the output — regardless of how capable the underlying model is.
That’s the uncomfortable truth for technology leaders who have spent two years benchmarking foundation models: the models themselves are becoming commoditized. The durable competitive advantage is the trusted data foundation feeding them.
Even organisations that get the data layer right run into a second wall almost immediately: cost predictability. Enterprises are built to budget for fixed costs. AI spend scales with usage, and that variability is enough to stall the approvals needed to move a pilot into core production. Chadha’s read is blunt: the organisations that solve both the data problem and the cost problem are the ones that will go from hundreds of scattered pilots to a handful of AI systems actually running meaningful parts of the enterprise.
Talent strategy: not everyone needs to become an AI engineer
If the data layer is the infrastructure problem, talent is the organisational one — and here too, Chadha argues most enterprises are asking the wrong question. The goal isn’t turning every technologist into an AI engineer. It’s making every domain expert AI-enabled.
That distinction plays out as what he calls a barbell strategy. On one end, existing technology teams keep running and modernizing the core estate. On the other, frontier-AI skills get pushed directly into the business, so functional teams can use prompting, low-code tools and assisted coding to build their own agents — inside guardrails set centrally. The logic: the people closest to a problem are best positioned to design its solution, and that’s where much of the value sits.
Holding the middle of the barbell is a small, high-caliber AI Center of Excellence sitting inside the CIO or CTO organisation. Its job isn’t to build every agent — it’s to build enterprise-wide use cases, set architecture and security standards, own governance and reuse, and maintain the sandbox that lets business-built agents exist safely.
The hiring rule that falls out of this is simple: upskill internally where the value is domain-specific, and hire or partner externally where the skill is scarce and platform-level — think ML engineering or AI infrastructure. Chadha notes that some specialist capabilities move so fast, and may not be needed at sustained scale, that augmenting a strong internal core with external specialists often beats trying to build every capability in-house.
Governance: match the controls to the risk, not the technology
Ask most technology leaders about AI governance and they’ll describe a single framework applied uniformly. Chadha’s operating principle inverts that: govern the risk, not the technology.
An employee summarizing a document and an agent releasing a payment should never carry the same governance burden. One framework can cover both use cases, Chadha says, but it can’t apply identical controls to both — because most enterprises are now running more than one distinct “AI pillar,” and each needs its own control environment.
A broad employee-productivity platform, for instance, needs light-touch, largely technical controls — what data can go in, which models are approved for which data types, how outputs can be used — backed by monitoring rather than heavy policy, so innovation isn’t taxed by friction. An enterprise pillar where agents take actions touching financial reporting, customers or regulated processes is a different story entirely. That requires real oversight: an AI governance council and clear accountability spanning business, security, risk, compliance and audit.
The practical move, Chadha says, is to classify every use case by data sensitivity, autonomy, customer impact, regulatory exposure and the cost of a wrong decision — then let governance intensity scale with that risk score. Controls for identity, data access, model evaluation, logging, human approval and exception monitoring should be embedded directly into the engineering lifecycle so they run technically rather than manually. Done this way, a productivity assistant stays fast while a payment-approving agent stays tightly held — without forcing every initiative through the same gate.
The metric transformation programs keep missing
Digital transformation reporting has a well-known blind spot, and after years spent across Big Four and consulting engagements, Chadha has a name for it: human interventions per business outcome.
Most programs get judged on ROI, NPS and time-to-market. Useful numbers, but none of them answer the real question — does the organisation actually operate differently as a result of the transformation? That answer lives in behavioral signals: straight-through-processing rates, exception volumes, data quality, process compliance, task velocity. These are the metrics that consistently get overlooked.
The trap Chadha describes is familiar to anyone who has sat through a steering committee update: a program reports that 70% of a process is now automated, while people quietly work around the system, enter poor data, bypass controls, and burn hours clearing exceptions. The technology KPI looks impressive. The process hasn’t actually improved, and human behavior hasn’t evolved. Transformation creates lasting value, in his view, when it changes behavior and reduces complexity — not when it simply installs a new system or shifts work between teams.
Speed versus risk is a false choice
The last friction point Chadha addresses is one that shows up in nearly every large-scale implementation: the tension between moving fast and managing IT risk properly. His diagnosis is that this isn’t really a speed-versus-risk problem at all — it’s what happens when every initiative gets treated as if it carries identical risk.
The fix is risk-tiering: fast lanes and slow lanes, built deliberately. Low-risk implementations move through automated, pre-approved paths — reusable patterns, policy-as-code, controls built directly into the delivery pipeline — so teams can move without a committee in the loop. Higher-risk implementations, the kind that can materially affect customers, money, regulated decisions or critical operations, go through deeper review and compliance gates that simply shouldn’t be rushed.
What makes the model work, Chadha says, is bringing risk, security, compliance and audit into the design from day one and embedding them inside delivery squads — rather than bolting on a review at the end, where problems are most expensive to fix. Controls become part of the definition of done, not a separate checkpoint.
Done well, he argues, rigor stops being a tax on speed and becomes the thing that lets organisations move fast safely — because the safe path ends up being the fastest one, too.
The through-line
Across data infrastructure, talent, governance, metrics and delivery speed, the same pattern recurs in Chadha’s answers: enterprises that scale AI successfully aren’t the ones with the most pilots or the most advanced models. They’re the ones that have matched their controls, their skills and their measurement to the actual risk and actual value of each use case — rather than applying one rule to everything. That discipline, more than any single technology choice, appears to be what separates a slide full of pilots from an enterprise actually running on AI.