A team gets excited about an AI assistant for sales forecasts or customer support, and a few weeks later the pilot produces answers nobody trusts. The model is rarely the cause. More often the data feeding it is incomplete, duplicated, out of date or nobody knows who is allowed to use it.
This article is about tables and system exports: CRM records, order lists, ticket histories, spreadsheets that people keep by hand. If your material is mostly documents and policies, see how to prepare company documents for an AI agent. For the wider picture of why data blocks projects, read data readiness and why it kills AI projects. Here you get a short routine that one person with access to the data can finish in about a week.
Start with one dataset and one question
"Is our data ready?" has no answer. "Is the last two years of support tickets ready to help an assistant suggest replies?" does. Before any check, write down the use case in one sentence and name the one or two datasets it would depend on. Everything below applies to those only.
Then take a sample: a few hundred rows chosen at random, plus the most recent month. Checking a sample is enough to see the pattern, and it keeps the week realistic.
Check 1: Completeness
For each field the use case needs, count how many rows are empty or hold a placeholder such as "n/a", "-" or "unknown". Express it as a percentage per field.
A field that is empty in a fifth of the rows is a real problem if the assistant relies on it, and irrelevant if it does not. This is why the use case comes first. Agree in advance on a threshold, for example "no more than 5% empty in fields the use case depends on", so that the result is not argued about afterwards.
Check 2: Duplicates
Look for the same customer, product or order recorded more than once. Exact copies are easy to find with a sort or a pivot table. The harder ones differ in spelling: "Acme Ltd", "ACME Limited" and "Acme, Ltd." are one company.
Take the sample, pick twenty records at random and search for each one by name and by email or tax number. Count how many have a second entry. If that is above your threshold, an AI tool will treat one customer as several, and its summaries and counts will be wrong in ways that are hard to notice.
Check 3: Ownership
For each dataset, write down one name: the person who knows what the fields mean, decides who may use the data and fixes it when it is wrong. This is not a technical check, and it is the one that most often fails.
If nobody can be named, or two departments each think the other owns it, stop here. Without an owner, nobody can answer the questions that always come up during a pilot: what does this status mean, why do these two columns disagree, can we use this field at all. An owner can be assigned in an afternoon, so treat this as a fix-first item rather than a hopeless one.
Check 4: Freshness
Find out when each dataset was last updated, and how it gets updated: by a system automatically, by people typing, or by an export someone runs when they remember. Then compare the most recent month in your sample with what you know happened. If three large deals closed last month and only one is in the data, you have a freshness problem.
Write down the lag in days. A weekly forecast built on a table that is six weeks behind is not a forecast. Also note whether old records are corrected when things change, or only added to.
Check 5: Sensitive fields
Go through the column headers and a few sample rows, and mark every field that holds personal data, health information, payment details, credentials or confidential contract terms. Free-text fields deserve special attention, because people paste all kinds of things into notes and comments.
For each marked field, ask three questions: do we need it for this use case, are we allowed to send it to the tool we plan to use, and can we remove or mask it first? Your legal or data protection contact should answer the second question, not the project team. If sensitive fields appear that nobody expected, treat it as a reason to stop and clarify before continuing.
A worked example of the result
The numbers below are invented to show how a result can look. They do not describe a real client.
A team wants an assistant that suggests replies to customer emails, using 18 months of ticket history. A sample of 300 tickets gives this:
| Check | Result | Threshold | Verdict |
|---|---|---|---|
| Completeness | 4% of tickets lack a resolution text | 5% | Pass |
| Duplicates | 3 of 20 customers have a second record | 10% | Pass |
| Ownership | Support lead owns it, confirmed in writing | named person | Pass |
| Freshness | Export is 9 days behind | 7 days | Fix first |
| Sensitive fields | Notes contain phone numbers and card fragments | none unexplained | Fix first |
Verdict: not yet a go. The two fixes are small - schedule a daily export and mask the notes field - and the team sets a re-check in three weeks. Nobody had to guess, and the decision fits on a page.
Turn the results into a decision
Use three outcomes only:
- Go. All checks pass or the failures do not touch fields the use case needs. Start a small pilot.
- Fix first. One or two checks fail and the fix is clear, with an owner and a date. Re-run only the failed checks afterwards.
- No-go for now. There is no owner, the data is mostly missing, or sensitive content cannot be handled. Pick a different dataset or use case instead of forcing this one.
Put the numbers, the decision and a re-check date on one page, and share it with whoever sponsors the pilot.
Common mistakes
- Checking everything. A company-wide data audit takes months and answers no question. Check the data for one use case.
- Cleaning before measuring. Count the problems first, otherwise you cannot tell whether the cleaning helped.
- Leaving sensitive fields to the end. They can change which tool you may use, so check them before you commit to a vendor.
- Treating it as an IT task. The people who use the data every day know which columns lie. Include them.
- Assuming one pass is enough. Data decays; plan to repeat the checks when the pilot moves toward production.
What to do this week
Choose one use case and one dataset. On Monday, write the use case and the thresholds. From Tuesday to Thursday, run the five checks on a sample. On Friday, write the one-page result with a go, fix-first or no-go and a date for the next look. If you want a view of the whole business case, how to measure AI return on investment pairs well with this routine.
Sources
- Our related articles linked above.
- The worked example is invented to show the method and does not describe a real client, dataset or result.
