- AI cannot invent information that is not there or reconcile numbers that contradict each other across systems; it inherits every data problem underneath it and makes it more visible.
- Data-ready does not mean perfect. It means the data is reachable in one place, recorded consistently, and your systems can exchange it automatically.
- Fixing it is usually unglamorous plumbing, not a rebuild: map the systems, connect the ones that must talk, standardise the fields that keep clashing, clean the obvious duplicates.
Most businesses that come to us saying “our AI project stalled” do not have a model problem. They have a data problem. The tool they bought or built was never the issue. It simply could not do anything useful with what it was given. This is the most predictable and most avoidable reason AI projects go nowhere, and it is worth understanding before you spend money on anything else.
The pattern behind most stalled projects
It usually goes like this. A business decides to add an AI agent for customer support, or build a tool that predicts stock needs, or automate reporting across departments. The idea is sound. The budget is approved. Someone builds or configures the system.
Then it launches, and the answers are wrong, or incomplete, or the system cannot see half of what it needs. The agent tells a customer their order has shipped when it has not, because the shipping system and the order system do not talk to each other. The forecast produces numbers that do not match reality, because it learned from three months of clean data sitting next to two years of duplicates and mislabelled records. The reporting assistant cannot answer a simple question about revenue because “revenue” is calculated one way in the finance spreadsheet and another way in the CRM.
None of that is a failure of the AI. AI is good at finding patterns and producing language. It cannot invent information that is not there, and it cannot reconcile numbers that genuinely contradict each other. If your data is scattered, inconsistent or locked in tools that do not connect, whatever you build on top inherits all of those problems, and usually makes them more visible and more embarrassing than they were before.
When people ask us why AI projects fail, the honest answer is rarely “the technology wasn’t good enough”. It is “the data wasn’t ready, and nobody checked before starting”.
For the wider due-diligence questions, see five questions to answer before you spend a dirham on AI. This note is only about the data.
What “data-ready” actually means
It does not mean perfect data. No business has perfect data. It means three practical conditions are met well enough that an AI system can use what you have.
Is it in one place, or five?
Most businesses run on more systems than they realise: a CRM, an accounting platform, a spreadsheet someone built three years ago that half the team still relies on, a support tool, a stock system, maybe a separate web shop. Each holds a piece of the picture and none was designed to share it.
An agent can only act on what it can reach. If customer history lives in one tool and order status in another, with nothing connecting them, the agent is working with half the story, and it usually cannot tell you that is happening. It just gives you an answer that is confidently incomplete. The fix is rarely to throw the tools out and buy one giant system. It is to build proper connections between the systems you already have, so the same information flows correctly everywhere it needs to.
Is it consistent?
Even when data lives in fewer places it is often recorded differently depending on who entered it and when. One customer appears as “Acme Corp”, “Acme Corporation” and “ACME” in three records. A product has one code in the warehouse and another in sales. Dates are stored in three formats. Fields that should be standard (status, region, category) are not, because different people filled them in over different years with no shared rulebook.
A person skimming a spreadsheet does not notice. An AI matching records, adding up totals or answering a question that spans two sources hits it every time. If “Acme Corp” and “ACME” are treated as two customers, the AI-generated report on customer activity is simply wrong, and it can take a while before anyone works out why.
Can the systems talk to each other?
The third condition is technical. Even if the data is reasonably clean, can your systems exchange it automatically? Some older or niche software was never built for modern connections. Some only allow manual exports. Some data sits behind logins that were never meant to be used by a program.
It matters because an agent that is supposed to update a record, check a status or pull live information needs a real working connection, not a person copying between two browser tabs. If the connection does not exist yet, it has to be built before the AI project can do what it is meant to do.
A six-question self-check
Run through this honestly before starting, or restarting, an AI project. You do not need a perfect score. You do need to know where the gaps are before you commit budget.
- Can you name every system that holds data relevant to this project? Specifically, by name, not roughly.
- Do those systems share data automatically today, or does someone move it by hand: exports, copy-paste, re-typing?
- If you pulled the same customer, order or product from two different systems, would the details match?
- Is there one agreed definition of your key terms (a customer, an active order, a completed job), or does it depend on which team you ask?
- Does anyone own data quality, even informally? Someone who would notice and fix a broken or duplicate record?
- Have you actually looked at a sample of the real data you would feed in, rather than assuming it is fine because it looks fine at a glance?
If the answer to more than one or two of these is “no” or “not sure”, that is not a reason to drop the idea. It is a reason to fix the data layer first, so the AI project you eventually run actually works.
What fixing it looks like
It is not usually a massive rebuild. In most of our work it comes down to a few concrete steps: map which systems hold what, build real connections between the ones that need to talk, standardise the fields and definitions that keep causing mismatches, and clean up the obvious duplicates and errors before they get baked into the next tool.
This is deliberately unglamorous. It is tempting to skip it and go straight to the exciting part: the agent, the automation, the dashboard. But it is the difference between an AI project that works on day one and one that limps along, gets blamed on “the AI”, and is quietly shelved six months later. It is exactly what our data and integrations work is built around: getting the systems you already run to connect and agree with each other, so whatever you build on top has something reliable to work from.
Questions
How long does getting data ready usually take?
Do we need a data warehouse first?
Our data is in spreadsheets. Is that a problem?
Can AI clean the data for us?
Leads every 90-day programme personally. Writes these notes from the projects that shipped and the ones that did not, so you can skip the second kind.
