TL;DR: Your data is ready for AI when it can answer one specific question: for the job you want automated, does a record exist that shows what happened, can it be pulled out reliably, and do the people who use it agree on what it means? You do not need a data lake, a cleanup program or years of history. You need one use case, a real sample of a few hundred records, and a person who knows the business reading them alongside an engineer. Most AI projects that disappoint were not let down by the model. They were let down by data that nobody looked at closely until the build had started.
"Is our data ready for AI?" is one of the most common questions buyers bring to a first call, and it is usually asked the wrong way round. It treats readiness as a property of the whole company, something to fix with a migration before any AI work can begin. In practice readiness only exists relative to a job. The same CRM can be perfectly ready for an assistant that drafts follow-up emails and completely unready for one that predicts which deals will close.
Start from the job, not the data
A data audit with no use case attached produces a long report and no decision. Every company has duplicates, empty fields and odd conventions. The useful question is whether those problems touch the job you care about.
So write the job down first, in one sentence, with its inputs and outputs. "When a supplier invoice arrives, enter it into accounting." "When a customer calls, book them into an open slot." "When a deal goes quiet for two weeks, draft a follow-up using what was discussed." Then list exactly which pieces of information a competent new employee would need to do that job well. That list, not your whole database, is what gets checked.
If you cannot write the sentence yet, the project is not blocked by data. It is blocked by scope, and adding AI to an existing product covers how to pick the job first.
Five questions that decide readiness
1. Is the answer actually in the data?
The most common gap is not dirty data but missing data. The thing that decides the outcome happened in a phone call, a hallway, or someone's head, and the system only recorded the result.
A sales team may log that a deal was lost but not why. A support team may close a ticket without noting what actually fixed it. An AI system cannot learn or reason from information that was never written down, and no amount of model quality changes that.
The test is simple: take twenty records and ask the person who did the work whether the record contains enough to explain what they decided. If they keep saying "well, you would have to know that...", the gap is in capture, not cleanup.
2. Can you get it out?
Data you own is not always data you can reach. Before anything else, find out how each source can be read by software:
- A documented API is the best case, but check rate limits and which fields it actually exposes. Plenty of SaaS tools show a field in their interface and leave it out of the API.
- Scheduled exports work for many jobs that do not need live data, as long as someone owns the export and notices when it breaks.
- Direct database access to an older internal system is often possible but needs care, since reading production tables can slow the system people are using.
- Screens and spreadsheets are the hardest case. If the only way to see the data is a person clicking through a legacy interface, the first project may be getting it out, which is covered in legacy system modernization.
This step is ordinary integration work, and on most AI builds it takes longer than anything involving the model.
3. Do people agree on what it means?
Fields drift. A "status" column that sales uses one way and operations uses another. An "active customer" that finance counts differently from marketing. A notes field where half the team writes summaries and the other half pastes whole email threads.
People work around this because they know who entered what. An AI system reads the field literally. We see this most clearly in financial data: on Fyuel, an accounting platform for the fuel trade, customers, suppliers, tankers, ledgers and banks only make sense together because every one of them has an agreed definition. Any AI feature on top of records like that inherits the definitions, good or bad.
The fix is unglamorous and fast: a one-page glossary for the fields the job depends on, agreed by the people who enter them.
4. Is it current, and does the past still apply?
Two different problems hide here.
Freshness. Some jobs depend on data that changes by the minute. An AI receptionist that books appointments, the kind we built behind CallGuard AI, is only as good as the calendar it reads. If availability lives in a system that syncs once an hour, the agent will offer slots that are already gone, however well it talks.
History that no longer applies. If your pricing, process or product changed last year, records from before the change may teach the wrong lesson. Older data is not automatically better data. Sometimes the right sample is the last six months only.
5. Are you allowed to use it this way?
Data collected for one purpose is not automatically available for another. Customer contracts, privacy notices and consent for recordings all limit what you can send to a model provider and what you can keep. The options and trade-offs are covered in adding AI to an existing product and AI feature security. The point for readiness is that this question gets answered before the build, by someone with the authority to answer it, not discovered during a customer's security review.
What you do not need
Buyers often assume AI needs far more data preparation than it does, which delays useful projects.
You do not need a data warehouse first. Most AI features read from operational systems directly. A warehouse is a separate project with its own payoff.
You do not need years of history. Most current AI features use a general-purpose model that already understands language, documents and conversation. What it needs from you is context at the moment of the task, which is the argument made in fine-tuning vs RAG vs prompting. Large labeled datasets matter mainly when you are training or fine-tuning a model, which most business projects should not start with.
You do not need all of it clean. You need the fields the job depends on to be reliable. Everything else can stay as messy as it is today.
You do need a sample. The one thing that cannot be skipped is a real set of past cases, including the awkward ones. That sample becomes the evaluation set the feature is judged against, which is the subject of evaluating AI features.
Sometimes the fix is upstream
When the readiness check finds that the data the job needs simply is not captured, the best AI project may start with changing how information comes in.
That is a recurring pattern in our own work. On Fortell AI, we build the voice and SMS systems that help Community Action Agencies handle intake in over 100 languages, so information arrives structured at the moment someone calls rather than as paperwork a person has to read and key in later. When you build the system of record yourself, as with Fyuel, data quality is a design decision from day one rather than a cleanup job years later.
Products that create their own data face the same question as a capture problem. LectureNotes AI, one of our own products, records lectures and turns them into takeaways and outlines, so what goes into the recording decides what can come out. If you expect to add AI to a new product later, deciding what to record now is far cheaper than reconstructing it. Product analytics for an MVP covers the same principle for usage data.
A data readiness check you can run in two weeks
This is roughly how we run the check at the start of an engagement. A capable internal team can do most of it without outside help.
- Write the job sentence and the list of information a competent person needs to do it.
- Map each piece to a source, and note how software can read it: API, export, database or nothing.
- Pull a real sample. A few hundred recent records is usually enough to see patterns. Include cases people remember as difficult.
- Read fifty of them together. One person who does the work, one engineer. Mark where the record is missing the reason, where fields are inconsistent, and where the answer lives outside the system.
- Write the glossary for the fields that matter, and get it agreed.
- Check freshness and rights. How current does the data need to be, and is this use allowed under your contracts and notices?
- Decide. Go as scoped, go with a smaller first version, fix capture first, or stop.
"Stop" is a legitimate outcome, and a cheap one compared with a build that cannot work. A smaller first version is the most common result, and the one most likely to show value quickly, as covered in measuring AI automation ROI.
Questions to ask a vendor about your data
- Which specific fields does this feature depend on? A vague answer means the data has not been looked at.
- Have you read a sample of our real records? Not a demo dataset. Yours.
- How current does the data need to be, and how will it stay that way?
- Where is our data sent and stored during processing?
- Who keeps the glossary, the sample and the pipelines afterwards? They are part of what you are paying for, as covered in software ownership and handover.
The bottom line
Data readiness is not a company-wide state you reach before AI work can begin. It is a short, specific check against one job: whether the answer is recorded, whether you can reach it, whether people agree what it means, whether it is current, and whether you may use it. Most companies are closer than they think for some jobs and further than they think for others, and two weeks of reading real records tells you which is which. We run that check before every AI build, and we build both sides of it, the AI systems behind CallGuard AI, CallSetter AI and Fortell AI, and the systems of record like Fyuel that make good data the default.
Not sure whether your data can support the AI project you have in mind? Book a demo and bring the job you want automated. We will tell you honestly what your data can support today and what would need to change first. See our work: CallGuard AI, Fortell AI, Fyuel and more.