Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
Governance breaks in four places once data spans a warehouse, dbt, BI and AI agents: ownership, policy reach, lineage gaps and uncataloged tables.
Updated on
Data governance in a modern data stack is the practice of holding a single answer to four questions about a table when that table is touched by five or six separate systems: who owns it, what class of data is in it, where it came from, and who read it. The questions are the same ones a bank asked of a mainframe in 1995. What changed is that no system in the stack can answer any of them on its own.
This page is about that gap, not about governance in general. If you need the definition, the pillars and why governance matters at all, what data governance is and the pillars it rests on covers it. What follows assumes you already run a modern stack and want to know where it leaks.
A modern data stack is usually five layers. Ingestion moves records in. A cloud warehouse or lakehouse holds them and runs the compute. A transformation layer, most often dbt, turns raw tables into modelled ones. A BI layer serves dashboards and extracts. Since 2025 there is a fifth layer that did not exist when most governance programs were designed: agents and assistants that query the same tables through an API rather than through a dashboard.
Every one of those layers keeps its own metadata. The warehouse knows the object owner. The transformation project knows the model owner written in a YAML file. The BI tool knows a workspace role. The catalog knows a data steward. None of them is wrong, and none of them is authoritative.
The centralized model worked because governance was a property of the database. There was a single engine, a single administrator and a single GRANT statement, so a rule set once applied everywhere the data could be read. Three changes in the modern stack take that away.
| Governance concern | Single database era | Modern data stack |
|---|---|---|
| Where a rule is set | Once, in the database | Separately in each tool that touches the data |
| Who owns an asset | The schema owner | Four owner fields that do not agree |
| How lineage is known | Read from the one engine | Assembled from every layer, with gaps |
| Who read a column | The database audit log | Several logs with different retention windows |
| Speed of change | Release cycles | Daily model deploys and ad hoc agent queries |
Across the stacks we see, the same four failures come up. They are not vague risks. Each one has a check that finds it in an afternoon.
| Breaking point | What it looks like | The check that finds it |
|---|---|---|
| 1. Ownership | Every tool has its own owner field and none of them agree | Count assets with an empty or stale owner in every tool, not only the catalog |
| 2. Policy reach | A rule set in one tool does not follow the data out of it | Take one classified column and follow it into a BI extract |
| 3. Lineage | The graph stops where each tool stops instrumenting | Rename a table, then reopen the lineage graph |
| 4. Agents | An assistant reads tables nobody cataloged | Ask the assistant for a table you know is undocumented |
Ownership is the failure that looks solved and is not. Every tool in the stack has a place to record an owner, so every tool reports high coverage, and the four sets of owners disagree the moment anyone checks them side by side. Worse, most of those fields hold a team name or a service account rather than a person.
Tool boundaries make this concrete rather than philosophical. In Databricks Unity Catalog, detailed information about workspace objects such as notebooks, jobs and dashboards is visible only in the workspace where they were created, and appears masked to a user working from another workspace. Two teams can each believe they know who owns a pipeline while looking at different halves of it.
The working test: an asset has an owner only when the owner is a named person who can be contacted, recorded in a single system, and resolvable from any tool in the stack. A field filled with a team alias is a field, not an owner. Count your assets against that definition rather than against whichever tool gives the flattering number.
A classification is only worth what it reaches. In a modern stack, most classifications are written where it is convenient rather than where the data is read, and the gap between those two places is where policy quietly stops.
Take dbt. You can write a description and a classification against a column in the model YAML, and it will sit in the dbt project and go no further, because the persist_docs setting that pushes descriptions into the warehouse as column and relation comments is disabled by default. dbt Labs also documents that persist_docs is not implemented for sources at all, so the raw tables closest to your regulated data are the ones least likely to carry their description into the warehouse. On Databricks, column level comments additionally require a delta file format. Keeping those descriptions and classifications aligned across tools is the work covered in our guide to metadata governance.
Now take Snowflake. Tag based masking policies let you set a policy on a tag and have every column of a matching data type protected automatically, which is a real answer to scale. Two boundaries come with it. It is an Enterprise Edition feature, so a Standard Edition account does not have it. And the policy is evaluated when the column is queried inside Snowflake: an authorized role sees the raw value, and anything that role writes out to a CSV, a BI extract or a notebook carries the raw value with no policy attached to it.
The working rule: treat every export as the edge of a policy. Write the classification where the data is read rather than only where it is defined, and know the list of places your data leaves the tool that protects it.
Lineage is the most oversold part of the modern stack because every vendor ships a lineage view and every lineage view is honest about a smaller area than buyers assume. The limits are published. They are just published in the documentation nobody reads during a demo.
The working assumption: your lineage is complete only for objects that were never renamed, connected through the vendor user interface, and touched inside the retention window. Everything else needs a graph assembled outside the tools. How that graph is built, and what column level lineage adds over table level, is covered in data lineage tracking, its types and techniques.
Retention is where this becomes a compliance question rather than a convenience one. The windows are short and they differ by layer.
| Layer | What it retains | Documented limit |
|---|---|---|
| Snowflake Time Travel | Historical row state for queries, clones and undrop | 1 day by default, up to 90 days for permanent objects on Enterprise Edition |
| Snowflake ACCESS_HISTORY | Which user read which object and column | Last 365 days, Enterprise Edition or higher |
| Databricks lineage system tables | Table and column lineage events | Rolling 1 year window, older events removed |
| Databricks Catalog Explorer lineage | The lineage graph | Retained indefinitely, but only from 1 September 2024 onward |
| Power BI lineage view | Dataset, dataflow and report links | Scoped to one workspace, Viewer role cannot open it |
Read that table against your own retention obligation. If an auditor asks who read a customer column two years ago, a Snowflake account cannot answer from ACCESS_HISTORY, because the view covers the last 365 days. The record has to be landed somewhere with a longer window before the question is asked, not after.
The newest breaking point is the one no governance program was designed for. An agent connected to your warehouse does not browse a catalog and pick the certified table. It runs a query. If an uncataloged copy of the customer table is sitting in a scratch schema with the same columns and no classification, the agent will find it, use it and answer confidently.
The failure mode is worth stating precisely, because it is not the one people expect. The risk is not that the agent invents an answer. The risk is that the agent is correct about a table that should never have been in scope, and nobody can tell from the answer which table it used. That turns every uncataloged asset into an access problem rather than a documentation problem.
Two numbers make the size of it visible in any stack. Count the tables an agent credential can reach. Then count the ones with an owner and a classification. The distance between those two numbers is your actual exposure, and in most stacks nobody has ever measured it.
The demo below shows what closing that distance looks like in practice. Claude is connected to live Decube context through an MCP server and works through a governance team, one after another: how asset recovery is calculated from query logs, how many assets have no owner, which dashboards a table change would break, and, in the part that matters here, finding a Databricks table holding customer email that has not yet been classified as PII. It also writes back, enriching descriptions and creating monitors, with access controls refusing users who are not authorized.
The governance controls an agent needs are the ones you already owe an auditor, applied to a non human reader. Our guide to governing AI agents that read your data works through the access model in detail.
Four things, matching the four failures. None of them can live inside a single tool, which is the whole point.
That set is what a data governance tool for a modern stack has to deliver: not a policy library, but a place where those four answers stay consistent while the tools underneath them change.
The rest of this page is the worked example. It is the Decube governance module, and it is organized around exactly the four problems above rather than around a feature list.
Traditionally, governance policies are stored in disparate locations: spreadsheets, email threads and documents that live outside the systems holding the data. Decube provides a central location for all of your data governance policies and links them to the actual data assets in the Catalog. That link is what turns a written policy into something you can check, because it gives you a complete view of how a given asset is governed rather than a folder of documents nobody opens.
Every organization classifies differently, so classifications are yours to define. Add a custom policy in the Classification Policies tab and start classifying data against your own criteria. This matters most for teams early in a governance program: start with a basic set of classifications and add more as the program grows, rather than waiting to design the full taxonomy before anything is classified.
The sensitive content pattern rule is a classification workflow inside each policy detail. It lets you set rules against connected data sources that automatically tag columns matching a keyword or a regular expression. For example, a rule can classify every column containing the phrase social security number as PII, which is how you close the distance between the tables an agent can reach and the tables that carry a classification. On a large stack this is the only version of the job that finishes.
Policy documents can be uploaded as attachments directly against the policy they belong to, so the governance documentation and the assets it governs sit in the same place. When an auditor asks for the written policy and the list of assets covered by it, both answers come from one screen.
For each policy you get the list of assets managed under it, so every asset tagged as PII, for instance, appears in a single view. The list exports as a CSV, either to send to another team or to hand over for an audit. You can see the same governance features running end to end in the Decube product tour.
Four checks, one for each breaking point. None of them needs a project.
Whatever those four checks return is your governance position in a modern data stack, and it will be more specific than any maturity score. If you want to see the four answers assembled in one place across your own connected sources, book a Decube walkthrough and bring the numbers with you.
Data governance in a modern data stack is the practice of holding a single answer to four questions about a table when the table is touched by five or six separate systems: who owns it, what class of data is in it, where it came from, and who read it. The definition of governance has not changed since the single database era. What changed is that no one system in the stack can answer any of the four questions on its own, so the answers have to be assembled in a layer that sits above the warehouse, the lakehouse, the transformation project, the BI tool and the agents.
Data governance controls the data: who owns a table, how it is classified, where it came from and who read it. AI governance controls the models and agents that act on that data: which models are in use, what they are allowed to touch, how they are tested and how their outputs are audited. They meet at one point. An AI system can only be governed as well as the data underneath it is governed, because an agent that reads an uncataloged table with no owner and no classification produces an answer nobody can trace. In practice a company needs both, and the data governance work has to be in place first.
Four things, and they are the same four an auditor would ask for. First, every table the agent can reach has a named owner who can be paged, not an empty owner field. Second, every column holding personal or regulated data carries a classification that the agent's access path respects, not just the warehouse console. Third, lineage that reaches the tables the agent actually queries, so you can say what a wrong answer was built from. Fourth, an access record showing which agent read which column, retained for at least as long as your auditor asks for. If any of the four is missing, the agent will still work, and that is the problem: it will be confidently right about a table that should never have been in scope.
For healthcare the deciding factors are not feature counts, they are where the data sits and what the platform can prove. Ask three things. Does the platform read metadata without copying the underlying records out of your environment, so protected health information never leaves your boundary? Does it hold the compliance attestations your security review will ask for? Does it keep an access record long enough for your retention obligation, rather than the shortest window your warehouse happens to offer? Decube is built for the first point, keeping customer data inside the customer environment, and publishes SOC 2, ISO 27001, HIPAA and GDPR compliance along with TLS in motion and AES-256 at rest. Weigh any vendor on those three questions before comparing feature grids.
The platforms most often shortlisted against Collibra are Decube, Alation, Atlan, Informatica and Microsoft Purview. They split into two groups. The older enterprise suites sell a governance program: workflow, stewardship and policy management, usually bought by a chief data officer. The newer platforms sell governance attached to the working stack: catalog, column level lineage, classification and quality monitoring that a data engineering team runs day to day. The right shortlist depends on which of those two problems you actually have.
Both are catalog first platforms, so the difference that matters in an evaluation is rarely the feature list. Compare them on three axes instead. How much of the metadata arrives automatically from your connectors versus how much a steward has to type. Whether lineage reaches column level and survives a rename in the source system. And how the platform is deployed relative to your data, because that decides your security review more than any other answer. Run the same three questions across every vendor on your list, Decube included, and the shortlist usually reduces itself.
Outside all of them, with read access into each. A governance layer that lives inside the warehouse cannot see the BI extract, and one that lives inside the BI tool cannot see the raw files. Three tests separate a real governance layer from a viewer built into one tool. Can it name an owner for an asset in a system you have not connected yet? Does its lineage survive a rename in the source? Can it answer who read a given column without you logging into the warehouse console?
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)