How Is AI Exposing Old Data Governance and Quality Debt?

---

AI exposes data governance debt by removing the analyst who read ambiguous data first. In EntSQL, 96.0% of enterprise BI questions needed knowledge beyond the question and schema (arXiv, 2026). Atlan’s context layer is where teams write that knowledge down and certify it for agents on Snowflake, Databricks, Microsoft Fabric and other platforms.

---

Most of that missing meaning is not lost. It sits in SQL query history, BI logic, lineage and a few analysts’ heads, written for people rather than agents. Atlan’s Context Agents draft descriptions and candidate business terms from the query history, BI logic and code, Context Engineering Studio surfaces the definitions that collide, and your data owners decide what each metric means.

Data debt question	Answer
What data debt is	Shortcuts in definitions, ownership and data quality that people compensated for and nobody wrote down
Why AI surfaces data debt	Agents answer at a volume no analyst reviews, and act faster than anyone can intervene
Which data debt bites analytics agents early	Context debt: one metric name, several meanings
What pays data debt down	Named, owned metrics drafted from existing signals and tested on the questions agents answer
What context work does not fix	Wrong values, which need fixing where the data is produced

---

Why does AI expose data debt that dashboards hid?

AI exposes data debt because dashboards usually failed slowly enough for a person to step in, and agents remove that window. That person knew which revenue column finance trusts, that the region field was renamed twice, and that one nightly load always lands late. According to Raghuvar Karthik Durga, Strategic CTO and Senior Account Technology Strategist at Microsoft, “a person almost always stood between ambiguous data and a consequential action,” and agentic AI removes that person (CDO Magazine, 2026).

The tribal knowledge that made this work held only because reports failed slowly. An analyst catches a strange number before the morning meeting; an agent acting across a dozen systems in seconds leaves nobody that window (TechTarget, 2026).

Two kinds of agent raise the stakes differently. A question-answering agent still has a reader, but it answers more questions than anyone reviews. An agent that acts has no reader at all. Doug Leal, Vice President of Data and Analytics Consulting at CGI, sums up the second case: “AI amplifies the range of the blast radius” (TechTarget, 2026).

In both cases the failure tends to look like the model’s fault. A confident wrong number reads like AI agent hallucination even when the model used exactly what the data allowed, which is how teams end up with projects that stall on data rather than models while they keep swapping models. Before swapping models again, run the failing question through the SQL an analyst would write. If that answer matches the dashboard and the agent’s does not, the gap is meaning the agent was never given.

---

What is the difference between context debt and data quality debt?

Context debt and data quality debt are two different shortcuts: a revenue column that means gross bookings to sales and recognized revenue to finance is context debt, and a duplicated customer_id is quality debt. Context debt is the gap between what an agent assumes your data means and what your business actually means. Quality debt is wrong, late or missing values.

Treating data as a source of debt is older than generative AI. Sculley and colleagues treated unstable data dependencies, the kind that change without anyone detecting it, as a form of technical debt in machine learning systems in 2015 (Sculley et al., NeurIPS 2015). What changed is who pays for it.

People absorbed most context debt. Your sales analyst knew revenue meant gross bookings and your finance analyst knew it meant recognized revenue, and both dashboards were right for their audience. The metric conflicts never surfaced because each team only read its own. People absorbed quality debt only partly: some duplicated customer_ids and some ship_date values earlier than order_date always reached a report.

Dimension	Context debt	Quality debt
What it is	Missing, overloaded or unowned meaning	Wrong, late or missing values
Example	revenue is gross bookings in sales, recognized revenue in finance; active_customer is 30 days in one team, 90 in another	Duplicate customer_ids; ship_date before order_date; a snapshot that stopped refreshing
Who absorbed it before AI	Analysts, mostly	Analysts and data engineers, partly
How an agent surfaces it	Confident answers that disagree with the dashboard	Answers that are consistent but wrong
What fixes it	Named, owned metrics an agent can read, plus a rule for which one a question means	Quality rules and fixes where the data is produced; checks downstream to catch what slips through
Who owns the fix	The business owner of each metric	The producer of the data

