The data foundation
under your AI initiatives

Does the data foundation need to be in order before an organisation starts with AI?

A perfect data foundation isn't needed to start with AI: enough of a foundation for one use case is sufficient. The approach that works in practice starts with one use case that has clear value and an owner in the business, and fixes the definitions, lineage and quality only for that use case's own data sources. After three or four use cases, a foundation emerges that has grown from real use, smaller than the ideal picture and considerably more reliable.

Is a central data warehouse needed for the data foundation under a first AI use case?

Often not: for the data foundation under a first use case, a daily export is often enough. Accessibility and infrastructure are usually the least urgent data problem, and in practice often the easiest to solve, especially for one use case.

Are there situations where tackling the data foundation first is the right answer?

Yes. Delaying is wise with three signals around the data foundation: the core entity isn't clearly defined, the data you need isn't being captured, or the source has no owner. Those signals are about meaning and ownership, not technology.

How many terms are defined to tackle the definitions problem in the data foundation?

Five to ten: the approach to the definitions problem in the data foundation is to define only the terms that the use case touches, not the whole company data model. According to the article, that's two weeks of work instead of two years.

Source: article by Dave Willemstein. Updated: October 2026.

Two truths that contradict each other

The first: without reliable data, AI delivers unreliable outcomes. That's not in dispute.

The second: organisations that want their entire data landscape in order before they start with AI rarely get to AI at all. The data foundation is never finished, after all, and there's always another layer that should come first.

Both are true. The way out is in how you phrase the question. "Is our data in order?" is a question you can't answer. "Is this data good enough to base this specific decision on?" you can answer, within a week.

What actually matters

When I run data scans ahead of AI projects, I come across four problems. They're not equally serious and they don't need the same fix.

Problem 1: Definitions (serious, often underestimated)

Four systems, three definitions of "customer". Two departments that calculate "revenue" differently. A product code that's a variant in one system and a separate product in another. This is by far the most common problem, and the most underestimated.

It's serious because no amount of technology fixes it. A model trained on inconsistently defined data learns that inconsistency too. And it's underestimated because everyone works consistently within their own department. The problem is only visible once you look across departments.

Approach: define only the five to ten terms that your use case touches. Not the whole company data model. That's two weeks of work instead of two years.

Problem 2: Lineage and traceability (serious for regulated work)

Can you trace a number in a report back to where it came from and what's been done to it? For AI applications that influence decisions, this isn't a luxury. Regulators, auditors and eventually your own board will ask that question.

Approach: map the lineage for the data flows your use case actually uses. Document the transformations. That doesn't need an expensive tool: a readable document that's accurate is worth more than a lineage tool nobody maintains.

Problem 3: Quality and completeness (manageable)

Missing fields, inconsistent entry, historical data that changed format halfway through. Annoying, but this is the type of problem technology actually helps with, and one you can quantify.

Approach: measure it. What percentage of records has the field you need? If it's 94%, you can get moving, and the question becomes what to do with the remaining 6%. If it's 40%, you're having a different conversation.

Problem 4: Accessibility and infrastructure (usually the least urgent)

No central data warehouse, data spread across systems, no APIs. This feels like the biggest problem because it's the most visible, and because suppliers are happy to sell you a platform for it. In practice, it's often the easiest to solve, especially for one use case.

Approach: for a first use case, a daily export is often enough. Don't build a platform to test a hypothesis.

The use-case-led order

The approach that works in practice reverses the order. You don't build the foundation upfront, you pull it along with your first applications.

• Step 1: Choose one use case with clear value and an owner in the business.
• Step 2: Map which data that use case actually needs: usually three to seven sources, not thirty.
• Step 3: Fix the definitions, lineage and quality for those sources only. Do this properly, because it becomes your reference.
• Step 4: Build the use case and measure whether it works.
• Step 5: Choose the next use case that reuses as many of the same sources as possible.

After three or four use cases, you have a foundation that's grown out of real use. It's smaller than the ideal picture, and considerably more reliable, because every component is tested in production.

When "data first" is the right answer

There are situations where delaying really is wise. Three signals:

• The core entity isn't clearly defined. If you can't pin down who counts as a customer, or what counts as one order, that affects every use case. Fixing this first saves you rework on everything that follows.
• The data you need isn't being captured. No amount of clever technology creates data that doesn't exist. The first step then is a change to how you record things, and that takes time.
• There's no owner for the source. If nobody is responsible for a dataset, it won't be maintained either, and your application will quietly degrade within six months.

Notice that none of these three is about technology or a missing platform. All three are about meaning and ownership. That's what the data foundation is really about. The rest is infrastructure, and infrastructure you can buy.

A half-day test

Want to know where you stand? Take one concrete decision you want AI to support, and try to reconstruct it by hand for ten past cases. If that takes an afternoon, your foundation is good enough. If it takes two weeks and you have to call three departments, you know exactly which part to fix first. And it's almost never the part the platform proposal was about.