Stop Funding Data Governance! Start Climbing the Maturity Ladder with Agentic Data Governance
For two decades we answered broken data governance with more boards, more policies, more headcount but got meetings instead of data quality. Agentic AI finally changes the economics.
Data Governance didn’t die. It can finally grow up. Thanks to AI, not because of it. Data People expected a lot of attention on the Topic of Data Governance, but in fact the expectations fell short; it started with arguments “we need good Data Quality for AI”. This is wrong, data people didn’t understand what AI is about. AI is about (process) automation largely and it only touches data on the side. You can get impressive results without even touching Data.
For two decades, the poor Data People argued for Data Quality and nobody listened. The board didn’t want to fund it; odd, considering the same board expected reliable numbers every quarter. I know this uphill battle from the inside, because I fought it the traditional way. I set up governance boards, gremiums, steward networks. They produced policies, the policies produced meetings, and the meetings produced very little data quality.
So today I argue for something close to the opposite of what I once built: strip governance back to what actually needs a human, and let the rest run where the work happens. DAMA gave us a framework that is theoretically complete and organisationally unfundable. Nobody staffs it fully, so it half-exists everywhere and works nowhere.
But “unfundable framework” and “no governance” are not the same conclusion, and this is where I’ve changed my mind about my own hot take. The failure mode was never too little governance or too much. It was uniform governance. We reviewed the experimental chatbot with the same ceremony as automated credit decisioning. Heavy process applied evenly kills velocity on the harmless stuff and still under-serves the genuinely dangerous stuff. The fix is proportionality: governance intensity should match exposure: blast radius and reversibility but not a one-size-fits-all policy.
This is where AI enters — and no, it doesn’t kill governance (the dash is on purpose :D). It finally makes the proportional version affordable. Agents can write the documentation, watch quality, classify sensitive data, and review every change directly in the pipeline. All the toil that once justified an entire governance organisation is now automatable, which means governance stops being a department you fund and becomes a capability that runs.
One honest caveat before the recommendation, because it’s the thing that separates a LinkedIn take from something that survives contact with your actual org: this is a capability you have to earn. Agent-run governance sits on prerequisites: a clean corpus, documented APIs, real guardrails. Most organisations are somewhere between “we have a RAG chatbot” and “our core systems have documented APIs.” Deploy governance agents on top of that and you don’t get automation, you get an agent that fails unpredictably. Do the honest assessment of which rung you’re on first.
If you’ve earned the rung, here’s the shape I now recommend with three changes to the team setup.
The Exception Layer
This is done by a handfull of humans as a side task. They are here for the decisions that genuinely need humans: accepting risk, settling conflicts, saying yes to the thing the agent flagged and can’t decide alone. This is the one job the department was always secretly for. No standing meetings, no agenda, agents prepare the case, people decide the exception. Define the risk appetite once (”we accept up to X% error on internal document search”) and it becomes a boundary the agents operate inside, not a debate you re-run every sprint.
The Exception Layer is automated and doesn’t run in regular meetings. If the agents (I’ll describe them below) flag something, automated alerts are sent to those impacted and potentially the CDO. There is no need for a dedicated Data Governance Team, Data Governance becomes a capability people need to know.
The Agent Fleet
All the steward work nobody ever wanted, such as documenting, tagging, writing quality rules, goes to agents, running continuously, right where the data work happens. The catalogue stays current on its own (i’d argue we might even don’t need one as we know them, they would need to evolve!). Frontier models are extremely capable here, and tuned well, errors are rare (humans also make errors, possibly at an even higher rate as frontier models now!)
But there is the part I’d have skipped a year ago: the fleet is itself a system you govern. An agent that classifies your sensitive data is an AI system with its own accuracy, cost, and security profile. So governance doesn’t disappear; it moves up a level. Humans stop doing the toil and start watching the agents doing the toil. Your oversight loop wraps around the agents’ loops. That’s not more bureaucracy it’s the same OODA discipline, just pointed one layer up: observe the agents, orient on drift, decide, act, in days rather than quarters. Systems change too fast to keep up anyways, what you govern today is already outdated tomorrow!
The Semantic Agents
No more workshops about what “customer” means, because an agent finds the definitions already living in your queries and reports, surfaces the conflicts, proposes one answer. Humans just ratify. I’ve spent recent months on transformations that moved from legacy DWH to lakehouse in months, not years, precisely because agents have genuinely strong semantic understanding of what’s already encoded in the estate.
On the “but hallucinations” objection: I used to answer it with “they’re rare, and humans err too, so what.” I don’t anymore, because that’s the wrong axis. The question was never how often the agent is wrong. It’s how bad is it when it is, and can you undo it. A mislabeled internal doc is a shrug; an agent misclassifying regulated PII is not. So you don’t govern by error rate, you govern by exposure with heavy oversight where blast radius is wide and mistakes stick, light touch where failures are caught cheaply. Get that calibration right and “AI slop” stops being an argument against the approach and becomes an argument for doing it properly.
What does this need?
To make an Agentic Data Governance Team, you need several different agents, grouped by the 3 dimensions I just described above. Let’s have a look at the visualization I’ve created:
The Orchestrator Agent
Think of it as the chief of staff of the whole setup. It coordinates the fleet, pulls in the analysis from the semantic agents, does the heavy reasoning over all of it, and decides exactly one thing: does this need a human? Everything routine it handles itself; the genuine exceptions it routes to whoever owns that responsibility. This is where the RACI matrix nobody ever maintained finally gets important. With human Data Teams, it was just paper, Agents will use it for their daily routing. What it never does is own the risk, humans do.
A key thing here: an independent Challenger Agent watches it: an independent auditor, on purpose a different model vendor than the fleet, reporting to Risk rather than the CDO. This challenger or Audit Agent constantly reasons over the log the orchestrator with the fleet produced and gives insights to risk and security (but also the CDO). As mentioned, don’t use the same model as for the fleet, as the same model likely swallows the critical things (e.g. if your fleet runs Claude models, use OpenAI or similar here!)
The Semantic Agents
These two replace the most painful ritual of all: the glossary workshop. Instead of another two-hour debate about what "customer" means, the Semantic Agent mines the definitions already living in your dbt models, SQL, and reports, and finds where Finance and Marketing calculate the same KPI differently, surfacing the conflict with evidence, not opinion. The Modelling Agent does the same for structure: it drafts models from source systems and proposes conformed entities from what actually exists across domains, rebuilding the enterprise data model bottom-up in weeks instead of years. Both share one hard rule: they only ever propose. Meaning stays human; the agents just do the archaeology.
The semantic agents should also re-use skills as they are relevant for any kind of check-ups. Also, they should use strong tools, e.g. sqlglot to have deterministic analysis combined with reasoning rather than parsing all of the models by inference.
The Agent Fleet
This is all the steward work nobody ever wanted, handed to agents that run continuously, right where the data work happens: in the pipeline and in the pull request:
The Documentation Agent keeps the catalog current as a byproduct of every change.
The Classification Agent scans for sensitive data and tags it, not once a year for the audit but always.
The Quality Agent proposes its own rules instead of waiting for someone to write them, and delivers a diagnosis rather than an alert (propose only, heavy reasoning here).
The Access Agent proposes the low-risk 80% in minutes and routes only real exceptions to the owner, e.g. by sending a reasoning why the user can access to the data owners and tracks the execution
The Lineage Agent answers "who breaks if I change this column?" before the merge, not after the incident. It also tracks lineage end-to-end and reasons about potential breaking changes by scanning project requests and Jira tickets. My vision is that this agent can actually weight in on tickets; humans can never scan this and won’t know what exactly is going on in all projects a company does while a lineage agent can constantly change project changes, demands and feature requests and warn upfront about breaking changes.
And the Architecture Agent patrols the paved road, catching the shadow datasets and point-to-point copies no board ever saw coming.
A key thing about the Agent Fleet - they would normally run per domain, not as single items. But this depends a lot on the size of the organisation.
What are the benefits of this approach?
Governance is a fast and constant loop. The old cycle was: change happens, quarterly review notices, committee discusses, memo follows. The new cycle is: change happens, agent comments in the pull request, done. This is now Minutes, not quarters. This is the benefit no budget could ever buy and even a governance unit of fifty people cannot sit in every PR, every access request, every schema change. Your OODA loop shrinks from quarters to days, and governance finally moves at the same speed as the estate it governs.
Full coverage instead of samples. Human governance always sampled: the annual audit, the spot check, and alike. Humans can’t oversee all and the large majority of data was hope. Agents review everything, continuously: every column, every change, every grant. One hundred percent coverage is never a matter of funding; it is structurally impossible with humans, but with Agents it’s the default. Annual audits become what they always secretly were: archaeology.
The cost structure flips from headcount to compute. This is the financial argument, and it’s the one your CFO will actually hear. A governance department is a fixed cost that produces meetings whether or not anything changed. Agents cost compute that scales with actual work. The business case I could never sell as “fund fifteen stewards” now closes as “tokens plus one platform engineer.” Governance stops competing with delivery for budget, because it stops being a department and starts being infrastructure.
The audit trail writes itself. Every agent decision lands in the append-only log: what was checked, what was found, what was decided and why. That’s better compliance evidence than any manual process ever produced and no reconstructing decisions from old emails, no panic before the regulator visits. Ironically, the setup that looks radical to a risk officer produces exactly the documentation risk officers always begged for and never got.
People stop hating governance. This one is underrated. Access in minutes instead of weeks. Documentation written for you instead of demanded from you. A warning before you break two dashboards instead of an incident review after. Governance flips from police to colleague. Shadow datasets shrink, not because of another awareness campaign, but because the paved road is genuinely the easiest path. That’s the data culture the gremiums spent two decades trying to create with posters and workshops. It turns out culture follows friction, not slogans.
What’s the catch?
One thing upfront: it is not about hallucinations or long tail events. Everything I described above is a Level 6 capability of AI maturity as described in our book. You can only do this if you are already good in AI execution (and most companies are rather at the basics of it)
In the book we lay out the AI Capability Ladder: six levels, strictly sequential: Basic RAG, Core System APIs, Agent Tool Calling, MCP Integration, Agent Orchestration, and finally Multi-Agent Orchestration. Agentic Data Governance is textbook Level 6: multiple specialized agents, an orchestrator coordinating them, inter-agent communication, aggregate governance. You cannot skip your way there. An organization without stable, documented APIs (Level 2) cannot run reliable agents (Level 3), let alone a governance fleet. An agent without reliable APIs is an agent that fails and a governance agent that fails unpredictably is worse than the bureaucracy it replaced.
Most organizations today sit between Level 1 and 2. That’s not an insult, it’s a starting position. And the climb pays as you go: documented APIs are worth having on their own. Your first single-purpose agent (documentation, classification) is a Level 3 win that removes toil immediately. The orchestrator arrives at Level 5. The department dissolves at Level 6. No big-bang switch, no transformation program, a constant improvement in the OODA Loop.
So no, don’t disband your governance unit on Monday. Climb. You can’t buy your way up the maturity ladder, but for the first time, the top of it isn’t a bigger department: it’s almost no department at all.
Is it actually possible and what should you do now?
Some parts are already here. Semantic modelling, automated quality rules, PII classification, lineage extraction; look at the references in this piece and you’ll find most of the components sitting in the literature, several of them already shipping in production systems. What doesn’t exist yet is the assembly. And the assembly is the hard part: it demands maturity in AI and architecture but not in governance. That’s the inversion nobody in the governance world wants to hear.
Here’s the uncomfortable part. Most data people are not AI-savvy, and they carry a wrong perception of what AI will do for them. The common thinking goes: AI finally gives us the justification we begged for over the last two decades: now they have to fund our data quality. It’s exactly vice versa. AI can solve data issues far better than most data people can, and it doesn’t need their gremiums to do it. I say this as someone rooted in the data community who moved over to AI in recent years, and from that side of the fence the view is brutal: data handling is about to change completely, and most data people are sitting in slowly warming water like the proverbial frog: comfortable, validated, and not noticing that it will end them.
So here’s what to do now, concretely. First, run the honest assessment: which rung of the ladder are you actually on: in production, not in a demo? Second, ship one agent. Documentation or classification, in the pull request, this quarter. It’s a Level 3 win, it removes real toil, and it teaches your organisation more about agentic governance than any strategy paper. Third, put your standards into git, where agents can load them; the day pipelines are written by agents, that repo is your governance. And if you’re a data person: move toward the AI side, now. The people who thrive in this shift won’t be the ones defending the old department. They’ll be the ones running the fleet.
The honest version of my original claim, then: Data Governance as a standing bureaucracy is over. Data Governance as a proportional, agent-run, exposure-calibrated capability is finally possible, arguably for the first time. The models get more capable weekly. The discipline is in knowing which rung you’re on and where your real exposure lives.
The frog can still jump. But the water is warming weekly.
Some References and further read
[1]: arXiv:2408.04691; Synthetic SQL Column Descriptions and Their Impact on Text-to-SQL Performance; Though written in 2023 and experiments done with Gpt-4o and Qwen2, the performance was already great.
[2]: arXiv:2505.23133; LINEAGEX: A Column Lineage Extraction System for SQL; Lineage graphs can be integrated as tools, combined with LLMs they are far better than any human could do
[3]: arXiv:2506.22305; Detection of Personal Data in Structured Datasets Using a Large Language Model; prooves that LLMs can help classify; though done with an outdated model (GPT 4o)
[4]: arXiv:2503.11573; Synthesizing Access Control Policies using Large Language Models; this paper discusses how LLMs can improve access control policies