Most AI projects that fail do not fail because the model was wrong. They fail because the data could never have supported the model, and nobody checked before the budget was approved.
This is the assessment worth doing first. It takes an afternoon and it costs nothing.
Question 1: does the data exist at all?
Write down the specific decision you want the system to make, then ask what information a competent human would need to make it.
Then find out whether that information is recorded anywhere. Not whether it could be. Whether it is, today, in a system you can query.
Common gaps we find:
- Predicting machine failure, but maintenance is recorded in a paper register
- Forecasting demand, but stock outs were never recorded, so the data shows zero sales rather than unmet demand
- Scoring credit risk, but defaults were resolved informally and never flagged in the system
- Routing support tickets, but the historical category field was optional and mostly empty
That second one is worth dwelling on: a demand forecast trained on sales data alone learns what you sold, not what customers wanted, and it will quietly reproduce your stock outs. See demand forecasting for retail.
Question 2: do you have outcomes, not just inputs?
For anything predictive, you need to know what actually happened. Which customers churned, which invoices went unpaid, which machines failed, which leads converted.
Businesses very often have the inputs and not the outcomes, because the outcome was handled by a person and never written back to the record. Without labelled outcomes there is nothing to learn from.
Question 3: how much, and over how long?
Rough guidance, not rules:
- Classification with clear categories: a few hundred examples per category to begin, thousands to be reliable.
- Forecasting anything seasonal: at least two full years, ideally three, because one year cannot separate seasonality from trend.
- Rare events such as fraud or equipment failure: enough history to contain a meaningful number of the events themselves. A year with three failures is not a dataset.
If you have six months of data and want a seasonal forecast, the honest answer is to wait and collect, while using a simple method in the meantime.
Question 4: is it consistent enough to use?
Run these checks on an export of your actual data:
- Duplicates. How many customers appear more than once under slightly different names?
- Missing values. Which important fields are empty, and for what share of rows?
- Free text where categories belong. Count the distinct spellings of your top ten cities or suppliers. If there are forty, that field cannot be used until it is cleaned.
- Date consistency. Mixed formats, impossible dates, and whether timestamps have a timezone.
- Silent definition changes. Did the meaning of a status field change when you upgraded the system in 2023? This one is invisible and it poisons models.
The city field test is the fastest single indicator of whether a business’s data is usable. It takes one query.
Question 5: can you get at it?
- Is it in a database you can query, or locked inside a vendor system with no export?
- Does export include history, or only current state?
- Is it spread across four systems that do not share a customer identifier?
That last point is the most common practical blocker in mid sized businesses. If your CRM, your accounting system and your support desk each have their own idea of who a customer is, joining them is the project, and it is usually worth doing regardless of AI.
Question 6: what happens when the answer is wrong?
Every model is wrong some of the time. Before building, write down the consequence.
- Low stakes and reversible: a poor product recommendation. Automate freely.
- Moderate: a misrouted support ticket. Automate with an easy correction path.
- High: a declined loan, a blocked transaction, a flagged job applicant. Human review required. See AI in recruitment screening.
The scoring
Count how many of the six you can answer confidently.
- Five or six: you are ready. Commission a small scoped pilot on one use case.
- Three or four: fixable within a quarter. Usually the gap is outcomes not being recorded, or systems not being joined. Fix that first.
- Two or fewer: the right project is not AI. It is recording the data properly, which improves the business immediately and makes AI possible in a year.
There is no shame in the third answer. It is the most common one, and businesses that accept it save a great deal of money.
Related reading: where AI genuinely absorbs operational work and what running an AI feature costs.
Frequently asked questions
How much data do we need for AI?
It depends on the task, but two to three years for anything seasonal, and enough examples of the outcome you are predicting. Rare events need long history, not just large volume.
Can AI work with messy data?
Some messiness is tolerable and is handled during preparation. Inconsistent categories, missing outcomes and changed definitions are not, and cleaning them is the real first project.
What should we fix first?
Recording outcomes, and giving your systems a shared customer identifier. Both improve reporting immediately and are prerequisites for anything predictive.
Can we start small?
Yes, and you should. One use case, one dataset, a defined success measure, a fixed time box. A pilot that answers whether this is viable is worth more than a large programme built on assumptions.
Ezitech builds AI systems grounded in a business’s own data and will tell you plainly when the data is not ready yet. See our AI solutions or describe the decision you want to automate.