The pattern behind stalled AI projects
Most stalled AI initiatives fail on four questions nobody answered: who owns the data, how complete it is, who may access it, and what correct means. The model is rarely the problem. Today's foundation models are good enough for most business use cases; what they cannot do is fix the data they are given.
The pattern is easy to recognize. A prototype is built in a few weeks on a clean sample. It impresses in a demo. Then the team tries to connect it to real data, and the project slows to a crawl: access requests wait in a queue, the real data is messier than the sample, two teams disagree on what the right answer is, and nobody can say whether the system is good enough to launch.
The four questions
| Question | You have answered it when | Who usually answers it |
|---|---|---|
| Who owns the data? | Each dataset the use case needs has a named person who can fix it and approve its use | The business team that produces the data |
| How complete and timely is it? | You know the gaps and delays, and the pipeline checks for them | Data engineering, with the owner |
| Who may access it? | Access is granted by role, for this purpose, and logged | Security and compliance, with the owner |
| What does correct mean? | There is a written definition and a set of real examples experts agree on | The people who do the work today |
1. Who owns the data?
Someone who can fix it and approve its use. Without an owner, every quality problem becomes a discussion and every access request waits for someone willing to say yes. An AI project that depends on five datasets with no owners depends on five open-ended negotiations.
2. How complete and timely is it?
Gaps and delays that a person works around become wrong answers in a system. An experienced analyst knows that yesterday's settlement file arrives at ten, or that one region's records are always missing a field. An AI system does not, unless the pipeline tells it.
3. Who may access it?
For customer and transaction data, this is a control question before it is a technical one. If the answer is unclear, the project will stall in security review, which is the right outcome. Decide early which data the system needs, which it does not, and how access will be granted and logged.
4. What does correct mean?
Without a definition and examples, nobody can test the result. "The assistant should give the right reason for a payment exception" needs twenty to fifty real exceptions with the right reason agreed by the people who resolve them today. That set becomes the first evaluation set, and it is often the first time two teams discover they disagree.
An example from payments
Take an assistant that helps analysts handle chargeback disputes. On paper, it needs the transaction, the customer's history, the merchant's evidence and the card network's reason code. In practice:
- Transaction data lives in the ledger and the processor's files, with different identifiers.
- Merchant evidence arrives as attachments in a support tool nobody has integrated.
- Access to customer history requires approval from a team that has never been asked.
- Analysts disagree on when to accept a dispute rather than fight it.
None of those is a model problem. Each one is a decision with an owner. Once they are made, the assistant itself is the smaller part of the work.
Why it matters for how you start
Answer those questions for one use case and you have a production path. Skip them and you have a demo that impresses in a meeting and cannot be operated. That is why our AI work usually starts with a data readiness assessment, not with a model: two to four weeks to answer the four questions for one use case, score the data and plan the gaps. Our article Five signs your data platform is not ready for AI includes a ten-minute self-assessment, and the human approval guide covers what comes after.
A 30-day plan for one use case
The four questions can be answered quickly when they are answered for one use case at a time. A month is usually enough.
| Week | Focus | Output |
|---|---|---|
| 1 | Name the use case, the sponsor, the users and the decision it supports; list every dataset it needs | A one-page use case brief and a data inventory |
| 2 | Name an owner for each dataset; agree definitions for the key fields and metrics | Owners and definitions recorded in the catalog |
| 3 | Agree access by role for the system and its users; check completeness and freshness of each source | An access design approved by security, and a list of data gaps |
| 4 | Collect real examples of correct answers and score the data against them | The first evaluation set and a go, fix-first or stop decision |
The decision at the end of week 4 is the point. Sometimes it is "build", sometimes it is "fix two data sources first", and sometimes it is "this use case is not worth it". All three are good outcomes compared with discovering the same thing six months into a build.
Measure before you build
Write down how the work is done today before the AI system exists: how long a case takes, how often it is escalated, how often the answer turns out to be wrong. Without that baseline, nobody can say later whether the system helped. It also keeps the project honest about the size of the prize. If analysts spend ten minutes a day on the task, an assistant that saves half of it may not justify the effort.
Questions we hear
Can we build the prototype and fix the data in parallel?
Yes, as long as the prototype uses the real data, with its real gaps, as early as possible. A prototype on a clean sample hides exactly the problems that will stop it.
Which use case should we start with?
One with a sponsor, a measurable outcome, data you already mostly control, and actions that a person reviews. Internal operations work, such as exception handling or case summaries, usually fits better than anything customer-facing.
Do we need a data platform first?
You need reliable access to the data this use case needs. That can be a slice of a future platform, built for this use case and extended for the next one.