The easiest way to spot a governance framework that won’t work is to ask a simple question: “What happens when your training data is wrong?” Watch how long it takes for someone to answer.

Most organizations have governance structures for AI models that exist entirely downstream. They talk about model cards, testing protocols, access controls, deployment gates. These are real things. But they’re built on an assumption that the data feeding the system is adequate. It rarely is.

I’ve watched this play out in three different ways. First, there’s the organization that has excellent data quality standards—but only for their transaction systems. When AI teams pull data for training, they treat it like a novelty. There’s no service level agreement. No validation pipeline. No understanding of what “good” looks like. The AI governance meeting happens monthly. The data quality review never happens at all.

Second, there’s the organization that built data governance years ago around regulatory compliance. Their data lineage tools work great for financial reporting. But AI training pulls from sources those tools never contemplated—third-party datasets, unstructured feedback, behavioral logs. The data steward doesn’t know what’s in production. The AI team doesn’t know where it came from.

Third, and this one is common: the organization that has separate governance structures entirely. Data governance is a technical problem, owned by engineering. AI governance is a risk problem, owned by compliance. They email each other occasionally. The data person doesn’t understand why the model person needs certain attributes. The model person doesn’t understand why the data person won’t merge this dataset from another system. They optimize locally for their respective problems.

Here’s what actually happens in each scenario: Your AI system goes into production. Three months in, a downstream business process starts failing in ways that don’t quite make sense. You dig. You find that the training data included records from a system migration that was supposed to be flagged as an outlier period. Or the historical data contains behavioral patterns that don’t apply anymore. Or someone changed how a critical field was calculated, and that change wasn’t documented, so downstream models are using stale definitions. Or you discover that 15% of your training set was duplicated because someone ran a batch job twice.

By the time you realize this, the model is in production. You’ve built decisions on top of it. Your governance framework has no way to retroactively assess what changed. It has no way to answer: “Should we have caught this?” Because it has no real view of what the data actually was.

Proper data governance for AI means several concrete things. First, your data contracts have to extend all the way upstream to the source. You need to know not just what fields exist, but what they mean, how they’re calculated, when they change. This is harder than it sounds. A “date” field sounds simple until you discover it’s been calculated three different ways in three different legacy systems that were supposed to be consolidated in 2019 but actually weren’t.

Second, you need a testing mindset around data that matches your testing mindset around code. Before a dataset feeds a production model, it needs to pass checks. Are there unexpected nulls? Has the distribution changed? Are there new values that weren’t in training? This should be automated, not a checklist someone marks off once.

Third, you need traceability. Not just “we trained this model on this dataset,” but “this field came from this system, it was transformed by this pipeline, and these validations happened at each step.” When something breaks, you need to know the full lineage fast.

Fourth, you need an owner. Not a committee. Not a shared responsibility. Someone who wakes up in the morning thinking about whether the data feeding your AI systems is trustworthy. That person needs to have standing in governance conversations. When they say a data source isn’t ready, that’s a model-deployment blocker.

The hard part is that data governance doesn’t feel urgent until it is urgent. A model audit finds a problem, and suddenly you’re in crisis mode trying to figure out where your data actually came from. A regulator asks about training set composition, and you realize you don’t have a complete picture. A customer reports they were treated unfairly, and you need to reconstruct what inputs your model saw.

By then, your governance theater is exposed as purely ornamental.

The organizations doing this well don’t separate AI governance from data governance. They treat them as the same problem. The criteria for putting data into production are the same criteria for putting models into production. Same rigor. Same documentation. Same review. Same ownership. When you ask “How do we know this data is good enough?” you get the same answer you’d get if you asked “How do we know this model is good enough?”

That alignment is harder to build than any framework. But it’s the difference between governance that actually catches problems and governance that exists to check a box.