Benefits of a Data Readiness Check Before AI Kickoff

The most expensive sentence in an AI project is "the data is in good shape, I think." A data readiness check replaces it with one week of looking at real records before anyone signs a scope. For a project manager, it is one of the cheapest risk reductions you can put on the plan.

Gartner's February 2025 press release predicted that through 2026, organizations will abandon 60% of AI projects that aren't supported by AI-ready data. That is a forecast, not a measurement, but it matches what delivery teams keep reporting: the model is rarely the part that slips.

What a one-week data readiness check covers

Pull about 200 random records from the real source system, not the tidy export someone emailed you for the demo. Then answer five questions: which fields are missing, how many duplicates exist, how stale the records are, how the project will actually get access, and who owns the data.

The first three are a query. The last two are conversations.

-- 1. Sample 200 rows and count the gaps
WITH sample AS (
  SELECT *
  FROM support_tickets
  ORDER BY random()
  LIMIT 200
)
SELECT
  count(*)                                                          AS rows_sampled,
  count(*) FILTER (WHERE customer_id IS NULL)                       AS missing_customer_id,
  count(*) FILTER (WHERE resolution_text IS NULL
                      OR btrim(resolution_text) = '')               AS missing_resolution,
  count(*) FILTER (WHERE updated_at < now() - interval '12 months') AS older_than_12_months,
  min(updated_at)                                                   AS oldest_record,
  max(updated_at)                                                   AS newest_record
FROM sample;

-- 2. Count duplicated keys across the full table
SELECT count(*) AS duplicated_keys
FROM (
  SELECT lower(btrim(ticket_ref))
  FROM support_tickets
  GROUP BY 1
  HAVING count(*) > 1
) AS d;

This is PostgreSQL syntax, so adjust FILTER and random() for your warehouse and swap in your own table and column names. The first query samples 200 rows and counts gaps and old records. The second scans the full table, because duplicates rarely show up in a small random sample. On a very large table, TABLESAMPLE is cheaper than ORDER BY random().

Put the results on one page, next to two names: who can grant read access, and who can explain what the columns mean. That page belongs in your AI project kickoff checklist.

Benefits of an AI data readiness check

1. Estimates come from evidence, not optimism. Say 60 of your 200 sampled tickets have an empty resolution field, and the use case depends on that field. Now you can budget for cleanup, find another source or cut the feature, all before you promise a date.

2. Access gaps surface in week one. Data that "lives in the CRM" may sit behind a VPN, a security review or an export job owned by another team. Discovering that before kickoff costs you a calendar entry. Discovering it in sprint three costs you the sprint. Approvals run on other people's timelines, so start the clock early.

3. The first scope shrinks to what the data supports. Sampling often shows that one region, product line or time window is clean while the rest is a mess. Scope the pilot to the clean slice and park the rest in a later phase, with the sample attached as the reason.

4. Staleness is caught before anyone builds on it. A knowledge base whose newest article is a year and a half old will produce confident, outdated answers. The oldest_record and newest_record columns above take seconds to read and save a retrieval build on content nobody maintains.

5. Sponsor conversations get shorter. "Data quality is a risk" is an opinion people argue about. "30% of sampled records lack the field we need, and Dana's team owns the fix" is a number with a name next to it. It also becomes the baseline you compare against after cleanup.

This is a lightweight data quality assessment, not a governance program. You are looking for the big problems, not certifying the warehouse.

When a data readiness check is not worth it

Skip the full week when the pilot is prompt-only and runs on data the team already owns and uses daily. If the people building it open those records every morning, a 30-minute skim covers it.

Also know what 200 records can't tell you. A defect hitting 1 in 100 records shows up in a sample of 200 about 87 times out of 100, but a 1 in 1,000 defect will usually slip past. The check finds the common problems, so don't read a clean sample as proof the data is clean.

Run it the week before kickoff

Do the sample, make the two calls, write the one-page result, and let it set the scope. A model can only be as dependable in production as the records behind it, and the week before kickoff is the cheapest time to find out what those records look like.