Here's an uncomfortable truth about enterprise AI:
Most initiatives don't fail because the model was bad. They fail because the data that model needed was locked inside systems that were never designed to be asked questions.
I watched a team go through three model swaps in two months. Each swap came with internal demos that looked better than the last. Each one degraded the same way in production. Nobody asked why until the fourth swap was being approved — and by then, the answer was obvious: the product catalog data they were querying had no price history attached, only current price. The model was doing its best reasoning with one hand tied behind its back. The model was fine. The data wasn't built to answer the question being asked.
The real problem? Operational systems — ERPs, CRMs, supply chain platforms — were built for one job: recording transactions. They were optimised for stability, compliance, and reliability. Not for being explored. Not for being combined across systems. Not for powering AI that needs to reason over your entire business, not just one department's data.
So when teams try to connect AI to those systems, they hit a wall. Access restrictions. Undocumented schemas. Integration complexity that wasn't budgeted for. The demo worked. Production doesn't.
And here's what makes it worse: the failure gets misdiagnosed. Teams switch models. Tune prompts. Add retrieval layers. None of it fixes a data architecture problem.
Before asking "which model should we use?" — ask this:
- Can the systems that hold our operational data actually support AI workloads?
- Can relevant data be accessed without friction across systems?
- Are data contracts stable enough that AI outputs won't drift as the underlying schema changes?
That's the questions that separates pilots that ship from pilots that stall.
👉 Follow to my blog post for more Why AI Projects Fail
Top comments (0)