Most enterprises write their AI strategy first and discover their data governance gaps second — usually during the first pilot, when someone asks “which system is the source of truth for this field” and nobody has a confident answer. The organizations that avoid this expensive rework do the opposite: they treat a basic data governance pass as the prerequisite for AI strategy, not a parallel workstream that can catch up later.

Why the common ordering fails

AI strategy documents are exciting to write and easy to present to a board — they describe a future state, a set of use cases, a roadmap. Data governance work is unglamorous and looks like a delay: data lineage documentation, ownership assignment, quality auditing, access control cleanup. Given the choice, most organizations sequence the exciting work first and treat governance as something to handle “in parallel” — which in practice means it gets handled reactively, the first time a model’s output looks wrong and someone has to trace back through three undocumented systems to find out why.

This ordering doesn’t just slow things down, it produces worse strategy. An AI roadmap built without first understanding what data is actually usable, how current it is, and who’s accountable for its accuracy is built on assumptions that frequently turn out wrong once a real pilot starts pulling from real systems. The roadmap gets revised anyway — the only question is whether that revision happens on a whiteboard before any engineering starts, or three months into a stalled pilot.

What a basic governance pass actually needs to answer

Four questions, answered honestly, before committing to a specific AI roadmap. What data exists that’s relevant to the planned use cases, and where does it actually live — not where the org chart says it should live, but where it’s actually stored and how current it is. Who owns each data source’s accuracy — a named person or team accountable for it being correct, not a system that nobody actively maintains. What’s the actual quality — missing fields, duplicate records, inconsistent formats — measured, not assumed, because “our data is pretty clean” is almost never true when someone actually checks. And who’s allowed to access and use each data source for a new AI use case, given existing privacy commitments, contracts, and regulatory constraints — this is the question that kills the most timelines when it gets asked in month three instead of month zero.

Why this doesn’t have to mean a long delay

A full enterprise-wide data governance program can take years, and waiting for that before starting any AI work is its own mistake — it trades one form of paralysis for another. The practical middle ground is scoping the governance pass to exactly the data the planned use cases actually touch, not the entire enterprise data estate. Answering the four questions above for the two or three data sources a specific pilot needs takes weeks, not years, and it’s genuinely fast compared to discovering the same gaps mid-pilot and having to pause engineering work to go answer them under time pressure.

The sequencing that actually works

Scope the AI use case first at a rough level — enough to know which data sources it would touch. Run the narrow governance pass against just those sources. Let what that pass reveals actually shape the final use case design — sometimes the answer is “this data isn’t usable yet, pick a different first use case” rather than pushing forward with a use case built on data nobody can vouch for. Then build. This isn’t governance instead of moving fast — it’s the version of moving fast that doesn’t require redoing the same roadmap work twice.

Before your next AI initiative gets a roadmap and a budget, has anyone actually answered where its data lives, who owns it, how clean it is, and who’s allowed to use it — or is that still an assumption baked into the plan?