On May 19, 2026, Databricks announced a set of new capabilities for Unity AI Gateway: LLM-based guardrails, MCP payload logging, per-user cost controls, and service policies. The announcement positions Unity AI Gateway as "your single place to enforce governance across your entire AI estate."
It's a meaningful product move. It's also a statement worth reading carefully — because "your entire AI estate" is scoped more narrowly than most enterprise security and compliance teams assume.
What Databricks Built
The new Unity AI Gateway capabilities are genuinely useful for data engineering and ML teams running AI workloads inside the Databricks platform.
The guardrails replace rigid, pre-built filters with LLM-based policies configured using a model and a prompt, covering PII detection and redaction, content safety, prompt injection detection, and data exfiltration prevention. These run in real time on inputs and outputs to any model endpoint served through Databricks. Service policies let admins define who can call which MCP server, with fine-grained controls based on agent identity, user context, and request parameters.
The payload logging is particularly relevant for compliance teams: every request and response across model calls and MCP interactions gets stored as system tables in Unity Catalog, creating what Databricks calls "a centralized, queryable record of agent activity." That's a real, auditable trail.
One of the first design partners in the announcement, Definitive Healthcare's VP of Engineering, put it plainly: the company is "excited to deepen our partnership with Databricks and look forward to leveraging Unity AI Gateway to help us govern AI systems securely and at scale across models, agents, and tools."
This is what good API-layer AI governance looks like. The question for enterprise security teams is whether it's the layer they need to govern.
Who This Covers — and Who It Doesn't
Unity AI Gateway governs model calls that flow through the Databricks platform. Data scientists building pipelines. ML engineers deploying serving endpoints. Analytics engineers calling Claude or GPT-4 through the Databricks model serving API. Coding agents that invoke MCP servers to read from internal data systems.
That's a real population — and for organizations that have standardized AI development on Databricks, Unity AI Gateway brings meaningful governance depth to that surface.
But that population isn't where most enterprise AI compliance exposure actually originates.
The employees who create the most compliance risk with AI are rarely data engineers with structured API access. They're knowledge workers: HR managers, finance analysts, legal staff, customer success teams, clinical staff, procurement officers. These users are not calling the Databricks model serving API. They're opening ChatGPT in Chrome and typing. Or switching tabs to Claude. Or using Microsoft Copilot embedded in Word. Or asking Gemini to summarize a document they just uploaded.
Unity AI Gateway doesn't see any of that traffic — and that's not a product gap, it's a scope decision. The product is an API governance layer for the Databricks data plane. Browser-based submissions to external AI services are structurally outside that perimeter.
The Compliance Architecture Mismatch
This distinction matters when you map it against what enterprise compliance regimes actually require.
SOC 2 Trust Services Criteria — specifically CC6.6 and CC6.7 — require that you restrict external access to data in a way that's actually enforced and that you monitor for unauthorized data disclosure. An organization that governs its data engineers' API calls through Databricks but leaves the rest of the employee population free to paste sensitive data into external AI tools has a CC6.7 finding waiting to happen.
GDPR Article 32 requires "appropriate technical and organizational measures" to ensure the security of processing. If an employee pastes EU personal data into ChatGPT, that's processing — and if the organization has no technical control over that channel, the Article 32 coverage question becomes difficult to answer in front of a supervisory authority.
HIPAA's Security Rule (45 CFR §164.312) requires access controls and audit controls for electronic protected health information. An ePHI submission to an external AI chatbot is a potential breach, regardless of how well-governed your Databricks data pipelines are. Databricks Unity AI Gateway has no visibility into that submission.
The same structural mismatch applies to NYDFS Part 500, GLBA, CCPA, and the emerging state AI laws. These regimes ask where your organization's sensitive data goes — not just where it goes through your managed API endpoints.
Two Governance Layers, Not One
The reason Databricks Unity AI Gateway is a good product and an incomplete enterprise governance story isn't a flaw in execution. It reflects a broader architectural gap in how enterprise AI governance is being built.
Most AI governance investment in 2026 is concentrated on the development layer: guardrails on model APIs, controls on pipelines, policies on agentic frameworks. That matters. But sensitive data leaks in enterprise environments don't primarily happen in pipelines. They happen in the five-second decision to paste something into a chat window.
A complete enterprise AI governance architecture needs both layers:
API-layer governance — controlling what your development and engineering systems do through model APIs, enforcing guardrails, logging MCP interactions, attributing costs. This is what Unity AI Gateway is built for.
Browser-layer enforcement — intercepting and evaluating what employees submit through AI chat interfaces before it leaves the browser — before ChatGPT, Claude, Gemini, or Copilot receives it. This requires a different technical approach: a browser extension that sits at the point of submission, checks the content against your organization's policies, and blocks or logs the interaction in real time.
Without the second layer, the first layer monitors the structured, deliberate AI usage of your technical teams. Your knowledge workers' informal AI usage — the surface where most sensitive data exposure occurs — goes completely uncontrolled.
What to Look for in an Enterprise AI Governance Stack
The Databricks announcement is a useful prompt for enterprise security and compliance teams to map where their current AI governance actually has coverage.
Questions to ask:
- Do you have visibility into which AI tools employees use in their browsers — and what they submit to those tools?
- Are your governance policies applied at the browser layer, not just the API layer?
- When an employee pastes a customer contract into ChatGPT, does your security stack know about it?
- If your auditor asks for an audit log of all sensitive data submitted to external AI services, what does that log look like?
If your answer to any of these is "we handle that through our data platform controls," the gap is likely larger than you think. Data platform controls cover the AI usage you've formalized. They don't cover the AI usage your employees discovered on their own.
Databricks shipping LLM guardrails for the data plane is a good signal for the enterprise AI governance market. It means that organizations are starting to treat AI governance as an engineering discipline, not just a policy document. The next step is extending that discipline from the managed API surface to the place where most employees actually interact with AI — the browser.
Containment.AI enforces AI governance policies at the browser layer and the API proxy layer. See how it works →