Unity Catalog has solved data governance. The next challenge for enterprise AI is business context.
What Unity Catalog already does brilliantly
For any enterprise running AI workloads on Databricks, Unity Catalog is the foundation everything else depends on. It has genuinely solved a hard problem: applying one consistent governance model across every kind of asset in the Lakehouse.
Access control is unified — tables, files, models, and agents are all governed under a single permission model, rather than a patchwork of tool-specific rules. Lineage is tracked automatically, so teams can trace exactly where any dataset, metric, or model input came from. AI governance extends the same policies to models and agents, not just raw data. And because all of this runs natively on Databricks compute, there is no separate system to configure, secure, or audit.
For most organizations, this took years to get right. It is not an exaggeration to say that Unity Catalog is one of the most important reasons enterprises trust Databricks as their system of record.
What Unity Catalog was never designed to govern
And yet, walk into any large enterprise running AI on Databricks today, and a familiar frustration shows up. Teams ask their AI assistant a business question and get a confident answer but a colleague looking at the same underlying data, through a different tool, gets a different number.
Unity Catalog governs who can access data brilliantly. What it doesn't govern is what that data means.
That is not a governance failure. It is a different problem entirely. Unity Catalog was built to control access, not to define business meaning. It can tell you precisely who is allowed to query the supplier table. It cannot tell you what your organization means by "at-risk supplier" and whether that definition is the same in operations, procurement, and finance.
This is the gap where enterprise AI initiatives quietly stall. Not because the data isn't governed. Because the meaning behind the data was never defined consistently in the first place.
A question that shows the gap
The question a plant manager actually asks: "Which suppliers are putting next month's production at risk because they supply components used in critical assemblies?"
Answering that well requires connecting several things that live in different systems and mean different things to different teams: which suppliers are behind schedule, which components those suppliers provide, which assemblies depend on those components, and which of those assemblies are tied to committed production runs.
Without shared business context, answering this requires a data engineer to hand-write a complex query joining half a dozen tables and the definition of "critical assembly" they use may not match the one the operations team already has in their head. Ask the same question next quarter, in a different tool, and the answer may not match either.
With Shared Business Context in place, that question can be asked directly — in Genie, in a dashboard, or by an agent — and answered consistently, because "supplier," "component," "assembly," and "critical" are defined once, the same way, everywhere they are used.
Kobai: the Business Context Layer that extends Unity Catalog
Kobai helps enterprises create, govern, and operationalize context on Databricks. It is not a separate platform and does not introduce a new copy of your data. The Business Context Layer runs directly inside the Databricks Lakehouse, and it inherits Unity Catalog governance automatically — the same access policies your team already manages extend to every business context query, with no separate configuration.
Domain experts — not just data engineers — define the business entities, relationships, and rules that matter: what a supplier is, how components map to assemblies, which relationships are safety-critical. Kobai's Precursor tooling helps map that context to existing Databricks data quickly, keeping domain experts in control rather than routing every change through an engineering backlog.
The result is Enterprise Context that is defined once and reused everywhere — by Genie, by AI/BI dashboards, by agents, and by any application built on the Lakehouse.
|
Without Shared Business Context |
With Databricks + Kobai |
|
Each team encodes "supplier risk" or "critical assembly" separately, and the definitions drift. |
Business Context Layer defines these once and reuses them everywhere they are queried. |
|
Cross-domain questions require custom engineering work per use case. |
Cross-domain questions can be asked directly, reducing incorrect assumptions in the answer. |
|
Governance must be reconfigured for every new tool or reporting layer. |
Unity Catalog governance extends automatically to every Business Context query. |
|
AI outputs are difficult to explain, because the reasoning behind them isn't visible. |
Business relationships behind an AI answer are governed and traceable, improving explainability. |
Where this leaves Databricks customers
Unity Catalog gave enterprises a single, trustworthy governance model for their data. That was the hard problem of the last several years. The hard problem now is making sure the AI reasoning over that governed data actually understands the business behind it.
Governance without shared meaning is only half the solution.