A team we spoke with spent three months building an internal AI assistant. It was meant to answer staff questions about policies, pricing, and procedures. The demo was impressive. The launch was not.
Within a week, people had stopped trusting it — because it kept giving confident, well-worded, wrong answers. It quoted an old pricing sheet as if it were current. It cited a policy that had been revised the year before. It was, in short, fluent and unreliable, which is the worst combination a tool can have.
The model was never the problem. The problem was the data underneath it: outdated documents, three conflicting versions of the same policy, and half the "source of truth" living in people's inboxes. The AI did exactly what it was told — it just had nothing trustworthy to work from.
This is the quiet truth behind most disappointing AI projects. They don't fail on the model. They fail on the data. The encouraging flip side: you don't need a perfect, enterprise-grade data lake to start. You need the right data, clean enough, for the specific problem you're solving. Here's a practical way to get there.
1. Define the question first
Don't gather data in the abstract — that way lies a two-year "data readiness" project that never ships anything. Start from the exact decision or output you want to improve, then work out precisely which data that requires.
A narrow, well-defined question is a gift: it tells you exactly what "ready" means, so you can stop when you get there instead of boiling the ocean. "Answer staff pricing questions accurately" points you at one clean, current pricing source — not at every document the company has ever produced.
2. Find where the data actually lives
Before you touch anything, map it. List the systems that hold the data you need — CRM, finance, shared drives, that one spreadsheet everyone quietly depends on. For each, note what's structured, what's locked in PDFs, and what only exists as tribal knowledge in someone's head or inbox.
This map is worth more than it looks. It usually explains, in one page, why previous efforts stalled — and it turns "our data is a mess" (paralysing) into a specific, finite list of things to fix (manageable).
3. Fix the essentials, not everything
For your chosen use case — and only your chosen use case — focus on three things:
- Consistency. The same thing is named the same way across systems. If a customer is "Acme Ltd" in one place and "ACME Limited" in another, the AI can't reliably connect them.
- Completeness. The specific fields the model needs are actually filled in. Missing data produces guesses, and guesses erode trust fast.
- Access. The data can be reached securely and automatically, without someone manually exporting it every week. If a human has to feed it, it will fall out of date the moment they're busy.
Leave everything outside your use case for later. Perfect is the enemy of shipped, and a narrow slice of clean data beats an ocean of messy data every time.
4. Connect before you're clever
Here's the step most teams skip, and the one that quietly determines success. If people are copying data between systems by hand to keep it current, no AI project sitting on top will be reliable — you're building on sand.
Integrate those systems first. Clean, connected data is the foundation everything else stands on, and — this is the part worth savouring — it pays off with or without AI. Even if you never build the model, connected data means better reports, fewer errors, and less manual work. The AI just makes the foundation more valuable.
5. Start small and measure
Finally, prove the use case on a contained slice of real data before you expand. Point the AI at one department, one document set, one clearly-scoped question. Check its answers against reality. Watch where it gets confident and wrong — that's your data telling you where it's still weak.
Only once it holds up on the small version do you widen it. This is slower than a splashy full launch, and far more likely to end with a tool people actually trust.
Governed, accurate, boring reliability beats a dazzling demo that can't be trusted. Aim for the former.
The version that works
Had our disappointed team done this in order — defined the question, mapped the sources, cleaned and connected just the pricing and policy data, then tested on a slice — their assistant would have launched trustworthy instead of embarrassing. The technology was ready the whole time. The data wasn't.
Do the groundwork, and AI stops being a gamble and starts being a genuinely useful tool.
Want a hand getting your data ready for AI? That groundwork is a big part of what we do. Talk to us or explore our AI services.