For a question-answering agent on a warehouse, the evidence points to context debt as the earlier wall: EntSQL found that 96.0% of enterprise BI questions need knowledge beyond the question and the schema (arXiv, 2026), a gap no amount of clean data closes. That is a reason to start KPI definitions and the business glossary before a broad cleanup. Values still need their own work: data quality for AI failures arrive in the same rollout, and in streaming or operational pipelines they often arrive first.

---

Where do AI agents hit old data debt first?

AI analytics agents, from Snowflake Cortex Agents to Databricks Genie, hit old data debt in four places: overloaded definitions, undocumented grain and filters, unowned tables, and stale or wrong values that analysts used to catch by eye.

Overloaded metric definitions

When one column name carries several meanings, the agent picks the most plausible one and answers with full confidence. According to Anthropic (2026), its internal analytics agent did not exceed 21% accuracy on its evals without skills, the domain-scoped documentation that tells it which tables and sources to use for each question, and ran consistently above 95% with them (Anthropic, 2026). Schema-only text-to-SQL for enterprise can ask a clarifying question, but only if it knows revenue is ambiguous, and in that context vacuum the schema alone cannot tell it.

Undocumented grain and always-on filters

Analysts know that fct_orders excludes test accounts and that order_total lives on the order header, not the line. An agent that joins fct_orders to order_lines and sums order_total counts each order’s total once per line, so revenue comes out inflated, and the SQL runs without an error. A declared grain and primary key on each model is what prevents it.

Unowned tables

Many tables have no owner anyone can name, so nobody can say whether an answer built on them is right. In one Deloitte case, a financial services firm struggled with limited metadata documentation and unclear data definitions, and its quarterly audits needed extensive manual review just to piece together data lineage, before it could rely on generative AI tools (Deloitte, n.d.).

Stale, late and wrong values

A half-loaded partition or a snapshot that stopped refreshing used to get caught because someone looked at the chart and thought it looked off. An agent answering from the same table does not have that instinct, so it needs a freshness and quality signal it can check before it answers.

Symptom an agent shows	The debt underneath	Who used to catch it	Where it gets fixed
Answer disagrees with the finance dashboard	One name, two metrics	The analyst who knew which to use	Named, owned metrics and a disambiguation rule
Revenue inflated by a multiple	Undocumented grain	The analyst who built the report	Declared grain and keys on the model
Nobody can say if the answer is right	No owner for the table	The one person who knew the table	A named owner and certification
Yesterday’s number presented as today’s	Stale or late data	Someone who knew the load schedule	Freshness checks the agent reads before answering
Answer is consistent but wrong	Bad values	Someone eyeballing the chart	Quality rules at the source, checks downstream

Each row is a different job for a different person. Treating them as one “data cleanup” effort hides which AI agent accuracy problem you are actually fixing.

---

Where does the missing business context already live?

The missing business context mostly exists already, as evidence written for people rather than agents. It lives in SQL query history, BI semantic models and dashboard logic, lineage, transformation code, wikis and tickets.

Research on enterprise text-to-SQL shows how much of it can be recovered. A LinkedIn team built a knowledge graph over database metadata, historical query logs, wikis and code. According to its authors (2025), adding example queries, table clusters and column attributes raised the share of correct or almost-correct queries from 9% to 49%, compared with table schemas alone (arXiv, 2025), which still left half the answers wrong. A 2026 study of schema-free text-to-SQL learned database structure from query logs alone and produced SQL that executed 95.7% of the time, against 60.8% for embedding-based retrieval (arXiv, 2026). Execution shows the query ran; only the metric’s owner can say it meant the right thing.

Production teams report the same pattern. According to VentureBeat (2026), when Miro pointed AI agents directly at a Snowflake environment of more than 10,000 tables with no semantic layer, the agents gave the wrong answer more than 65% of the time; the fix organized data into well-defined data products and mined SQL query logs for context (VentureBeat, 2026).

