Unity Catalog governance for AI becomes real only when policy changes what teams can do in production. The live Databricks Generative AI Engineer Associate exam treats governance as part of the application lifecycle, and Databricks has extended that model beyond tables and models toward prompts, functions, agents, MCP services, and runtime AI access through Unity Gateway. The architectural question is therefore not whether governance objects exist; it is who owns the decision, what evidence supports it, and how exceptions are handled when delivery pressure arrives.
The general principles behind role-based access control are necessary but not sufficient. AI systems may read governed data, invoke models, call tools, publish prompts, and send information to external providers. A user who can query a table should not automatically be able to expose that table to an agent, and an agent that can call one tool should not inherit administrative access to every integration.
A useful operating model separates asset governance from runtime governance. Unity Catalog defines controlled assets and privileges; Unity Gateway can govern model and tool access at runtime; application teams still own the business purpose, evaluation evidence, and safe behavior of the system that uses those capabilities. Governance works when those layers reinforce one another.
Ownership must be named at the decision level
Catalog administrators can manage platform permissions, but they should not decide which customer-support data is appropriate for an AI assistant or which model may be used for a regulated workflow. Those choices require business and risk owners who understand the consequence.
Define ownership for data sources, models, prompts, tools, evaluation datasets, serving endpoints, and the production application. Shared ownership can work when decision rights are clear; vague shared ownership usually means nobody is accountable when a risky exception persists.
Escalation should follow the decision. A permission error belongs to platform operations; an unclear business-use policy belongs to the data or product owner; a quality regression belongs to the application team. Governance becomes faster when issues are routed to the owner who can actually change the outcome.
Decision rights should also include who can approve a new external model provider or MCP integration. Those choices can alter data residency, privacy, cost, and incident ownership even if the Unity Catalog objects themselves remain unchanged. Record the business purpose, approved data classes, responsible product owner, and expiry or review date so runtime expansion does not outpace governance.
Privileges should express the minimum useful relationship
Grant access to the catalog, schema, table, model, function, or other object at the level required by the workload. Avoid broad workspace or catalog privileges merely because an application spans several assets.
Service principals and agent identities deserve the same scrutiny as human users. A backend credential that can read every customer table undermines per-user restrictions even if the front-end application has excellent authentication.
Review inherited and group-based access from the perspective of the sensitive asset. The effective privilege is the result of all grants, not the smallest role name visible in one policy screen.
Privilege design should account for separation of duties. The team that owns an AI application may need EXECUTE or USE rights without needing MANAGE on the governed schema, while platform operators may manage infrastructure without being allowed to read sensitive source rows. Keeping those roles distinct reduces the risk that operational convenience becomes a broad data-access path.
Runtime AI access adds a second policy surface
AI applications can call Databricks-hosted or external models, MCP servers, tools, and APIs. Runtime governance needs to answer which identity can call which service, under which rate or cost constraints, and with which guardrails.
Model access is not equivalent to data access. A user may be allowed to use a model while the application must still restrict which governed data can enter the prompt.
Tool access is even more consequential when the tool changes state. A read-only search tool and a ticket-deletion tool should not share the same approval or credential model simply because both appear in one agent catalog.
Runtime rate limits and cost controls are also governance choices. A model can be approved for use and still require per-team budgets, token ceilings, or request quotas so one experiment cannot consume the capacity or spending envelope of a shared platform. Exceptions to those limits should follow the same named-owner and review model as permission exceptions.
Evidence should prove governance is working
Useful evidence includes privilege changes, denied access, model and tool usage, cost attribution, policy exceptions, audit events, owner reviews, and application traces showing which governed resources participated in a request.
The monitoring principles behind logging and monitoring matter because a policy that cannot be observed is difficult to distinguish from a policy that is merely documented.
Metrics should answer governance questions: how many production agents use broad service credentials, how many exceptions lack owners, which prompts or models are unused, how long denied-access incidents take to resolve, and whether runtime guardrails are being bypassed.
Audit evidence should preserve the effective principal. When a user acts through an application identity, the system should retain enough attribution to distinguish the end user, application, and downstream model or tool. Without that context, a governance review can prove that one service principal acted but cannot prove whose business request caused the action.
Data quality is governance when AI consumes the data
The ownership discipline in data-quality accountability becomes part of AI governance because an agent can amplify stale, duplicated, or incorrectly classified data into many user-facing responses.
Catalog metadata can describe lineage and ownership, but business teams still need quality expectations for authoritative sources. A governed table with poor data is governed poor data.
Use quality incidents to test the ownership chain. When an AI answer is wrong because a source was stale, the response should not end with a prompt fix if the real defect belongs to the source system.
Data classification should influence which AI paths are allowed. Public documentation, internal operational data, customer records, and regulated data may require different models, regions, tools, or retention. Unity Catalog metadata can help describe sensitivity, but policy needs an explicit rule that turns classification into a runtime restriction.
Exceptions need reasons, scope, and expiry
Teams will encounter legitimate exceptions: temporary access during migration, external model use for one experiment, a tool that needs broader scope for a narrow operation, or an emergency production fix.
Record who approved the exception, which asset or runtime path it affects, why the normal policy is insufficient, and when it must be reviewed.
Exception volume is itself a governance metric. If every team requires the same exception, the baseline policy or platform design may be wrong. Governance should learn from recurring friction rather than treating each case as unrelated.
Exception workflows should include compensating controls. If an agent temporarily needs broader read access, require stronger logging, narrower time limits, or an approval checkpoint around state-changing tools. An exception is safer when the design states how the extra risk is contained instead of merely recording that someone accepted it.
Incentives can undermine perfect policy
If the governed path takes days while an unmanaged API key works in minutes, teams will create shadow AI. Security and platform teams need to make the compliant path usable enough that engineers choose it during normal delivery pressure.
Chargeback, quotas, rate limits, and approval gates should align with product value. A team should understand why a model is restricted or why a high-cost endpoint requires approval rather than seeing governance as arbitrary friction.
Centralized secrets management is an example of a control that works best when the secure path is also easier than copying credentials into notebooks or configuration files.
Incentives also include cost allocation. When one team pays nothing for broad model usage while the central platform absorbs the bill, there is little reason to optimize prompts, model choice, or tool loops. Showback or quotas can align engineering choices with shared-resource reality without turning governance into a finance-only exercise.
Review cadence should follow risk and change
A stable internal summarizer may need periodic review. A customer-facing agent with external tools and sensitive data deserves more frequent access, quality, and cost review.
Trigger reviews after ownership change, model-provider change, new tool integration, data-classification change, security incident, or material expansion of user population.
Governance should also retire unused assets and privileges. Old prompts, endpoints, service principals, and external integrations accumulate risk when nobody removes them after experiments end.
Review cadence should follow evidence, not a calendar alone. A sudden increase in model spend, repeated denied-access attempts, new external tool registrations, or rapid growth in broad service-principal permissions should trigger review immediately. Scheduled review remains useful for quiet systems, but event-driven review catches meaningful drift sooner.
A governed AI system can explain its decisions
Pick one production request and trace the user identity, application identity, data sources, model, prompt, tools, privileges, policies, cost controls, and audit evidence involved.
If the team cannot explain why that request was allowed, which owner approved the path, and how the system would respond if one component became untrusted, the governance program is still mostly documentation.
Unity Catalog and Unity Gateway provide control surfaces; operating discipline comes from ownership, measurable evidence, narrow privileges, review, and a process for exceptions that does not quietly become the default.
A mature governance test should include deliberate misuse. Attempt to call an unapproved model, access data outside the agent’s role, exceed a rate limit, invoke a restricted tool, and reuse an expired exception. The control should deny or constrain each path and leave enough audit evidence for another operator to explain exactly why.
