Why AI projects stall on data, and a checklist to run first

Why AI projects stall on data

A prototype usually works. Someone exports a file, cleans it by hand, and shows a model doing something useful. The stall comes later, when the project needs that data every day, complete, current and with permission, and finds that the export was a favour from one analyst.

The causes are ordinary. Nobody owns the data. Access takes months. The same customer appears under several identifiers. The data arrives a day after the decision it was meant to inform. None of this is a modelling problem, and no model fixes it.

The seven checks below cover ownership, access, quality, freshness, lineage, pipelines and privacy. Run them against one use case at a time. They tell you if you are ready to build or need to repair first.

Ownership and access

For every source the project needs, name one person who can explain what the fields mean and who can approve the use of the data. If no one will take that role, treat the source as unavailable until someone does.

Then test access for real. Ask for a service account that a pipeline can use, with the right scope, in the environment where the model will run. An analyst's personal login to a reporting screen does not count. Record how long the request takes, because that delay will repeat for every new source.

• A named owner for each source
• A written definition for each key field
• Machine access granted to a service identity
• A known approval path for new uses

Quality and freshness

Profile the data against the use case, field by field. Check how often each field is filled, how many records are duplicated, if codes follow the reference list, and if the same thing is recorded the same way across systems. For anything a model will learn from, check the labels. The outcome recorded in a system is sometimes what a person typed to close a ticket, and it may differ from what happened.

Freshness is a separate question. Work out when the decision is made and what the data looked like at that moment. If a model scores an application at submission, it may use only what was known at submission. Training on fields that were filled in later gives excellent test results and a system that fails in use.

• Completeness per field
• Duplicates and conflicting identifiers
• Reliability of labels and outcomes
• Delay between an event and its arrival in the data
• Fields truly available at the moment of decision

Lineage and pipelines

Lineage means you can trace a value from the model's input back to the system where it was first recorded, through every transformation. You need it the first time someone asks why the model gave an answer, and every time a source system changes a field.

Pipelines turn the one-off export into something that runs. A production pipeline is scheduled or triggered by events, tested, monitored and owned. It fails loudly, with an alert to a person, and it can be rerun without creating duplicates. It checks incoming data against expectations and stops when a source changes shape. If your current flow depends on someone remembering to run a script, plan to build the pipeline before the model.

• Each input traceable to its source system
• Transformations kept in version control
• Scheduled, monitored runs with alerts
• Safe reruns after a failure
• Checks on incoming data

Check where the data is collected

Sometimes the right fix is to collect data earlier in the process. For an international payment gateway, we built a backend data system for high-frequency data across countries and a data collection pipeline for disputes. In that engagement, dispute handling moved from the settlement deadline, 90 days out, to the moment a dispute is raised.

The general point holds for any AI use case. Look at the step in the process where each piece of data is captured. If it is captured late, on paper, or in a free-text note, everything built on it inherits that limit. Changing the capture point is often ordinary engineering work, and it can matter more than the choice of model.

Privacy boundaries

Decide what the project may use before anyone builds. List the personal and sensitive fields in each source, the purpose they were collected for, and whether this new use fits that purpose. Decide which fields are masked or dropped before data reaches a development environment, where the data may be stored and processed, and whether any of it may be sent to a model hosted outside your own systems.

Bring your privacy and compliance people in at this stage, with the field list in hand. A specific list gets a specific answer. A general request to use customer data for AI gets a refusal or a long wait.

• Sensitive fields identified in each source
• Original purpose checked against the new use
• Masking rules for non-production environments
• Clear rules on external model services
• Retention and deletion agreed

How to read the results

Mark each of the seven areas as ready, fixable within the project, or blocking. A use case with one or two fixable gaps is a normal project: put the data work in the plan, with its own budget and owner. A use case with a blocking gap, such as no owner or no permitted access, should wait. Let a different use case with better data go first.

Be wary of plans to fix all the company's data before any AI work starts. Programmes like that tend to run on without a finish line. Fix the data that one use case needs, build its pipeline properly, and the next use case that shares those sources starts from a better place.

What to do next

Pick one AI use case and run the seven checks against it. Write the result on one page: ready, fixable or blocking for each. If you are still choosing a use case, our free AI readiness report can help: answer six questions and the team sends a written report within one business day.