When a company tells me they want to adopt AI, the conversation usually starts in the wrong place.
They want to talk about which model to use, which vendor, which use case to prioritise. These are reasonable things to think about. But they're not where most AI initiatives actually get stuck.
Most AI projects stall because the data underneath isn't ready. Companies that miss this can spend six to twelve months finding out the hard way.
A familiar pattern
I've seen this at large organisations with established data estates and at startups building everything for the first time.
At one company, the AI initiative had funding, people, a sensible model, and a clear use case. But customer data sat in four systems with partial deduplication and no shared identifier. The team first had to build an entity resolution layer. That took five months and wasn't in the plan.
At a startup, event data existed but wasn't modelled consistently. Field meanings had drifted over eighteen months. There was no schema registry, version history, or documentation. The AI project turned into data archaeology.
Both teams had capable people and enough resources. They had simply planned the AI layer before understanding the data beneath it.
Why AI makes existing problems visible
Legacy data problems are usually manageable until you try to do something ambitious with the data.
A reporting system can tolerate inconsistent identifiers across systems — you just run a join and accept some noise. A recommendation engine cannot. The model will encode the inconsistency into its outputs and there will be no obvious way to know when it's doing so.
A data warehouse built for analytics can survive schema drift over time — someone queries it, they notice the anomaly, they clean it up. A real-time inference system cannot. The pipeline will process the anomaly silently and the errors will surface in production behaviour, not in error logs.
AI raises the bar. Data needs to be consistent, documented, and semantically stable in ways many legacy systems were never built to guarantee. That isn't a criticism. Those systems had a different job.
Four questions before you commit
Before scoping an AI initiative, I would ask four questions. It isn't a full audit, but it shows what may need to happen first.
1. Do you know where the data lives and who owns it?
For the data the system needs: who created it, where is it stored, who has access, and who owns its quality? "It should be in the warehouse" is a gap, not an answer.
AI projects surface ownership questions nobody had to answer before. Resolving them before the project is a conversation. Resolving them during it is a delay.
2. How consistent is the data over time?
Has the schema changed significantly in the last year? Are there fields whose meaning has shifted without the underlying data being updated? Are there event types that were deprecated, renamed, or never reliably populated?
The data won't be perfect. What matters is whether its inconsistencies are known and bounded. A model trained on five years of data absorbs every schema change and undocumented convention. If you don't know them, some of its behaviour will be hard to explain.
3. Can you link records across the systems the AI will need to use?
Most useful AI applications require joining signals from more than one source. Recommending next actions requires linking user behaviour to account status. Detecting anomalies requires linking operational data to historical baselines. Summarising customer context requires linking CRM records to support history.
Joining these signals on a consistent key is not a given. Many companies discover their entity resolution problem only when a project depends on it.
4. Is there a team who can own the data pipeline, or only the model?
Production AI is as much a data engineering problem as a machine learning one. The model is one component. Collection, transformation, validation, and monitoring keep it running.
If only the model team has capacity, the resourcing gap will become a reliability problem. The team needs to maintain the data infrastructure as well as build the feature.
What to do with the answers
If these questions reveal gaps, don't abandon the initiative. Fix the sequence.
Understand the data landscape first. Fix the critical gaps, such as entity resolution, schema documentation, and access controls. Then build the AI layer. Planning takes longer; delivery usually doesn't.
Starting with the model isn't faster. It moves the same work into the project, where it becomes unplanned and urgent.
I've seen both. Data work is less exciting to pitch and more reliable to deliver.
If you're assessing data readiness, I'm happy to compare notes.
The Technology Decisions page covers related build-versus-buy and platform questions.