Are your AI projects stuck on your own data?

The pattern

A company runs an AI pilot and it works. A team saves hours, somebody sees a result worth showing the board. So far so good! The ambition increases.

But then the next AI project doesn’t work, and the culprit is the company’s own data. Forget about AI for a minute: the systems and the people can’t agree on what a customer is. Nothing about the first project depended on that answer. Everything about this one does.

This wall shows up the moment an AI project has to touch the numbers the business runs on, no matter the size of the company.

What it looks like from the inside

Six weeks into a job, the CMO pulled me aside about a customer data platform. She’d signed a six-figure annual license and was paying for it every month while getting nothing out of it. The tool sat right there, unusable.

Underneath it, the two main upstream systems disagreed with each other. The same customer carried a different ID in each one. Email addresses had drifted apart. Thousands of records sat in one system with no match in the other, and every one of those was supposed to be a customer. Status fields contradicted each other, so someone marked active in one place came back churned in the other. Neither system was more trustworthy than the other, and we couldn’t tell a lead from an active customer from a former one.

Nobody had done anything wrong. The definitions had never been written down. We had to fix it because the contract was signed and the license was already paid.

You have probably said one of these out loud

• “Two of our teams report different numbers, and both of them are right.”
• “We bought the licenses and we still can’t switch it on.”
• “We want to use AI here, but we keep being told the data isn’t ready.”
• “Nobody can tell me how many customers we actually have.”

None of these sound like an emergency, which is exactly why they survive long enough to stop an AI program.

A five-minute test

Ask your CFO and your head of sales, separately, how many customers you have.

A confident matching answer means the foundation is fine and your problem is somewhere else. Any hesitation, especially “well, it depends what you mean by,” is the thing. Two smart people giving different answers doesn’t mean one is wrong. It means nobody wrote the definition down, and every system since invented its own.

What the first piece of work looks like

Forty to a hundred hours. It ends in two things: a number you can defend, and a scoped plan for the gap between what you have and what the AI work needs.

This isn’t a rebuild, a dashboard, or a warehouse implementation. The point is to clearly define the benefits, costs, and risks involved in the decision to reconcile the foundational data. Plenty of companies find the gap is smaller than they feared, and the ones that don’t at least stop paying for licenses they can’t turn on.

Why this is worth doing now

Before the emergence of gen AI, fixing a data foundation was hard to justify because it was difficult to calculate an ROI. That’s changed. Most AI projects you want to run next read your own records, so trust in the foundation becomes the thing standing between you and the benefits. A trustworthy data foundation is more valuable than it’s ever been. The cost of finding out how hard it is to fix has dropped sharply too. Projects correctly declined three years ago would pass today because they are easier to scope and much more likely to yield a positive ROI.

If any of this sounds like your situation, the next step is a conversation rather than a proposal. Thirty minutes is enough to work out whether this is your problem or something else, and either answer is useful to you.