Five signs your data platform is not ready for AI

Why data, not the model

Most AI initiatives that stall do not fail on the model. They fail on data that nobody owns, nobody trusts or nobody is allowed to use. In a Gartner survey of 1,203 data-management leaders, 63% said their organization does not have, or is unsure whether it has, the right data management practices for AI. Gartner predicts that through 2026, organizations will abandon 60% of AI projects that are not supported by AI-ready data (Gartner, February 2025).

The good news is that the warning signs show up long before the first prompt. They are visible in everyday reporting, in access requests and in how incidents are handled. If you recognize three or more of the five signs below in the data your AI use case depends on, fix them first. A better model will not compensate.

The five signs at a glance

1. Two teams report different numbers for the same thing

If finance and operations disagree on a basic figure, such as monthly active merchants or transaction volume, the problem is rarely arithmetic. They are using different definitions, sources or cut-offs, and nobody has decided which one is right.

An AI system grounded on that data inherits the disagreement. Ask it the same question in two ways and it may give both answers, each correctly sourced. The users conclude that the AI is unreliable, when in fact the data is.

What fixes it: a short glossary for the metrics the use case depends on, each with one definition, one source and one owner, published where people and systems can find it. A business catalog such as Amazon DataZone, or simply well-described tables in the AWS Glue Data Catalog, makes those definitions part of the data rather than a document nobody reads.

A simple first check, if both teams' data sits in the same warehouse: count the same thing both ways and look at the gap.

-- Active customers last month, by two definitions
SELECT
  (SELECT COUNT(DISTINCT customer_id) FROM billing.invoices
    WHERE invoice_date >= DATE '2026-10-01' AND invoice_date < DATE '2026-11-01') AS billed_customers,
  (SELECT COUNT(DISTINCT customer_id) FROM product.events
    WHERE event_time >= TIMESTAMP '2026-10-01 00:00:00' AND event_time < TIMESTAMP '2026-11-01 00:00:00') AS active_users;

A gap is normal. Not being able to explain the gap is the warning sign.

2. Nobody can name the owner of a critical dataset

Ownership decides who fixes quality problems, who approves access and who answers when something looks wrong. Without it, every issue becomes a meeting, and the meeting ends without a decision.

For AI, ownership matters even more. Someone has to approve that a dataset may be used to ground answers, decide what may be shown to which users, and accept responsibility when a source changes.

What fixes it: one named owner per dataset the use case needs, usually in the business team that produces the data, with an engineering counterpart who runs the pipeline. Write both names on the dataset itself, in the catalog, and give the owner a short list of decisions that are theirs.

3. Access is granted by exception

When people get data through one-off requests, shared accounts or extracts copied to laptops, nobody can say who saw what. For an AI use case touching customer or transaction data, that is a blocker. Security and compliance reviews stall, or the project quietly works around controls that were never there.

What fixes it: access granted by role and purpose, not by person and favor. On AWS, AWS Lake Formation can grant table, column and row permissions to roles, so the AI application gets exactly the data it needs and nothing else. Sensitive fields such as card numbers should not be needed at all; references and tokens are almost always enough.

4. Nobody has written down what "correct" means

An AI use case needs a definition of a good answer and a set of examples to test against. If that definition does not exist for the underlying data, such as when a transaction counts as settled or which address is the right one, it will not exist for the AI either.

This is the sign teams most often skip, because it feels like a business question rather than a technical one. It is both. Without it, there is no evaluation set, no way to compare versions and no objective way to decide whether the system is ready for production.

What fixes it: twenty to fifty real examples with the right answer, agreed by the people who do the work today. That small set becomes the first evaluation set, and the disagreements it uncovers are usually the most valuable output of the exercise.

5. Data arrives late, partial or silently broken

Pipelines without tests, contracts or alerts fail quietly. A job that loads half a file succeeds as far as the scheduler is concerned. An assistant that answers from yesterday's partial load is worse than no assistant, because its answers look complete.

What fixes it: data contracts for each source the use case depends on, checks for completeness and freshness inside the pipeline, for example with AWS Glue Data Quality rules, and alerts that reach the owner before the users notice. Make freshness visible to the AI system too, so it can say "data as of" with every answer.

What "ready" means depends on the use case

The five signs apply to every AI use case, but their weight changes with what the system does.

This is why a readiness assessment always starts from a use case. "Is our data ready for AI?" has no useful answer; "is our data ready for this assistant?" does.

Common objections

"Our data is good enough for reporting, so it is good enough for AI." Reports are read by people who know the caveats. An AI system answers questions nobody anticipated, from data whose caveats it cannot see. Data that is fine for a monthly dashboard can be misleading at the level of a single transaction.

"The model will handle messy data." Models are good at reading messy text. They are not good at knowing which of two conflicting figures is right, or that a file is missing half its rows. Those are data problems, and they become confident wrong answers.

"We will fix the data after the pilot." After a pilot, the pressure is to scale, not to go back. Fixing the data for one use case before the pilot is cheaper than fixing it for a system that is already in use.

Score yourself in ten minutes

For the data one specific use case needs, score each statement 0 (not true), 1 (partly true) or 2 (true).

A total of 8 to 10 means the data is unlikely to be what stops you. Between 4 and 7, fix the weakest areas for this use case before building. Below 4, start with the data work; the AI use case is a good reason to do it, not a reason to skip it. For a broader view across architecture, cost and operations, take our 10-question readiness check.

What to do about it: one use case at a time

Do not try to fix the whole data estate. That is a multi-year program that rarely finishes. Pick one use case that has a sponsor and a measurable outcome, then fix ownership, access, quality and the definition of correct for the data that use case needs.

1. Choose the use case and name its sponsor, its users and the decision it supports.
2. List the data it needs, source by source, and score each one with the table above.
3. Name owners for each dataset and agree the definitions of the key metrics.
4. Set up access by role for the AI application and its users.
5. Add contracts and freshness checks to the pipelines that feed it.
6. Build the first evaluation set from real examples.

That is a project you can finish in weeks, not years, and it leaves a pattern the next use case can follow. Our article Your AI project is a data project with a model attached looks at the same questions from the project side.

Questions we hear