Ask a data leader why AI projects move more slowly than expected, and the answer is often the same: code is rarely the bottleneck, data is.
Code usually lives in a relatively small, known set of repositories and follows a familiar security pattern: verify who is making the request, confirm that they have permission, and run the program. Data is different. The same table may be queried in a SQL editor, displayed in a BI dashboard, analyzed in a notebook, moved through a nightly pipeline, or included in an AI agent’s response. Historically, each of those access points required its own security controls.
That fragmentation shaped how data security was built. Organizations generally had to solve two related but separate problems: deciding which records a person could see and deciding which fields within those records they could see.
Row-level security controls access to particular records, for example, allowing a regional manager to see only customers in their own territory. These rules were often written as filters or database views, one table at a time, and then embedded in whichever tool ran the query. Column-level security was usually managed separately, masking or hiding sensitive fields such as salary, Social Security number, or medical information through another set of table-specific rules.
Moving to a new BI tool or building a new data pipeline often meant recreating both kinds of controls. Once the same policy existed in five places, keeping all five versions consistent became a continuing operational risk. That is the problem Databricks built Unity Catalog’s access-control model to address: applying a consistent policy to the data itself, rather than rebuilding that policy in every tool that accesses it.
Row filters and column masks can be enforced consistently across Databricks SQL, notebooks, jobs, and connected BI tools, without custom logic for each access point. The underlying capability reached general availability in 2026 as Attribute-Based Access Control (ABAC). With ABAC, policies are defined centrally at the catalog or schema level and evaluated dynamically using governed tags, rather than configured table by table. In practical terms, an organization can classify a column once and apply the appropriate controls wherever that data is used. The relevant row filter or column mask is then enforced whether the request comes from a SQL query, dashboard, notebook, scheduled job, connected BI tool, or AI agent.
The architectural shift is simple but consequential: policy is managed once in the catalog instead of being recreated and maintained separately across every data-access tool.
Graph depicting the traditional approach versus Unity Catalog’s centralized governance model.
Why This Is a Value Question, Not Just a Technical One
The value is not simply writing less code. It is reducing a costly and persistent business risk: policy drift, the gap between what a data policy is intended to do and how it is enforced across the systems that access the data.
That problem is widespread. McKinsey’s 2023 Master Data Management Survey found that 80% of responding organizations had at least some divisions operating in data silos, with separate data-management practices, source systems, and ways of using data. Only 29% reported that their master-data systems were fully connected both to the systems where data originates and to the business applications that use it, while also having the governance and stewardship roles needed to maintain those connections.
McKinsey’s research measures overall data-management maturity rather than security alone. But it describes the condition that makes data security difficult: the same rule must be rebuilt, maintained, and verified across disconnected systems.
The alternative is a shared metadata and policy layer: a common way to classify data and apply consistent rules wherever it is used. In Databricks, Unity Catalog provides that layer by centralizing metadata, permissions, and governance across data, analytics, and AI workloads. Through governed tags, organizations can classify sensitive or important data once and apply related policies consistently as the data moves into dashboards, notebooks, pipelines, business applications, and AI agents.
That common layer creates value beyond access control. A tag that applies a masking rule to a column can also attach data-quality expectations to it. Once a financial or operational-data column is tagged, automated checks can monitor it for unexpected changes, missing values, or other anomalies. Security policies help determine whether someone is authorized to access the data; quality policies help determine whether that data is reliable enough to use.
The same metadata foundation also makes AI-generated documentation genuinely useful moving forward. Databricks can suggest table and column descriptions based on schema and usage patterns, while the metadata and governance layer provides the context that makes those suggestions meaningful. Databricks reports that more than 80% of table-metadata updates on its platform are now AI-assisted. The result is a reinforcing cycle: better metadata improves AI-generated documentation; better documentation makes metadata easier to maintain; and richer, more current context improves the reliability of every downstream consumer, from dashboards and reports to data pipelines and AI agents.
Why dbSeer
dbSeer’s team spent years implementing the older model before a governed alternative existed. That meant hand-coding row filters and column masks across BI tools such as Power BI, Logi Symphony, Tableau, and Qlik, then connecting those rules to underlying databases including PostgreSQL, SQL Server, and Redshift. The comparison is not theoretical: dbSeer has firsthand experience maintaining the “same policy in five places” problem that Unity Catalog is designed to reduce.
That experience informs how dbSeer delivers Databricks platforms today. Across prior engagements, dbSeer has built governed data platforms that combine managed pipelines, Unity Catalog access controls, and analytics experiences on a common foundation. The goal is not merely to make data available. It is to establish from the outset clear rules for who can access which data, how that data is defined, and how it can be used safely across reporting, analytics, and AI.
That foundation-first approach is central to dbSeer’s work on Databricks. Rather than treating governance as a control added after a platform goes live, dbSeer incorporates it into the architecture, data model, and operating model from the beginning.
At ATCS, for example, dbSeer implemented a Databricks lakehouse on AWS, connected previously separate systems, and established Unity Catalog as the platform’s governance layer. That approach enabled role-based access while creating a governed foundation for analytics and future AI use cases.
As a Databricks Consulting Partner, dbSeer’s differentiator is not simply platform implementation or migration. It is full-lifecycle delivery: translating a business need into an architecture, building the platform, and helping clients operate and evolve it after launch. Governance remains effective only when someone continues to own the policies, metadata, access model, documentation, and data-quality practices.
Reach out to us today to help you move forward with Databricks.
