I’ve seen a ton of charts and diagrams lately comparing data governance and AI governance. Or a maturity model where you cannot advance to AI governance until your data governance reaches a certain level.

Data is an interesting beast. I’ve argued for years that the right order is customer first, data second, technology last. Data is how you make decisions for your business and your customers. Data is king, and it was king long before AI became a market category. You can run a business without AI. You cannot run a business without data.

So I understand why the relationship gets drawn that way. But I think the charts are doing something misleading. They’re treating data governance and AI governance as sequential layers of the same thing. They’re not. They’re different disciplines answering different questions. And conflating them creates the same problem as any other governance confusion we’ve been discussing: organizations believe they have something they don’t.

What Data Governance Is Actually About

When we talk about data governance, we’re talking about ensuring that data is secure, private, accurate, available, and usable. That the right people can access the right data. That the data is trustworthy enough to base decisions on. That it’s handled in compliance with applicable regulations. That it doesn’t leak into places it shouldn’t.

These are foundational concerns. A business with poor data governance has dirty data, inconsistent records, integration failures between systems, and compliance exposure. AI absolutely relies on data, and AI trained on poor data produces unreliable outputs. That relationship is real and matters.

But notice what data governance is about. Data. The records, the pipelines, the access controls around information itself. Data governance governs a noun. A thing at rest or in transit.

What AI Governance Is Actually About

IBM says AI governance is about making AI systems safe and ethical. That’s a reasonable starting point. But safe and ethical by what standard, evaluated by whom, at what point in the system’s operation?

The fuller picture includes risk management, transparency, accountability, and compliance. It includes the questions that have come up throughout this series. Was this actor authorized to take this action? Should this action have happened? Who is responsible when something goes wrong? Can we prove what the system did and why? Does the system’s behavior stay within the boundaries that were defined for it?

Now compare those questions to the questions data governance asks. They’re different questions. The subject is different. The timescale is different. The enforcement mechanisms are different.

Data governance asks: Is this data trustworthy and properly controlled?

AI governance asks: Is this system behaving appropriately, and is someone accountable for it?

You can have impeccable data governance and terrible AI governance. Clean, accurate, well-governed data feeding into an agent that has no verifiable identity, no behavioral contract, no audit trail, and no human accountability chain is still an ungoverned AI system. The data was governed. The system wasn’t.

Where the Confusion Lives

The confusion comes from a few genuine overlaps that get inflated into a dependency.

Data isn’t ethical by default. How data is collected, compiled, labeled, and weighted becomes an ethical question. An AI system trained on biased data produces biased outputs, and that bias is a data problem with an AI consequence. But AI can develop biases based on its system architecture before data is even used. There is an overlap, but it doesn’t make data governance and AI governance the same discipline.

Data can’t be accountable. How data is exposed, who accesses it, and what decisions it influences are accountability questions. But accountability in an AI system isn’t about the data. It’s about the human who deployed the system and the governance chain that should connect every action back to a responsible person.

Security and safety do overlap at the edges. Locking down a database and preventing a system from accessing data it shouldn’t have are related concerns with different implementations. Database access control is a data governance mechanism. Defining the behavioral scope of an AI agent is an AI governance mechanism. The line between them is finer than the charts suggest.

Siloed data creates real integration problems. But siloed data doesn’t necessarily prevent collaboration through AI tools. An AI system can surface insights across organizational data silos that traditional integration would struggle to connect. The data governance and collaboration problems are separate from the AI governance problem.

The Right Tool for the Right Job

Here’s the principle that actually resolves this.

Data governance is the right tool for governing data. AI governance is the right tool for governing AI systems. The right data for the right project. The right type of AI for the right outcome. The right governance framework for the right problem.

A healthcare organization needs both. Strong data governance ensures patient records are accurate, protected, and compliant with HIPAA. Strong AI governance ensures that the agent accessing those records has a verified identity, operates within a defined scope, produces decisions that are auditable and explainable, and can be stopped if something goes wrong. One doesn’t substitute for the other. They address different failure modes.

A financial services firm needs both. Data governance ensures transaction records are clean and regulatory reporting is accurate. AI governance ensures the agent making trading recommendations operates within its authorized parameters, that its behavioral history is monitored for drift, and that, when a regulator asks which system made which recommendation under which authorization, there is a verifiable answer.

But a company with strong AI governance and messy data isn’t in the same position as one with strong data governance and no AI governance. Data problems will lead to inaccurate outputs. The governance problems will produce unaccountable systems. These are distinct risks with distinct consequences and remediation paths.

The charts that show data governance as the mandatory foundation for AI governance are drawing a dependency that isn’t categorical. They’re describing a best practice, not a structural requirement. You can govern an AI system well regardless of whether your underlying data governance is mature. The system might produce worse outputs if the data is poor, but the governance of the system’s behavior is a separate concern from the quality of its inputs.

What Actually Determines AI Governance Maturity

Data quality influences AI output quality. It doesn’t determine AI governance maturity.

AI governance maturity is determined by whether you can answer the questions that matter when something goes wrong. Which system did this? Who authorized it? What was it permitted to do? What did it actually do? Can you prove it? Who is responsible?

Those answers come from agent identity infrastructure, behavioral contracts, runtime governance, and tamper-evident audit trails. They don’t come from a data catalog or a data lineage tool, regardless of how mature those tools are.

The right question isn’t whether you need data governance before AI governance. The right question is whether you have the right governance infrastructure for the specific risk you’re managing. Sometimes that’s a data problem. Sometimes it’s a system behavior problem. Often it’s both. But treating them as the same problem, or as strictly sequential layers, means you’ll solve one while leaving the other unaddressed.

---

If you find this content valuable, please share it with your network.

Follow me for daily insights.

Book me to speak at your next event.

Chris Hood is an AI strategist and author of the #1 Amazon Best Seller Infailible and Customer Transformation, and has been recognized as one of the Top 30 Global Gurus for Customer Experience. His latest book, Unmapping Customer Journeys, will be published in 2026.