Data readiness is not a property of your whole organization. It is a property of the data needed for one specific use case. A company can have a messy data landscape and still be ready to build a document-processing assistant, and it can have a well-run warehouse and still not be ready for a demand forecast because the history it needs was never recorded.
So the practical question is not "is our data ready for AI?" but "is the data this use case needs ready, and if not, what would it take?"
The short answer
For a given use case, the data is ready enough to start when you can answer yes to five questions:
- Accessible: can the system reach the data through a reliable, approved route?
- Understood: does someone know what each field or document type means and where it comes from?
- Representative: does it reflect the real range of cases the system will face, including the difficult ones?
- Known quality: have you measured completeness and accuracy, even roughly?
- Permitted: are you allowed to use it for this purpose, in this environment?
"Ready enough" matters. Most useful projects start with gaps and close them as part of the work. The point of the assessment is to know the gaps in advance and plan for them.
Step 1: Start from the use case, not the data
List the decisions or tasks the system will support and trace back to the data each one needs. For example:
- A support assistant needs help articles, product documentation, and possibly past tickets and account details.
- A document-extraction workflow needs a representative set of incoming documents and the correct values for each.
- A forecasting model needs historical demand at the level decisions are made, plus the factors that influenced it, such as promotions or price changes.
This keeps the assessment focused. It also avoids the common trap of launching a broad data cleanup program before any value has been delivered.
Step 2: Check access
Access problems are the most frequent cause of delay in our experience, and they are usually organizational rather than technical.
- Where does the data live? Operational systems, a warehouse, shared drives, email, a vendor platform.
- How can it be read? A supported interface, a database replica, scheduled exports, or only through the application screens.
- Who approves access? Identify the system owner and the approval process early.
- What identity will the system use? Plan for a service identity with scoped permissions rather than a personal account.
- How fresh must it be? Real-time, daily or a one-off extract each lead to different pipelines.
Step 3: Understand what the data means
A column called status can mean five different things across five systems. Before building, confirm:
- Definitions of key fields, codes and document types.
- Lineage: where each value originates and what transforms it along the way.
- Known quirks: default values, fields reused for other purposes, historical changes in meaning.
- Owners: who to ask when something looks wrong.
For unstructured content such as documents and knowledge bases, the equivalent is knowing which collections are authoritative, which are drafts and which are out of date.
Step 4: Test representativeness
A model learns from, or retrieves from, what it is given. If the data only covers easy cases, the system will only handle easy cases well.
- Coverage. Does the sample include all the major document layouts, customer types, product lines or regions?
- Edge cases. Are the unusual but important cases present, such as the rare failure mode, the complex claim, the non-standard contract?
- Time. Does historical data cover enough cycles, such as seasons or product launches, to reflect how the work varies?
- Labels. For tasks that learn from examples, are the correct outcomes recorded, and were they recorded consistently?
Step 5: Measure quality, even roughly
You do not need a formal data quality program to start. A sample-based check is often enough to decide.
- Completeness: how often are required fields missing?
- Accuracy: in a sample checked by someone who knows the work, how often are values wrong?
- Consistency: do the same entities appear with different names or identifiers across systems?
- Duplication: how much repeated or near-duplicate content exists?
- Timeliness: how old is the data when it becomes available?
Record what you find. Those numbers become part of the baseline and help explain system behavior later.
Step 6: Confirm you are allowed to use it
Having access to data does not mean you are permitted to use it for a new purpose.
- Purpose and consent: does the original reason for collecting the data cover this use?
- Sensitive data: does it contain personal, health, financial or confidential business information that needs minimization or masking?
- Location and processing: can it be processed in the environment and region you plan to use, and by the model provider you plan to use?
- Contracts: do agreements with customers, suppliers or data vendors restrict how it is used?
- Retention: how long may copies, logs and indexes be kept?
Involve privacy, security and legal colleagues at this step rather than after the build.
A simple scoring approach
For each of the five dimensions, rate the use case as ready, workable with known effort, or blocked. Any blocked item needs a decision before building starts. Workable items become tasks in the project plan with an owner and an estimate. This keeps the conversation practical and avoids treating data readiness as an all-or-nothing verdict.
Common gaps and how teams close them
- Data only in application screens: build or request an extract, or use careful extraction as an interim step.
- No labeled examples: have domain experts label a few hundred representative cases as part of the project.
- Scattered, outdated documents: agree which collections are authoritative and retire the rest from the index.
- Inconsistent identifiers: build a matching step for the entities that matter to this use case, not the whole business.
Where to go next
If the assessment shows gaps in pipelines or data platforms, see Data Engineering. Once the data is in place, the pilot-to-production checklist covers the next steps.