Most boards in the region have already approved an AI governance initiative this year. Fewer have asked a harder question first: governed by what, exactly?
AI governance frameworks, model risk assessments, bias testing, explainability requirements, human-in-the-loop sign-off, are designed to catch problems at the point of decision. But they can only govern what the data layer hands them. If lineage is undocumented, if no one owns the reference data feeding a model, if access controls were never enforced consistently across systems, the AI governance framework isn’t managing risk. It’s inheriting it, one layer downstream, where it’s harder to trace and more expensive to fix.
This is the pattern showing up across GCC enterprises moving fast on AI adoption: the AI governance conversation gets funded, staffed, and reported on, while the data governance conversation that should have preceded it remains partial or informal. What’s usually missing is an operating gap. No single function sits upstream of both disciplines with the mandate to own the data that AI governance depends on. The result doesn’t show up in a pilot. It shows up in a model that drifts because no one flagged a change in the underlying data, in a decision that can’t be explained because the data behind it was never lineage-tracked, in a regulator’s question under NDMO or PDPL that the organisation can’t answer cleanly because ownership of the data in question was never assigned to a person.
Two Disciplines, One Point of Failure
Data governance and AI governance are often presented as parallel tracks, one making data trustworthy, the other making AI systems accountable. That framing is accurate as far as it goes, but it understates how directly one depends on the other. AI governance’s core commitments, explainability, fairness, human oversight, are only as strong as the data foundation underneath them. A model can be audited for bias all day; if the training data’s lineage was never mapped, the audit is checking the output of a process no one can fully reconstruct.
The stakeholder overlap is the tell. Business leaders, compliance, and security sit on both lists. Treating them as separately owned initiatives, reporting to different parts of the organisation, is how the handoff between them becomes the gap where risk accumulates.
Why the Fix Isn’t Another Framework
The instinct, once this gap is visible, is to write a policy that bridges it, a data-and-AI governance charter, a joint steering committee, a RACI document. These rarely hold, because a policy document doesn’t have the standing to arbitrate between competing priorities when a data owner and an AI product team disagree about what’s ready for production. What’s missing is a function with the mandate and the operational proximity to enforce it, day to day, not at quarterly review.
This is why a DMO does more than write data standards; it owns the lineage, the stewardship assignments, and the quality gates that AI governance depends on to do its job. But most DMO functions, including the ones shaped around frameworks like NDMO, were built before AI adoption made this dependency visible, their quality gates were designed for reporting, not for the specific risks a model introduces once it starts making or influencing decisions. That’s a gap most organisations building a DMO today are still working out how to close, and it’s where the function needs to extend rather than where it can be assumed to already reach.
We built HEMOdata’s DMO-as-a-service model to close that gap directly, treating AI governance as a core skillset within the DMO function rather than a separate discipline bolted on afterward. That means the same function that owns data quality and stewardship is also equipped to define the controls a model-ready dataset needs to meet, and to tell an AI governance committee, with evidence, whether the data behind a model is fit for the decision being made, rather than leaving that judgement to a governance layer that was never built to make it.
For most organisations at this stage, the constraint isn’t recognising this. It’s capacity: building and running a DMO function requires a specific blend of governance design, data engineering, and change management that internal teams are rarely resourced to stand up quickly, on top of the AI initiatives already competing for the same people.
Where This Goes Next
If AI governance is the framework being asked to catch risk your data governance hasn’t resolved, the sequencing question is worth asking directly: which one is actually in place, and which one is being assumed.
That’s the gap our DMO-as-a-Service engagements are built to close, giving the operating function AI governance needs underneath it, without the lead time of standing one up internally from scratch. If you’re evaluating where your organisation sits on that line, we’d welcome the conversation.