The platforms are building on this too. Snowflake’s Semantic View Autopilot proposes candidate metrics and filters learned from query history and trusted BI assets, and Databricks’ Genie Ontology, in Public Preview, extracts snippets from the SQL queries in query history, alongside dashboards, metric views and Genie Agents. A semantic layer built for BI already holds one definition per measure inside its own platform, which is much of what an agent needs. What it cannot see is the same revenue defined differently in the platform next door, or who in the business owns each version.

Query history is evidence for owners to weigh. The most-run query shows the most popular definition, which can still be the wrong one, and the business context for AI that settles it lives with the people who own the metric. Pasting raw documents into a prompt, the way many LLM knowledge bases start, does not close that gap: in EntSQL, the best system reached only 15.9% accuracy on English inputs even with long-form business documents supplied (arXiv, 2026).

AI can do much of the first draft. Across 50+ enterprises, Atlan’s context layer has generated more than 1.7 million asset descriptions from existing signals, with 90% accepted and 87% rated on par with or better than human writing (Atlan, 2026). Those numbers measure drafting, and owners still decide. To start, pull recent query history for your agent’s top questions and list the metric names that appear with more than one definition: those are the first drafts to send to owners.

---

Do you have to fix all your data before deploying AI agents?

You do not have to fix all your data before deploying AI agents. Scope the work to the questions your agent has to answer, and fix what those questions touch first. According to McKinsey (2026), only 7% of companies have fully scaled AI across their organizations, and more than two-thirds of high-performing companies say data is the primary obstacle (McKinsey, 2026). McKinsey’s advice is to “define what ‘good enough’ means for each use case” instead of perfecting data before starting.

Wrong values cannot be defined away, though. One production ERP deployment managing 240,000 employee records paired a multi-stage cleaning pipeline with LLM query generation to reach 92.5% query validity (arXiv, 2025). VentureBeat argues agents are confidently wrong mostly because of data engineering failures in correctness, freshness, consistency and lineage (VentureBeat, 2026). Scoping keeps that work and orders it: the tables your questions touch get cleaned, monitored and owned first.

Aspect	Estate-wide cleanup first	Question-scoped pay-down
Starting point	The data estate	The questions the agent must answer
Scope	Every table, every column	Tables, metrics and owners those questions touch
First draft of definitions	People write them	AI drafts from query history, BI logic and code; owners decide
What sets the size of the work	The size of the estate	The length of the question list
Wrong values	Cleaned everywhere	Fixed at the source for tables in scope, monitored downstream
How it stays current	A periodic re-cleanse	Evals and drift checks on the same questions

The AI readiness question worth asking is narrower than most programs make it: what makes data AI-ready for these questions, owned by these people, tested this way. An AI readiness assessment that scores the estate in the abstract tells you how big the debt is; the question list tells you which part to pay first.

---

How to pay down data debt one question at a time

You pay down data debt one question at a time by working backward from what your agent must answer to the metrics, owners and quality checks those answers depend on. Six steps, in order:

1. List the questions. Collect the real questions the agent will be asked, from tickets, Slack and dashboard requests; a few dozen is a workable first range, though no study sets the number.
2. Capture the SQL, then trace it. Find the analyst query that answers each question today, or run the question through the agent and capture what it generates. Then use lineage to expand from those tables to upstream sources and owners.
3. Let AI draft the missing meaning. Generate descriptions, candidate metrics, grain and join rules from query history, BI logic and transformation code, the context engineering step that turns evidence into something an agent can read.
4. Split overloaded names, then assign owners. Where one name carries two meanings, make them two named metrics, each with an owner, plus a rule for which one a question means, by domain, by role, or by asking the user. Never let the agent choose silently.
5. Fix values where they are produced. Put quality rules and data contracts for AI at the producer, and keep freshness and quality checks downstream so the agent can see when a table is late or failing. Fixing data quality at the source prevents what downstream checks only detect.
6. Turn the questions into an eval set, and keep running it. Anthropic watched its analytics agent’s offline accuracy drift from about 95% at launch to about 65% over a month while its skill documentation fell out of step with a data model that changes daily (Anthropic, 2026). Testing context quality and watching for context drift keep the debt paid.

A worked example: one overloaded revenue metric

