Why Enterprise AI keeps dying in the pilot stage

The pilot goes well. An assistant reads a support case, produces a clean summary, drafts a reply that sounds like a person wrote it. Nobody in the room argues with the result. Then the project stalls, or it ships and quietly stops being used.

Ashok Apati has designed enough of those pilots to have a theory about what happens next, and it is not a flattering one for the technology. "The hardest enterprise AI problems are often not model problems," he says. "They are architecture, integration, data, security, workflow, governance, and adoption problems."

His own career has been spent building the layer underneath. Now a lead product developer and digital transformation leader at a global consumer goods company, Apati has worked for more than 13 years across enterprise integration architecture, Salesforce, cloud transformation and digital commerce. He led the technical design and proof-of-concept development of generative AI capabilities built into Salesforce, including Case and Account Assistants covering case summarisation, drafted customer responses, risk identification, next-best-action recommendations, knowledge suggestions, account intelligence and pre-visit preparation.

That work is where his argument comes from. The assistants demonstrated quickly that a language model could summarise a case usefully. What took longer was everything that had to be true before such a thing could be trusted inside a working business: retrieving the right Salesforce context, excluding personal data that should never reach a model, defining reusable AI services rather than one-off integrations, structuring prompts around specific business actions, and keeping a human in front of anything consequential.

None of that is model work. "Enterprise AI is an architecture challenge, not simply an LLM challenge," he says. Organisations spend their time comparing models when the harder question is structural: "creating an architecture that can provide the model with the right context, at the right time, for the right user."

There is a less comfortable corollary, and he states it plainly. "AI exposes existing technology and data debt." Fragmented customer data, inconsistent identifiers, outdated APIs, duplicated information, weak integration patterns and unclear data ownership have usually been tolerable for years. Then something arrives that needs to read across all of it at once. "AI does not eliminate these problems," he says. "In many cases, it makes them more visible."

He is in an unusual position to say so, because he spent years clearing that debt before AI made it urgent. He played a key technical leadership role in migrating mission-critical applications and integrations to Microsoft Azure while the business kept running, contributing to roughly $600,000 in annual cost savings. He has designed, modernised and supported platforms carrying approximately $260 million in annual transaction volume, serving more than 150,000 active customers and processing over 100,000 orders a year. He helped redesign a customer registration experience that has since handled around 110,000 registrations, and contributed to a single sign-on programme built on Okta.

Those projects explain the sequence he now argues for. Cloud provides scalability, APIs and integrations provide connectivity, identity establishes trusted access, enterprise data provides context, and only then does AI have something solid to reason over. "AI transformation is not separate from digital transformation," he says. "It is the next layer of it."

Which is also why he is unsentimental about how most AI programmes begin. The common mistake, in his telling, starts with the wrong question: "We have access to Generative AI, what can we build?" He would rather start from a measurable problem, reducing case-handling time or shortening sales preparation, and let that decide what gets built and which model is used.

Two of his design rules follow directly from watching pilots fail. The first is that AI has to appear where people already work. If an employee has to leave the application they are in, open a separate tool, paste in the context by hand and carry the answer back, the tool will be abandoned no matter how good the output is.

The second is about who remains accountable. For consequential work such as complaint handling, reason-code selection and customer communications, the pattern he favours is deliberately conservative: AI recommends, a human validates, and the enterprise system executes. Rather than forcing a single reason code, the system offers a shortlist for an agent to confirm. Drafted replies get reviewed before they are sent. Autonomy increases later, he argues, and only as governance and measured performance earn it.

Underneath both rules sits a preference for substance over polish. "Grounding is more important than eloquence," he says, and the reason is that a fluent wrong answer travels further than an obvious one. "An AI-generated answer that sounds professional but contains incorrect business information can be more dangerous than having no answer at all."

It leads him to the test most pilots never have to pass. "A successful demonstration is not evidence of a successful AI implementation," he says, and pilots, in his view, should carry measurable exit criteria before anyone calls them a success: case-handling time, preparation time saved, recommendation acceptance, adoption, cost per interaction.

So the question he would put to any organisation shopping for a model is a different one entirely. "Is our enterprise architecture ready to make AI useful, trustworthy, measurable, and scalable?" Pilots rarely die because the model disappointed. They die in the gap between a demonstration and an organisation that was never quite ready to receive one.