Three decades in enterprise technology means living through a few cycles already: Y2K, the internet rollout, the cloud migration wave, and now AI. The systems changed each time. The underlying lesson did not. Technology is rarely what kills a project. People, process, and data usually do the damage.
Boards move fast these days. Most CEOs want an AI strategy on the table this quarter, sometimes this month, because a competitor announced something or an investor asked an uncomfortable question. Down in the implementation layer, where systems actually get integrated and deployed, the picture looks different from what gets presented upstairs. None of this is an argument against AI. It works, in the right places, for the right problems. The more interesting question is why so many pilots never make it to production and what separates the ones that do.
The pilot that never becomes production
The pattern is familiar by now. A business head funds a proof of concept, IT hears about it after the fact, and InfoSec only gets pulled in once someone finally asks where the customer data is going. Six months pass. The original sponsor has moved to a different role, the API bill has crept up without much scrutiny, and the demo that got applause in the town hall is sitting untouched in a sandbox somewhere.
CRM implementations have failed for far smaller reasons than this over the years, so it should not be surprising that AI, layered on top of process change nobody has bothered to fix, runs into the same wall. Standard operating procedures still live in shared drives. Approvals still move through email threads. Adding a probabilistic system on top of that mess does not simplify anything.
The deeper issue is ownership, more than model choice. Somebody has to maintain the prompts. Somebody has to be on the hook when the assistant confidently quotes a return policy that was retired two years ago. That has to sit with a business owner, not the innovation lab and not the IT team running the infrastructure. Skip that step and the result is a polished prototype nobody wants to operate, sitting next to a support queue nobody wants to staff.
A lot of inquiries are still open with some version of “We want to implement ChatGPT.” Asked what business problem it is meant to solve, the answer is often a long pause. AI is an engine. It needs something to power. And in most engagements, the bulk of the actual work has little to do with the model itself and everything to do with the data feeding it.
Data debt does not disappear because everyone is excited
Boards want to talk about copilots and autonomous agents. On the ground, the customer record often lives in three different places at once: the ERP, a decade-old custom application nobody wants to touch, and a spreadsheet a regional branch office insists is temporary. Product data sits locked inside PDFs. Knowledge bases stop getting updated the day the person who maintained them retires or moves on.
Indian enterprises digitised in a hurry after GST, and again during the pandemic. Moving fast is not the same as building on solid ground, and AI has a way of exposing that gap rather than closing it. It does not fix messy data. It repeats the mess, faster, and with a lot more confidence than it has earned.
One manufacturing client came in wanting predictive maintenance, sitting on thirty years of sensor and maintenance data spread across Oracle, DB2, and a pile of flat files, full of duplicates nobody had ever reconciled. Six months went into cleaning and mapping that data before a single model got trained. Vendors like to sell six-week go-lives. Real data remediation, done properly, usually runs into quarters rather than weeks. Skip it and all that happens is the existing mess gets automated a little faster.
The Digital Personal Data Protection Act has sharpened this problem rather than simplifying it. Purpose limitation is not an abstract legal clause anymore the moment an AI pipeline starts pulling customer history from five systems that were never designed to talk to each other in the first place.
Integration beats intelligence, most of the time
A manufacturing client in Pune once said the board wanted “AI across the customer journey.” Once that journey actually got mapped out, the pain point was not intelligence at all. It was the handoffs: enquiry to quote, quote to order, order to dispatch, and dispatch to service ticket, with no shared customer ID linking any of it together. No model repairs a broken handoff. That is a systems problem before it is an AI problem.
Most of the real work turns out to be plumbing: secure APIs, identity, audit trails, and a way to roll back cleanly when something inevitably breaks. An assistant that cannot reliably update a case or reflect actual inventory is not really useful. It is a chat window dressed up to look like one.
Compliance and the audit trail problem
Years spent across banking, healthcare, and insurance projects bring out a specific version of this problem. In traditional software, when something breaks, someone traces the stack and finds the logic error. AI rarely offers that comfort. It is a probabilistic system, and more often than not it cannot explain why it landed on a particular answer.
A financial services client wanted AI in the loop for loan approval decisions. The model performed well on accuracy. But the moment it rejected an applicant, the bank was legally required to explain why, and “the model felt like it” is not something any regulator will accept. What followed was heavy, deliberate logging work just to capture which data points actually drove each decision, so the system stayed both accurate and explainable when someone came asking.
Official policy rarely matches what people are actually doing day to day. Client emails and contract drafts are already being pasted into public AI tools from personal phones, whether there is a policy against it or not. That is shadow IT, only with a much thinner trail than the earlier version of this problem. Banning the tools officially while leadership quietly uses them for their own notes tends to damage credibility faster than any regulator ever will.
What actually works
None of this is a case against AI. It is a case for being more selective about what gets funded and what gets skipped. The programs that hold up over time tend to start narrow: one bounded use case, clean data for that specific slice, a human still in the loop, and a named business owner accountable for the outcome rather than just the demo.
Working with clients across India, Southeast Asia, the US, and occasionally Europe out of a Pune base, the same pattern shows up almost everywhere: legacy debt, cautious risk appetite, talent concentrated in a handful of cities, and a gap between how urgently the board wants results and how much the operations side can actually absorb. The organisations getting real value out of this are rarely the loudest ones talking about AI. They are the ones doing the unglamorous work of data contracts and access models, listening to the people who actually deal with customers, and being willing to say no to use cases that are not ready yet.
After thirty years in this field, the pattern holds up: there are very few silver bullets, and boring execution tends to win. When AI adoption stalls, the model is rarely the reason. It usually was not about the technology to begin with.
The article has been written by Nitin Kadam, Co-founder and Principal Architect, digiCloud Solutions