Take one question from the list: “What was EMEA revenue growth last quarter?” The sales dashboard answers it from bookings.amount, gross bookings by close date. The finance report answers it from gl_revenue.recognized_amount, recognized revenue by period. Both are right, and the agent has been answering with whichever table it found first.

The fix is two certified metrics, gross_bookings (owned by sales operations) and recognized_revenue (owned by finance), each with its grain, filters and owner written down, plus one rule: board and finance questions mean recognized_revenue; pipeline questions mean gross_bookings; anything else gets a clarifying question. Those definitions are rendered into the semantic layer each agent reads, a semantic view in Snowflake or a metric view in Databricks, so every agent answers the same question the same way.

The eval set, a context eval rather than a data quality test, then holds both phrasings with their expected numbers. When finance changes its recognition rule next quarter, the eval fails before an executive sees the wrong figure. Snowflake’s Verified Query Repository and Databricks’ Genie Agent benchmarks already let you store verified questions and answers and score an agent against them inside each platform; the work above keeps the definitions behind them consistent across both.

For the build sequence, the guide to implementing an enterprise context layer covers the architecture, and an AI-ready data checklist gives you the checks to run per question.

---

Can AI pay down its own data debt?

AI can only partly pay down its own data debt. Context agents draft descriptions, candidate metrics and join rules from query history far faster than people can, but they cannot decide what revenue means to your business, and they add debt of their own.

Some practitioners see AI as the cure. Barney Krishnan, Data Executive at UniCredit, argues that undocumented legacy environments are the biggest hurdle to safe AI, and that agents are also the tools able to parse and catalog them (Forbes Technology Council, 2026). HFS Research goes further, arguing that agentic AI is the fix for enterprise data debt rather than its victim (HFS Research, 2025).

Others point to the debt AI adds and the debt it reveals. David Linthicum warns that AI creates new technical debt in prompts, models and retrieval workflows, showing up first as “inconsistent answers” and brittle workflows (TechTarget, 2026). Bill Schmarzo, who teaches AI-driven innovation at Iowa State University, puts the older half plainly: “AI did not create your auditability problem. It exposed the one you already had” (TechTarget, 2026).

The workable split is AI as the first drafter, an owner as the decider and an eval set, with expected answers the owner signed off, as the referee. That keeps people where accountability has to sit, which is the human side of context agents most rollouts underestimate, and it shapes who should own the context layer: the business owns the meaning, the platform team owns the pipeline.

---

How Atlan approaches context debt

Atlan treats paying down context debt as a pipeline: draft the missing meaning from signals you already have, have owners decide it, test it against real questions, and keep it consistent across every platform your agents run on.

The challenge is that each platform holds its own version. Teams can end up with one definition of revenue in a Snowflake semantic view, another in a Genie Agent and a third in a custom agent’s prompt, each correct for whoever built it.

Atlan’s Context Agents read SQL query history, BI semantics and pipeline code to generate asset descriptions, link business terms and surface your top business questions (Context Agents). Context Engineering Studio turns dashboards, reports and production queries into a test suite, surfaces definition conflicts across teams for owners to settle, and renders the result into the semantic layer each target expects: a semantic view in Snowflake, read by Cortex Agents and Cortex Analyst, metric views for Databricks Genie and MetricFlow models in dbt (product overview). The same certified context reaches a Microsoft Fabric data agent through OneLake, and agents on other platforms through Atlan’s MCP server (Fabric data agents). Data Quality Studio runs business-defined quality rules natively in the warehouse and surfaces the results as trust signals next to the definitions (Data Quality Studio docs), so an agent can see a failing table before it answers. Fixes still happen where the data is produced (step 5). All of it sits in one enterprise context layer.

At Mastercard, the Context Agents rollout enriched more than 30,000 assets and saved 6,200 hours of steward time in two weeks, moving the team from writing data descriptions to certifying what AI generates (Mastercard session).

---

Real stories from real customers: Shared meaning for AI

---

The debt AI exposes was always yours

