How do you know if your product has AI ready data?

01Why AI makes data problems louder

A report with a wrong number is annoying. An AI assistant that states the same wrong number in a fluent sentence is worse, because users trust it more. The model does not know that a vendor feed failed last night, that two records are the same person, or that a test import was never removed. It reads what is there.

Research backs this up. A Google study of practitioners in high stakes AI found that compounding data problems, which the authors call data cascades, were present in almost every project they examined. They also found that cascades are usually invisible and delayed but avoidable. An earlier Google paper on technical debt in machine learning systems names data dependencies as one of the main sources of long term cost. Neither problem is solved by a better model.

For a B2B product that depends on third party feeds, customer system integrations and imports, the practical test is simple: could you show a customer, record by record, where the answer came from? If not, the data is not ready.

02Treat every source as its own contract

The first step is an inventory. List every source that feeds the product, and for each one write down what you actually know about it, not what the integration document promised.

Treating each source as a contract changes how teams talk about failures. Instead of "the data is wrong", you can say "the vendor feed for this customer arrived four hours late and with half its rows", which is something you can fix.

03Build the pipeline before the prompt

Once the inventory exists, the work is mostly plumbing. It is not glamorous, but it decides whether the AI feature is trusted. We follow the same order on most projects:

1. 01

   Move every feed into scheduled jobs with logs, so each run records when it started, what it loaded and what it rejected.

2. 02

   Load incrementally where you can. Fetch only records newer than the last successful run instead of reloading and comparing everything.

3. 03

   Validate on the way in. Reject or quarantine records that fail type, range or required field checks, and keep the reason.

4. 04

   Match and de-duplicate, using a rule you can explain to a customer.

5. 05

   Attribute each record to its customer, location or tenant in the pipeline itself, not later in the application.

6. 06

   Reconcile numbers that come from several providers, and decide which provider wins when they disagree.

7. 07

   Expose quality to the people who own the data

   import logs, templates and clear error messages.

The last step is often skipped, and it is one of the most useful. When customers can see their own import logs and use a template that matches your format, many data problems are fixed at the source, by the people who understand them best.

04Make data quality visible inside the product

Data readiness is not a one time project. Feeds change, customers add new systems and providers change their limits. The product itself should show data health, both to your team and to customers:

• Import logs per customer, showing what loaded, what failed and why.
• Templates for manual imports, with the exact labels and ranges the pipeline expects.
• Freshness indicators, so a user can see when a source last updated.
• A way to flag a wrong record, stored for review rather than lost in a support ticket.

These features are useful long before any AI is added. Once an AI feature arrives, they also become the evidence you need when a customer asks why the assistant said what it said.

05What we see in production

On a multi-tenant dealership platform that turns website visitor data and dealer systems into follow ups, the data arrives from many outside sources. These are pixel and geo data vendors, lead feeds, dealer CRMs and dealer management systems, and inventory feeds, all on schedules we do not control. Every dealer group has its own locations, franchises and lead rules. Visitor data has to be matched, de-duplicated and attributed to the right dealership at scale, and communication statistics have to reconcile across several email and SMS providers.

We moved ingestion into scheduled workers and warehouse based pipelines, added each CRM and communication integration one provider at a time, and gave dealers data import templates and logs. The product has kept evolving in production for more than five years without a core rewrite. An AI chat assistant was later added as one feature on top of that data, not as a replacement for it.

On an analytics pipeline for a web3 messaging network, every run downloaded the previous snapshot, ran a full query, loaded everything into memory and compared it to find new rows. Memory use and run time grew with the data. We proposed an incremental design: start from the latest timestamp already in the destination, query only newer rows in batches, upload and confirm each batch, and log completion. Batching also covers the first sync and catch-up after a failed run, because the destination caps each upload at about 200 MB. The client approved the design.

The lesson carries over to AI work: a pipeline that knows where it left off is far easier to trust than one that rebuilds the world every time.

In the approved incremental sync, the destination itself is the record of progress, instead of the separate metadata table we first proposed. The job now reads only new rows every ten minutes, and the client later told us it was working great.

06Signs you do not have AI ready data yet

You can usually tell within a week of looking. Common signs:

• Dashboards that calculate the same metric in different ways.
• Duplicate customers or contacts that nobody can explain.
• Feeds that fail silently and are noticed by customers first.
• Manual imports with no template and no log.
• No record of which customer a row belongs to until the application joins it.

None of these need a model to fix. Fixing them first makes the model you add later look smarter, and it makes the answers defensible when a customer asks. We discuss how this connects to cost in how to reduce AI infrastructure cost in production.

Frequently asked questions