Databricks can keep hosted-model requests in-region—but that promise does not automatically follow external endpoints

The control is narrower than the gateway

Databricks’ new public-sector guidance makes a useful distinction that can disappear in an architecture diagram: Unity Gateway can govern models from multiple providers, open-source models and external endpoints, but its geography guarantee is stated specifically for Databricks-hosted foundation models. Account administrators can require those requests to be processed within the workspace’s geography; if a model is unavailable there, they can choose whether to permit processing elsewhere.Databricks public-sector guidance

That is a strong control, but it is not a blanket claim that every request routed through the gateway stays in-region. An external endpoint remains an external processing route. Teams should document that provider’s endpoint location, logging, retention and failover behavior separately rather than treating the gateway’s policy as inherited proof.

What Unity Gateway centralizes

Databricks says administrators can control which models, coding agents, MCP servers and AI tools are available and who may use them. The same guidance describes budgets and hard caps by user, team or use case, plus request-level attribution, token usage, costs and tool activity in unified traces.Databricks public-sector guidance

The product page positions Unity Gateway as the common layer for cost and security controls and links its operational documentation.Unity Gateway product page

For data agents, that centralization matters because a single user question may trigger model calls, retrieval and tool execution. A trace can show which route was taken; it does not by itself prove that every downstream service met the same residency rule.

Build a route-by-route evidence table

Before approving a production data agent, record four fields for every permitted route:

1. Processor: Databricks-hosted model, external provider or self-managed endpoint.
2. Allowed geography: the configured region and any exception path.
3. Data surface: prompt, retrieved rows, schema metadata, tool output and trace data.
4. Evidence owner: the team responsible for provider terms, endpoint configuration and periodic revalidation.

Then test the policy with the same identity and tool permissions used in production. Verify that a disallowed model is blocked, that an unavailable in-region model does not silently fall back elsewhere, and that traces identify the selected route. Databricks says administrators may explicitly allow out-of-geography processing when a hosted model is unavailable, so that exception should be treated as a reviewable decision, not a harmless default.Databricks public-sector guidance

The practical takeaway is simple: a gateway can centralize enforcement, but residency evidence still belongs to each processing path. Approve the route, not merely the gateway.