Agents fail on enterprise data for more than one reason, and for analytics agents the earliest one is usually meaning nobody wrote down, the same unowned meaning behind many data governance implementations that fail. The teams that ship start with a short list of questions, split the names that mean two things, put an owner on each metric, and fix the values those questions touch. Then they keep testing, because the definitions describe a data model that keeps changing, and an agent’s accuracy drifts with it.

---

FAQs about AI and data governance debt

1. What is data debt in AI?

Data debt is the accumulated shortcuts in definitions, ownership and data quality that people compensated for and never wrote down. In AI it splits into context debt, meaning metrics with unwritten, overloaded or unowned definitions, and quality debt, meaning wrong, late or missing values. Analytics agents tend to hit context debt early because analysts used to resolve it without writing anything down.

2. Why do AI agents give different answers for the same metric?

AI agents give different answers for the same metric when one metric name carries more than one meaning, such as revenue that means gross bookings in sales and recognized revenue in finance. Without named metrics and a rule for which one a question means, the agent picks the most plausible table for each query, so similar questions can resolve to different calculations.

3. Is data debt the same as technical debt?

Data debt is a form of technical debt that lives in data dependencies rather than code. Researchers treated unstable, hard-to-detect data dependencies as hidden technical debt in machine learning systems in 2015. With AI agents, the costliest part is business meaning that was never written down, which code review catches only when the meaning already lives in code.

4. Do you have to fix all your data before deploying AI agents?

No. Scope the work to the questions the agent must answer, trace them to the tables and metrics they touch, and name, own and fix those first. McKinsey recommends defining good enough for each use case rather than perfecting data before starting. Wrong values on the tables in scope still need fixing where the data is produced.

5. Can AI fix its own data debt?

AI can draft much of the missing context, including descriptions, candidate metrics and join rules generated from query history and BI logic. It cannot decide which meaning the business intends when one name carries two, and it creates new debt in prompts and retrieval workflows. The reliable pattern is AI drafting, an owner deciding and an eval set checking the result.

6. Why do AI agents handle bad data worse than analysts?

AI agents handle bad data worse than analysts because they do not notice that a number looks off and have no habit of checking the trusted dashboard. Give the agent freshness and quality signals it checks before answering, and fix wrong values where they are produced.

7. How do you decide which data debt to pay down first?

Pay down the debt behind the questions your agent will be asked most often, starting with metric names that carry more than one meaning. Then assign an owner to every table those questions touch, and add freshness and quality checks for the values that feed them. Debt outside that path can wait until a question needs it.

---

Sources

1. EntSQL: A Benchmark for Grounding Text-to-SQL in Long-Context Enterprise Knowledge, arXiv

2. Agentic AI Is Turning a Decade of Enterprise Data Debt Into Operational Risk, CDO Magazine

3. How agentic AI amplifies data management challenges, TechTarget

4. Root out hidden data debt to improve AI decision-making, TechTarget

5. Hidden Technical Debt in Machine Learning Systems, NeurIPS Proceedings

6. How Anthropic enables self-service data analytics with Claude, Anthropic

7. Writing GenAI checks your data can’t cash, Deloitte

8. Text-to-SQL for Enterprise Data Analytics, arXiv

9. Schema-Free Text-to-SQL: Learning Enterprise Database Structure from Query Logs, arXiv

10. SQL query logs hold the context AI agents need to stop hallucinating joins, VentureBeat

11. Snowflake Semantic View Autopilot: AI-Powered Semantic Modeling in Minutes, Snowflake

12. Genie Ontology, Azure Databricks Documentation

13. AI data readiness: The key to scaling impact, McKinsey & Company

14. RAG-Driven Data Quality Governance for Enterprise ERP Systems, arXiv

15. AI agents aren’t confidently wrong because of bad context, they’re wrong because of bad data engineering, VentureBeat

16. Cortex Analyst Verified Query Repository, Snowflake Documentation

17. Test and monitor a Genie Agent, Databricks Documentation

18. The Data Governance Deja Vu: Why Agentic AI Is Forcing Us To Rebuild The Data Foundations, Forbes

19. Agentic AI fixes enterprise data debt, HFS Research

20. The quiet rise of AI technical debt, TechTarget

21. AI doesn’t have a trust problem. Your data does., TechTarget