AI governance and data governance aren't the same discipline, but AI governance depends on data governance to function. Data governance decides who owns, can access, and controls each dataset. AI governance uses those same answers to classify risk, assign accountability, and build a usable audit trail, so an AI governance framework built on top of ungoverned data can't actually do any of those three things.

Data governance and AI governance are often treated as one project with two names, and that assumption is exactly why so many AI governance policies stop working the first time anyone tests them. Data governance is the standing set of decisions about who owns each dataset, who can reach it, and how long it stays. AI governance is the layer built on top of that, covering risk classification, named accountability, and ongoing monitoring, applied specifically to how AI systems are used. A business deploying a high-risk AI system needs to keep the data feeding it relevant and sufficiently representative for what the system is actually for, where it controls that data, and needs to hold onto that system's automatically generated logs, where it controls them, for an appropriate period of at least six months. That's Article 26 of the EU AI Act.[1] Both duties are far easier to demonstrate when the business already knows what data is feeding the system. Many Irish SMEs haven't checked.

If you're not sure the data behind your own AI governance work would hold up to that kind of scrutiny, an AI Readiness Assessment is the fastest way to find out.

What is the difference between data governance and AI governance?

Data governance covers how all of a business's information is owned, accessed, and kept, whether or not any of it ever touches an AI tool. AI governance is narrower and specific to AI, covering how AI systems are classified by risk, who is accountable for what they produce, and how their use is monitored and logged over time.

The distinction matters because it's easy to write an AI governance policy that reads correctly and still has nothing solid underneath it. A policy can name a risk tier for each AI tool in use, name a person accountable for outcomes, and set a monitoring schedule, all without ever checking whether the data behind those tools has an owner, controlled access, or a retention rule. The three data governance decisions that come first covers the three starting decisions, ownership, access, and retention, that make up data governance's working core. This article assumes that groundwork is understood and focuses on what happens to AI governance when it's missing. A one-time check that a specific dataset is ready for a specific AI project is a related but separate exercise, covered in full in the one-time readiness check for a specific dataset.

In summary

Check this before writing another line of AI policy. Does every dataset your AI tools touch have one named owner?

Why does AI governance fail without data governance underneath it?

AI governance fails without data governance because three of its standard mechanisms, risk classification, accountability, and audit logging, each assume a data governance answer that has to exist before they can work.

Risk classification needs to know what a system actually does and what it draws on to do it. If nobody can say which dataset an AI tool pulls from, or whether that dataset is current, the resulting risk rating rests on nothing solid. Accountability needs a person who can actually answer for an output, someone who can point to the real data owner behind it and explain where that data came from. Monitoring and audit logging exist to build a record that can be checked later, and a record is only useful if what it points to, the underlying data, has a known history. Each of these three pieces of AI governance does real work only once the data question underneath it has already been answered. The case for building AI governance at all makes the wider argument for why governance is worth building in the first place. This article is about what happens when that governance work outruns the data underneath it.

In summary

A risk classification without a named data owner behind it is just a guess with a label.

What breaks first, risk classification, accountability, or the audit trail?

Risk classification is usually the first thing to break, because it's the earliest point where AI governance asks a data question it can't answer.

The clearest public illustration of this sequence breaking is the US Federal Trade Commission's case against Rite Aid, a pharmacy chain that used AI facial recognition across hundreds of stores to flag suspected shoplifters. In its 2023 complaint, the FTC alleged that Rite Aid failed to test the technology's accuracy before deploying it, regularly used low-quality enrollment images despite having its own image-quality policies, did not train or oversee staff adequately, and failed to monitor and record false-positive matches consistently.[4] Rite Aid didn't admit these allegations as part of its settlement, and they describe exactly the gap this article has been tracing, policies that existed on paper but were never enforced in practice. The pattern maps onto the three lines set out above. Risk classification rested on an error rate nobody had actually measured, and the FTC alleged particular risk to Black, Asian, Latino, and women customers. Accountability weakened next. The complaint describes an early system with no outcome-tracking mechanism at all, and a later system where staff allegedly left most alerts unresolved despite having the means to record them. The audit trail existed in principle but wasn't kept up in practice. Rite Aid's final administrative order required it to delete the consumer photos and videos collected through the system, along with any data, models, or algorithms derived wholly or partly from them.[4] European regulators have reached a similar position by a different route. The European Data Protection Board's Opinion 28/2024, issued at the Irish Data Protection Commission's own request, confirms that where an AI model is built on personal data processed unlawfully, a supervisory authority's corrective measures may, depending on the facts and on proportionality, extend to the model itself as well as the data.[5] Neither regulator treats that outcome as automatic. Both treat it as a live possibility once the data underneath a system can't be accounted for, the same risk this article has been describing throughout. Building the six-step risk register process or the eight-component governance blueprint properly both assume this data question is already settled before the register or the blueprint is built.

In summary

Ask what happens if the data behind an AI system turns out to be ungoverned. Two regulators, on two continents, have already answered. The model itself can be ordered deleted.

Where does the EU AI Act actually require this connection?

The EU AI Act ties data governance and AI governance together directly, through two different articles depending on whether a business is a provider or a deployer.

One set of data governance duties falls on the business that actually develops a high-risk AI system, or has one developed and puts it into service under its own name, not only a business that personally builds and trains the model. That's the provider role, a specific legal role in the regulation, set out in Article 10.[3] A deployer can become a provider too, in the circumstances set out in Article 25, worth checking if your business substantially modifies a system it bought in. An Irish SME using an AI system under its own authority, without doing either of those things, is ordinarily a deployer rather than a provider for that use. Article 10 is still worth reading even where it doesn't apply directly, because it's the clearest statement in the regulation itself that data governance is a precondition for trustworthy AI, built into the requirements from the start. Where an Irish SME is the deployer of an in-scope high-risk AI system, a different set of duties applies instead. It needs to keep input data relevant and sufficiently representative for the system's intended purpose where it controls that data, and it needs to hold onto the system's automatically generated logs, where it controls them, for an appropriate period of at least six months. That's Article 26.[1] Neither duty is easy to meet without already knowing who owns the data, where it lives, and whether it can be trusted.

In summary

Article 26 only works if you already know what data your AI system is using. The regulation assumes governance many SMEs haven't built yet.

You already have some AI governance work done. How do you sequence the fix?

Fix the data governance gap before writing another page of AI policy, because every hour spent on governance work built on ungoverned data has to be redone once the data is fixed anyway.

Start with a single, answerable question for each AI tool currently in use. Who owns the data this tool draws from, and could that person explain where it came from and how current it is. If the answer is yes for a tool, its existing risk classification and accountability line are probably sound and can stay as they are. If the answer is no, or nobody is sure, that tool's governance work needs to pause until an owner is named and the data behind it's checked, however finished the paperwork already looks. This isn't a reason to abandon AI governance work already done. A lightweight, four-part AI governance framework can usually absorb a data governance retrofit without being rebuilt from scratch, provided the retrofit happens before the next audit or incident rather than after.

In summary

Fix the data question first. Everything else in AI governance gets easier once one person owns each dataset.

If AI governance work is already under way in your business and you're not certain the data behind it would survive a real test, an AI Policy and Governance Pack is built from your actual data landscape rather than a generic template, so the two pieces are put together properly from the start.