Governance in practice: what actually has to exist before AI touches your data

Governance is not a policy document. It is agreed metric definitions, clear ownership, documented lineage, sensible access controls and a change process, all of it tested against what an AI feature actually needs before you deploy one.

Ask a mid-market leader whether their data is governed and most will say yes. Ask them to name the owner of a specific dataset, or trace a number on a board pack back to the system it came from, and the answer gets vaguer fast. Governance said in the abstract means almost nothing. Governance that survives contact with an AI feature is a specific, checkable list of things that either exist or do not.

This matters more once AI is involved than it ever did for a static report. A dashboard with a shaky number gets questioned by a human who already has some scepticism built in. A model or agent built on the same shaky number will state it with total confidence, and confidence is exactly what erodes trust fastest when it turns out to be wrong. This post sets out what governance actually has to contain in practice, why most governance programmes stall before they get there, and the blockers that show up long before anyone opens a model.

What governance actually has to contain

For a mid-market organisation, governance means five concrete things, not a policy binder. It sits underneath whatever data strategy you already have, and assumes that strategy is properly defined rather than aspirational. Agreed definitions for every key metric, so that revenue means the same thing in the finance report and the sales dashboard. Clear, named ownership of datasets and reports, so there is one person accountable for accuracy rather than a shared assumption that someone else is watching it. Documented lineage, so anyone can trace a number back to the system and transformation that produced it. Access controls that reflect who should actually see what, rather than defaults nobody has revisited. And a lightweight process for managing changes, so a new field or a renamed category does not quietly break three reports downstream.

Named ownership matters more than it sounds like it should. Without it, a dataset technically belongs to everyone, which in practice means it belongs to no one. Nobody notices when it drifts out of date, nobody feels obliged to fix a definition that has quietly diverged from a related report, and nobody is accountable when a number turns out to be wrong. A named owner does not need to be technical. They need to be senior enough that fixing a data problem is part of their job, not a favour they do when they have time.

Lineage matters for a similar reason, but it earns its keep the moment something goes wrong rather than day to day. When a number in a board pack looks off, lineage is the difference between tracing it back to a specific transformation in an afternoon and spending a week interviewing three teams to reconstruct what happened. For AI specifically, lineage is what lets you answer the question a model cannot ask itself: where did this number actually come from, and should anything downstream trust it.

Why governance programmes stall before AI ever arrives

Five patterns recur. The first is a fifty-page policy document that becomes evidence governance exists rather than something that actually shapes behaviour. The second is waiting for a Chief Data Officer or a formal committee before starting anything. The third is treating governance as a separate workstream from delivery, so it never touches the reports people actually use. The fourth is confusing governance with control, which kills delivery speed and gets quietly routed around by the people doing the work. The fifth is having no review cadence, so the framework drifts out of date and becomes irrelevant within a year.

The blockers that have nothing to do with the model

When we ask mid-market leaders what is actually stopping AI adoption in their reporting, the tool itself is rarely near the top of the list. In order of how often we see them: no senior owner who has actually decided what AI is for in the business, rather than a general sense it should be doing more of it. Use cases picked because they were easy to demo rather than because they carry a quantifiable cost saving or revenue line. A governed data foundation that exists on paper but has not been tested against what an AI feature actually needs to query. No plan for keeping a model or agent running reliably once the pilot is over, so it works once and is never repeated. And no view on what happens to internal trust if the first pilot underperforms.

The businesses that get past this treat governance as a distinct piece of operational discipline that has to be tested against a real AI use case, not a policy exercise finished once and filed away.

The data quality problems that quietly break AI

Every governance framework eventually meets a specific set of data problems that keep showing up in mid-market analytics estates. Duplicate customer and supplier records creep in from inconsistent manual entry across systems, so the same organisation appears three times with three slightly different names. Product and account hierarchies drift out of alignment when one team reorganises a category structure and nobody updates the mapping everyone else relies on. Reference data goes stale, so cost centres that were closed two years ago and products that were discontinued last quarter still turn up in a report as if they are current. And definitional drift means the same metric name quietly means two different things in two different systems, so a query that blends both without knowing it produces a number that is confidently wrong rather than obviously broken.

None of this is exotic. Most of it has been sitting in the estate for years, tolerated because a human reading a report could usually spot when a number looked wrong. An AI feature removes that safety net. It will happily blend duplicate records, apply a stale mapping, or average across a drifted definition, and present the result with exactly the same confidence it would use for a correct answer. We go into why AI is so unforgiving of bad data in a dedicated piece on getting your data ready for AI.

What this means for you

None of these five things are individually hard to build. What is hard is treating them as a precondition for AI rather than something to circle back to once a pilot has proven itself. If you are assessing AI readiness properly, governance mechanics are one of the areas that assessment needs to test, not assume. We cover what that assessment should contain in our four-week AI readiness framework.

If you want a straight answer on where your governance actually stands before you commit to an AI feature, get in touch and we will walk through it with you.