HomeBlogCase Studies
Case Studies

Why most AI projects fail on data and the four-week plan to avoid being one of them

On the AI projects we took over after a failure, the model was almost never at fault. The data was: incomplete, contradictory, without an owner, without history. Here is what we find every time, and the four-week method we apply before talking about algorithms.

Sylvie Wendkuni NITIEMA
Sylvie Wendkuni NITIEMAFounder & Data Scientist, DataSAI
Published 31 August 2026 10 min read - reads - comments
Why most AI projects fail on data and the four-week plan to avoid being one of them
An AI project is worth what its data is worth. Everything else can be bought.
Table of contents
The essentials in 30 seconds
  • In the AI projects we take over, the model is rarely the problem. The data is, in the vast majority of cases.
  • Four defects recur: data that cannot be found, data that contradicts itself across systems, no owner, no history.
  • Four weeks are enough to know whether a project is feasible, and at what cost, before committing a budget.
  • The deliverable that matters is a table of sources with, for each, an owner, a quality level and a decision.

What we find when we arrive

The scenario repeats. A company launched an ambitious AI project, often with a competent contractor. The prototype worked on a curated sample. Then, at the moment of scaling, everything seized up: production data does not look like the sample, two systems give different figures for the same customer, nobody knows who is allowed to correct a value, and the history needed to train or evaluate only goes back six months.

The project is then paused "while we clean the data", which, without a method, never ends. It is not fate; the order of operations was wrong.

4 in 5
of the AI projects we took over were failing on data, not on the model
4 weeks
to establish a reliable readiness diagnosis
× 3
typical cost gap between a prepared project and one that discovers its data along the way

The four defects that kill a project

Data that cannot be found

It exists, somewhere: in a monthly export on a shared drive, in an old application nobody opens any more, in the emails of someone who left last year. The project needs regular, reliable access, not a treasure hunt.

Contradictory data

The CRM counts 4,200 active customers, billing counts 3,800, the marketing tool 5,100. Each is right by its own definition. Until the company decides which one is authoritative, no model can learn anything consistent.

No owner

When a value is wrong, who fixes it? If the answer is "IT" or "nobody", quality will never improve. Every data source needs a named business owner who answers for its quality.

No history

Forecasting sales requires years of sales. Detecting anomalies requires examples of anomalies. If the history does not exist or was overwritten at each update, the project must start by collecting, and that takes the time it takes.

The question to ask before any project

"Show me last month's real data, as it is, without cleaning." What you see in ten minutes is worth more than thirty pages of scoping.

The four-week plan

WeekGoalDeliverable
1Inventory of the sources the use case needsList of sources, access, frequency, volume
2Quality measurement on real dataEmpty fields, duplicates, inconsistencies, depth of history
3Owners and definitionsOne name per source, one arbitrated definition per indicator
4DecisionFeasible now, feasible after (costed) remediation, or to be postponed

The final deliverable fits on one page: a table of sources with an owner, a quality level (good, acceptable, blocking) and a decision. A board can read it in five minutes and decide. That document is what almost every project we take over is missing.

What governance really changes

Data and business teams working on data quality
Data quality is a business matter, not only a technical one.

The word "governance" scares people, rightly when it means a committee and a binder. What we put in place is simpler: one owner per source, one definition per indicator, an automatic quality check that raises an alert when a threshold is crossed, and a thirty-minute monthly review. This light setup does more for an AI project than any choice of model.

"You do not clean data for a project. You organise the company so that data stays clean."

Conclusion

AI projects do not fail because AI is immature. They fail because they started from the end. Four weeks of inventory, measurement and arbitration before any development avoid months of drifting and make it possible to say, with figures, whether a project is reasonable. It is less spectacular than a demo, and it is what separates projects that deliver from projects that are forgotten.

FAQ

Do we need a data warehouse before doing AI?

Not necessarily. For a first bounded use case, clean access to two or three sources is enough. The warehouse becomes useful when several projects share the same data.

Who should own a data source?

The business person who depends on it most and has the authority to get an error fixed. Rarely IT, which hosts the data but does not know its meaning.

How much does remediation cost?

It depends on the defect. Deduplicating a customer file takes a few days; reconstructing three years of history may be impossible. That is exactly what the four-week diagnosis costs out.

Can we do generative AI without this work?

For an assistant over well-organised documents, yes, with modest expectations. For anything touching structured business data, no: the model will answer confidently from wrong data.

DataGovernanceQualityAI projectMethod
Sylvie Wendkuni NITIEMA
Sylvie Wendkuni NITIEMA
Founder & Data Scientist · DataSAI
Over ten years in AI and data consulting (Big 4, telecoms, finance). She helps companies deploy AI in production and leads the DataSAI Academy.
Take action

Data readiness audit in four weeks

Inventory, quality, owners, remediation plan: the foundation before any AI project, with a report your board can read.

Book a free session →