Databricks Mosaic AI Compliance: Build the Deployment Evidence File

Databricks Mosaic AI compliance begins with two files that answer different questions. The vendor file covers Databricks assurance, contracts, service scope, and reports. The deployment file proves how your team configured one use case, which identities and data it permits, where requests go, which tests ran, and who approved the current state.

Combining those files into a statement that "Databricks is compliant" loses the evidence an assessor needs. Compliance attaches to a defined service, configured for a defined use, under a control owner who can demonstrate that the controls still operate.

TL;DR

• Databricks publishes compliance materials and makes additional assurance reports available through its trust process.
• Unity Catalog can provide access control, classification, lineage, and audit activity for governed data and AI objects.
• Unity Gateway can govern model services, external providers, request policy, and usage records inside its routed scope.
• The enterprise evidence file still needs approved purpose, route ownership, data rules, operating tests, retention, change review, and exceptions.

Separate provider assurance from deployment evidence

The Databricks Security and Trust Center says customers can download a due-diligence package containing ISO certificates and an annual penetration-test confirmation letter. It also directs customers to their account team for the Enterprise Security Guide and SOC 2 Type II report. Those materials belong in the vendor file with the contract, data-processing terms, service description plus subprocessor review and accepted residual risks.

Report scope provides the first assurance checkpoint. Record the Databricks account and cloud, enabled regions, workspace list together with subscribed services and report period. Map each relied-upon control to the assurance document that actually covers it. A certificate logo on a procurement page provides less evidence than the report scope and an owner who reviewed the stated exceptions.

The deployment file starts where provider assurance ends. Name the use case and business owner. Add its users, source data, Unity Catalog objects, model services, external providers, network route, retention rule and output review, alongside risk tier. The AI vendor risk assessment template can structure the first file. The second file must reflect the live architecture.

Unity Catalog evidence needs a defined object scope

Databricks describes Unity Catalog as its governance layer for data and AI. The documentation says it enforces access controls, tracks lineage, logs activity and classifies data. Tables, functions, models, model services and MCP services can be governed as securable objects.

Use those securable object types as the compliance index. For a claims-summary agent, record the relevant catalogs and schemas, source tables, function tools, registered model, model service, service principal, user group together with governed tags and workspace bindings. Export the grants and the lineage view used in the review. Add the system-table query that retrieves audit activity for the same objects.

A screenshot dated September 22 proves one moment. A control needs a repeatable test. Save the query or script, expected result, reviewer and cadence, alongside exception workflow. Run the test with an approved identity and a role lacking access. Preserve both outcomes under the use-case ID.

I would rather give an auditor a seven-line query they can rerun than a 70-page controls deck that cannot reproduce one access decision. That is the difference between design evidence and operating evidence.

Unity Gateway defines a second compliance scope

The current Unity Gateway documentation says the service governs runtime interactions among models and agents, including MCP servers and tools. It can register AI services as Unity Catalog securable objects and route requests to Databricks-hosted models or external providers. Service policies govern those routes, while system tables support usage monitoring. The documentation also describes request and response logging to Unity Catalog Delta tables.

Translate those capabilities into a route register. For each use case, record the approved model service, external provider connection where present, allowed principals, service policy, fallback route, request tags together with logging destination and responsible team. A fallback deserves the same data and jurisdiction review as the primary route because traffic may move during an outage.

Service policies govern requests that reach the service. Preserve the policy source and version, deployment approval, attachment point, and a test case for each material rule. Record the result in a way that connects the principal and request tag to the selected model service. The AI audit-trail requirements by regulation offers a reference for evidence fields, but the Databricks deployment file should use the identifiers that your environment can retrieve.

Compliance ownership continues outside Databricks

A Mosaic AI deployment usually crosses several control domains. IAM establishes trusted human and service identities. Data owners approve classifications and source access. Platform engineering configures Unity Catalog and Unity Gateway. A model-risk or product owner validates intended use and output handling. Compliance determines retention and legal basis, alongside required notices. Internal audit tests the design independently where the risk warrants it.

Write that ownership into the use-case record. A field called "owner" with one platform engineer's name hides too much. Assign accountable owners for business use, data, model behavior, vendor oversight, route policy, with logs and exceptions. Include deputies for controls that need evidence during leave or an incident.

Change management is the next gap. A new foundation model, external provider, governed tag, fallback destination, system prompt plus tool connection and service policy can alter the compliance posture. Define which changes require reassessment. Link the approval ticket to the deployed object version and add the next test date.

The AI data residency controls provide a useful check for external provider routes. The deployment record should state the actual destination and contract rather than infer location from the Databricks workspace region.

A quarterly control test for Mosaic AI

Select one material use case and bring its owner, data steward, platform engineer together with compliance reviewer and audit representative into a 60-minute session. Display the route on screen for the reviewers. Show the originating identity and acting service principal. Then retrieve the Unity Catalog grants, service policy, route configuration and lineage, alongside relevant system-table events.

Run two requests against a production-like endpoint. The first uses an approved identity and allowed data class. The second violates one declared policy. Preserve the request identifiers, model route, policy version, decision, with event time and response handling. Compare those records with the expected outcomes written before the test.

Next, simulate one approved route change. Confirm that the workflow triggers reassessment, updates the route register, attaches the new policy or model version, and schedules a control test. A small red label reading "external fallback" on the architecture diagram can prevent a meeting from drifting into assumptions about residency.

Document every failed check in plain language. A missing join between a request tag and the originating user becomes a remediation item with an owner and due date. A policy attached to the wrong service becomes a configuration defect. Evidence should show closure through a rerun, rather than a note saying the team discussed it.

The compliance boundary for mixed routes

Databricks-native evidence is strongest for assets and traffic inside the configured Unity Catalog and Unity Gateway scope. A notebook that calls an external provider directly creates a different route. An application outside the workspace may also reach a model without passing through the selected gateway. Inventory those paths and assign controls instead of stretching one evidence set over all of them.

The compliance file should distinguish local model execution, HTTP model requests plus MCP activity and provider operations. It should also distinguish workspace administration from per-request policy. Each area has separate technical evidence and control owners.

DeepInspect addresses only authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. Local execution, STDIO, stolen credentials, endpoint compromise, provider training together with model weights and traffic that bypasses the proxy require other controls. This narrow boundary lets an assessor understand exactly which requests produced DeepInspect evidence.

DeepInspect

DeepInspect can sit on an approved HTTP model route as a stateless proxy. It evaluates application-supplied identity context and prompt classification against the policy for that route before forwarding the request, then creates a per-decision audit record outside the calling application's write path.

For a Databricks Mosaic AI use case, the record can include the originating identity and acting service principal, model route, data classification, policy version, decision and timestamp, alongside correlation ID. That evidence complements Unity Catalog grants and lineage, Unity Gateway configuration, provider assurance and enterprise control ownership. It covers only traffic sent through the proxy and never substitutes for the broader deployment file.

A compliance review should preserve one permitted event and one denied event alongside the policy under test. Book a demo today.