Do I need an AI gateway if I already have data governance?

Summary

• Yes, and for a different reason than you might expect. Data governance controls who can access which data; an AI gateway controls what models, tools, and agents actually do on every request. Having one doesn't remove the need for the other.
• On Databricks you don't run two separate systems. Unity Gateway extends Unity Catalog to AI, so models, tools, and agents become governed securables with the same role-based privileges you already use for tables.
• The gateway adds runtime controls that access policies can't see: per-principal rate limits, budgets and spend caps, usage tracking, and request and response logging to governed tables.
• Guardrails and service policies (in Beta) inspect each request and response, allowing, denying, or requiring approval for an action, detecting and redacting PII, and mitigating prompt injection.
• Every model, tool, and agent call takes one authorized, logged path, so the discovery, lineage, and audit you rely on for data now extend to AI.

Do I need an AI gateway if I already have data governance?

Yes. Data governance and an AI gateway answer different questions. Data governance decides who can access which tables, files, and AI assets. An AI gateway decides what a model, tool, or agent is allowed to do on each call, and at what cost. Access control has no visibility into a live model request or an agent's tool calls, so even a well-governed data estate leaves the AI layer ungoverned at runtime. On the Databricks Data Intelligence Platform you don't stand up a second system to close that gap: Unity Gateway extends Unity Catalog to models, tools, and agents.

What an AI gateway adds beyond data governance

Data governance is about static access: which principals can read a table or use an asset, enforced with role-based and attribute-based access control and backed by discovery, lineage, and audit. An AI gateway is about runtime behavior: every model call and tool invocation passes through it, policies are evaluated against the request before it runs, and the outcome is logged after. That is where cost control, guardrails, and per-request decisions live.

Governance layer	Question it answers	Examples
Data governance (Unity Catalog)	Who can access which data and AI assets?	Table, file, and volume permissions; RBAC and ABAC; discovery, lineage, audit
AI gateway (Unity Gateway)	What can a model, tool, or agent do on each call, and at what cost?	Rate limits, budgets, usage tracking, request and response logging, guardrails

The point isn't to choose between the two. You need access control to decide who gets to use a model, and you need gateway controls to govern what that model does once it's running.

How Databricks approaches AI gateway governance

Unity Gateway is built on Unity Catalog rather than beside it. Models, model services, external model providers, MCP services, and agents are registered as Unity Catalog securables, so you grant access with the same privileges you use for data: EXECUTE to call a model or tool, CREATE SERVICE to register a new one, and MANAGE to administer it. The discovery, lineage, and audit that already cover your tables now cover your AI assets.
On that shared foundation, the gateway adds runtime controls:

• Traffic governance (generally available). Set rate limits for a user, team, or agent; track token usage and latency in governed system tables; set budgets with spend caps that stop requests when a limit is reached; and split or fail over traffic across models. Read Unity Gateway is generally available.
• Inference logging (generally available). Request and response payloads are logged to governed Delta tables for monitoring, debugging, and audit, giving you one telemetry layer across model and tool activity. See how AI governance works on Databricks.
• Guardrails and service policies (in Beta). Evaluate each request and response to allow, deny, or require approval for an action based on the user, agent, model, or content; detect and redact PII; mitigate prompt injection; and gate which tools an agent can call. Read what's new with Unity Gateway service policies, guardrails, observability, and cost controls.

Because every call routes through one place, policy stays consistent across Databricks-hosted foundation models, external models, external tools and MCP servers, and agents. See governing AI agents at scale with Unity Catalog.

FAQs

Isn't strong data governance enough to cover AI?

No. Data governance controls access to data and assets, but it can't see or shape what a model or agent does on a live request. Rate limiting, budgets, request and response logging, and content guardrails are runtime controls that an AI gateway provides.

Does an AI gateway replace my data catalog?

No. On Databricks, Unity Gateway extends Unity Catalog rather than replacing it. AI assets become securables in the same catalog, governed with the same privileges, lineage, and audit as your data.

What can an AI gateway govern?

Access to and behavior of Databricks-hosted foundation models, external models, external tools and MCP servers, and agents, all through one authorized and logged path.

Is Unity Gateway generally available?

Yes. Unity Gateway is generally available, including AI assets as securables, rate limits, budgets, and inference logging. Guardrails and service policies are in Beta.