The sequencing sounds responsible. Finish the warehouse migration, then the governance program, then the master data cleanup, and only then start on AI. Each step is defensible on its own. The result, eighteen months later, is a platform built for workloads nobody validated and an organization that has learned nothing about how it will operate an AI system.
We do not run projects that way. We assess the data environment in week one and sequence the work so AI value lands early while the data foundation is built in parallel underneath it. That is not a shortcut around data quality. It is a different order of operations, and it works because of one property of AI use cases that the sequential plan ignores.
How much of your data does an AI use case actually need?
Far less than a platform program assumes. A single production use case consumes a narrow slice: a defined set of entities, a specific handful of fields on each one, at one freshness level, for a bounded population of users. A support triage agent might need ticket text, product, plan tier, and the last few interactions on the account. It does not need the finance mart, the attribution model, or years of archived history.
So the useful question at the start of a project is not whether the data platform is ready. It is four narrower questions. Which entities does this use case touch. Which fields does it read. How fresh do those fields need to be. Who is allowed to see them. Those can be answered in days. Whether a platform is ready cannot be answered at all, because readiness only exists relative to a workload, and until a workload is named there is nothing to be ready for.
What goes wrong when you sequence everything first
Three things, reliably.
- Requirements get guessed. With no real consumer, the platform team optimizes for coverage: a feature store nobody populates, a streaming layer for a use case that would have been fine on a fifteen minute batch, a catalog with entries for tables no model will ever read. Each one is defensible in a design review and none of them was pulled by a workload.
- The cost arrives long before any of the benefit. Budget and political capital both get spent on infrastructure whose value is entirely deferred, which puts the AI program in the position of justifying itself twice: once for the platform, and again later for the thing the platform was supposedly for.
- The operating muscle never develops. Evaluation sets, human review gates, drift monitoring, and incident response for a probabilistic system, the substance of managed AI operations, are not learned by building pipelines. They are learned by running something in front of users. A company that spends a year on data engineering arrives at its first AI deployment with the same operational inexperience it started with.
When does data work genuinely have to come first?
When a specific, testable blocker exists, not when the data is merely messy. There is a version of the parallel argument that goes too far, and shipping through a real blocker creates damage that is harder to undo than the delay would have been. The conditions that actually stop us:
- No access path. The data lives inside a vendor system with no export, no API, and no contractual right to extract it. Nothing downstream matters until that is solved.
- Two conflicting sources of record for the same entity, with no rule for which one wins. An AI system will find the disagreement and surface it, often to a customer, in a sentence written with total confidence.
- Regulated decisions with no lineage. If you cannot show where a field came from and how it was derived, you cannot defend an automated decision that used it. That is a prerequisite, not a phase two item.
- Sensitive data with no access controls. Retrieval systems are extremely good at finding the document that was never supposed to be shared. Permissions have to be enforced at the data layer before anything indexes it.
Notice what is not on that list. Inconsistent naming, missing values, undocumented columns, a half finished warehouse migration, three overlapping dashboards. Those are true almost everywhere and they are not a reason to defer.
What we do instead: two tracks and one dependency rule
We run two tracks concurrently. Track one delivers a narrow AI use case end to end. Track two builds the data foundation. The rule that keeps both honest is that track two only builds what a named consumer on track one needs next. No component gets built because a reference architecture has a box for it.
Week one is an audit and a choice. We map the sources, schemas, and pipelines that exist, identify the gaps and the highest leverage fixes, and name a candidate first use case against it. The audit output is not a maturity score. It is a list of what a specific candidate use case would need in order to run, and how far the current environment is from providing it.
The first build is a vertical slice: one path from the source system to a working output, using the real access path, the real permissions, and the real refresh cadence. Not an extract someone pulled onto a laptop. The point of the slice is that it forces every integration question to be answered once, in miniature, while the cost of being wrong is still small.
From there the fixes are requirements rather than guesses. Duplicate customer records stop being a tidiness complaint and become a funded deduplication task with an obvious payoff. Data arriving a day late for an agent the business needs answering in minutes gives the streaming work a named consumer and a specific latency target. Which components that produces, and in what order, is the subject of our guide to building an AI ready data platform. The point here is narrower: the workload names them, so nobody has to guess.
How to choose the first use case
Pick one where the data is reachable, the output is checkable, and a mistake is recoverable. In practice we look for four properties:
- The data it needs can be read today, even if it is ugly
- A person can look at the output and say whether it is right, which is what makes evaluation possible at all
- Errors are recoverable, so early imperfection is survivable
- Volume is high enough that an improvement is measurable rather than anecdotal
Data cleanliness is not on that list. Reachability is. An ugly field you can read is worth more than a clean field sitting behind a migration that has not happened yet.
The rules that keep parallel work from becoming debt
Most of the debt attributed to shipping early actually comes from four shortcuts, all of them avoidable.
- The prototype uses the production access path, or it is explicitly labeled disposable. The common failure is a demo pipeline that quietly becomes the production pipeline.
- Every field the use case consumes gets a contract: expected schema, acceptable null rate, freshness. That contract is what tells the foundation team what they are not allowed to break.
- Quality monitoring is instrumented in the first slice, not added after go live, because the first slice is where you learn which checks matter.
- Nothing gets a private copy of the data. Private copies are how two versions of the truth are born.
Sequencing is a decision made per use case, not once for the whole program. Some use cases have to wait for the data work. Most do not, and the ones that do not are how you fund and direct the data work that the rest of them will need. The plan that ships is the one where the foundation and the first AI system are built against each other, each telling the other what it actually needs.
