AI Governance vs Data Governance: The Handoff Nobody Owns

“We can’t approve the budget for data governance right now. We need to focus on AI governance.”

Data governance leaders hear some version of that sentence often enough to recite it in their sleep, and each time it leaves the same question hanging in the room: if the data governance work is paused, what exactly is the new AI governance effort going to stand on?

Many organisations have reached the moment where AI governance arrives with a team, a dedicated channel and sometimes a Chief AI Officer, while the data team has spent years asking for a Chief Data Officer. Nobody seems to question why a second team was funded to govern the output before anyone fixed the function that makes the input trustworthy. It is a little like hiring a food critic before checking whether the kitchen has running water.

Both disciplines matter, and they do different jobs. AI governance is the newer one: the rules for how a model is built, what it is allowed to decide and who signs off before it ships. Data governance is the older and less glamorous one: making sure the information feeding that model is accurate, complete and traceable to where it actually came from. The trouble starts when AI governance arrives promising “responsible AI” without asking data governance a single question. What you get is two teams solving different problems, each convinced it owns the whole thing, and neither covering the seam between them.

The seam is where things break

An AI model has never produced a wrong answer entirely on its own. It produces a confident answer from whatever it was given, and when that answer is wrong, the cause usually started upstream, in the data, long before the model touched it.

That changes the order of the governance questions: whether a model is biased or explainable matters a great deal, but it is the second question. The first question, the one that decides whether the second can even be answered, is this: do we know where this data came from, who changed it, what it meant when it was collected, and whether it still means that now?

That is data governance, and it always has been. Lineage, quality, metadata and stewardship were the work nobody wanted to own for a decade because none of it shipped anything visible. Now AI builds on whatever was already there, cracks included, at a speed and scale that turns the old habit of “we’ll fix it in the next data quality sprint” into a real risk.

Regulators have noticed the same dependency, and Article 10 of the EU AI Act requires providers of high-risk AI systems to apply “data governance and management practices” to their training, validation and testing data, covering the origin of the data, “the original purpose of the data collection” for personal data, preparation steps such as labelling and cleaning, and an examination for possible biases (EU AI Act, Article 10). In other words, the law already treats data governance as part of AI governance. Even so, it is common to find the same organisation enthusiastic about AI literacy training and mildly offended at being asked to take data literacy training.

Where the line actually falls

Ask ten organisations whether AI governance should sit under data governance or alongside it and you will hear ten confident answers, very few of them backed by a map of what each function is supposed to own. The approach that holds up draws the ownership lines where the expertise already lives, rather than where the organisation chart looks tidiest on a slide.

Data governance owns the ground truth. That means source quality, lineage, cataloguing, master data, access controls, and the metadata that tells you what a field meant when someone first entered it. This is the layer that answers “where did this number come from?”, which is the question an executive will eventually ask whether a model is involved or not.

AI governance owns what happens once the model is in use. That covers model risk, bias testing, drift monitoring, explainability, and the regulatory obligations specific to automated decision-making rather than to the data itself. Traceability for decisions made by models at scale is a governance problem that did not exist in this form before.

Then there is the middle, and this is where most organisations are quietly failing. Who decides that a dataset is ready for AI? When a model consumes a data product, who owns the handoff: is it a data governance certification, an AI governance sign-off, both, or neither? If nobody names this layer explicitly, it does not disappear. It becomes the thing that surfaces eighteen months later, when someone asks a question neither team can answer and each points at the other in complete sincerity.

The fix is to choose a handoff and write it down. Data governance certifies a dataset as AI-ready, meaning its lineage is verified, its quality is checked and its access is controlled, and that certification is what AI governance builds on. It should be a certification with a named owner, one that either exists for a given dataset or does not. Too many organisations are inventing AI governance instead of expanding the governance they already have, often without consulting the people who run it.

The version that fails quietly

The tempting wrong version looks almost identical from the outside, which is what makes it dangerous.

AI governance sets up its own intake process, its own “AI-ready” checklist and its own definition of quality. It is built in good faith, sometimes by people who have never worked in the data layer and cannot know how bad a clean-looking dataset can be underneath. The organisation now has two definitions of “ready” living in two teams, and nobody notices the mismatch until a model makes a decision, someone challenges it, and the trace back shows the AI checklist never asked the one question that mattered for that field.

Picture a risk-scoring model whose AI governance intake asks whether the data is current and receives a technically true yes. Nobody asks whether “current” also means “collected under the definition we are now using it for”, and in this case it does not. The model stays confidently wrong for months, and the eventual fix costs far more than the single conversation with data governance that would have caught it on day one. This is exactly the gap that Article 10’s attention to the original purpose of data collection is meant to close.

Why getting this right matters

Data quality and governance teams are usually called in after the fact: after the wrong number has already reached a room with someone important in it, and after an executive has asked “where did that come from?” and received a shrug.

Anyone who has written data quality rules for regulated data, such as healthcare claims, learns early that the work is not really about compliance. A claim is not a row in a table. It is a person waiting to find out whether what just happened to their family is covered.

That is what is at stake in the handoff, underneath the organisation charts and ownership matrices. Get the seam wrong and the governance gap turns into something very concrete: a model confidently telling someone something false about their coverage, their care or their money, faster than any human reviewer can catch it.

So the next time someone tells you their AI governance is handled, ask them who certified the data the model was trained on, and what “ready” meant when they did. If the answer comes after a long pause, you have found the seam.