Why Databricks: one governed platform for all four layers.
We can implement the Governed AI Framework™ on what Azure, AWS and Google Cloud each provide natively. We implement it on Databricks: one platform, inside your own cloud, where the data, the models, the agents and the records they leave are governed by the same permission model. Here is how it carries each layer.
The workspace lives inside your cloud, on your network, under your identity.
Databricks deploys into your own cloud account, so the controls your cloud team already runs apply to the AI stack before any model is served.
- Your network, not a vendor’sThe workspace is deployed into your own virtual network on Azure, AWS or Google Cloud, with private connectivity for both the control plane and the data plane, no public IP addresses on compute, and IP access lists on the front door.
- Your identity, federatedUsers and groups are provisioned from your directory (Microsoft Entra ID, Okta or any SCIM-capable provider) with single sign-on; automation runs as service principals under token policies, never as a person’s credentials.
- Secrets out of codeCredentials live in secret scopes backed by your key vault; storage is reached through credentials and external locations bound to managed identities or roles, with customer-managed keys for encryption at rest.
- Compute you can policeCluster policies decide what may be created and how; serverless compute carries network and egress controls; the compliance security profile and enhanced security monitoring apply where your regulator asks for them.
- Audit to your SIEMAccount and workspace audit logs and the system tables stream to the security tooling you already run, so the AI stack is watched by the same people who watch everything else.
What you get to see: Posture evidence maps each of these to your cloud’s well-architected security guidance and to the Databricks AI Security Framework, the framework Databricks publishes for the risks of each stack component.
One permission model for data, models, functions and agents.
Containment on Databricks is not a policy document; it is Unity Catalog and the AI Gateway enforcing, in the request path, what an AI system may see, say and do.
- What it may seeUnity Catalog governs tables, files, models and functions in one hierarchy. Row filters and column masks decide which rows and which values a model or an agent can read; attribute-based access control applies the same rule everywhere a governed tag appears.
- What it may sayModel Serving endpoints sit behind the AI Gateway: rate limits per endpoint and per caller, guardrails that screen prompts and outputs for personal data and unsafe content, keyword and topic restrictions, and fallbacks when a provider fails. External models are reached through the gateway, so provider keys never leave it.
- What it may doAgents built with the Mosaic AI Agent Framework call tools that are registered as Unity Catalog functions, so an agent’s reach is a permission grant you can read and revoke. On-behalf-of-user authorization means the agent sees only what the person asking may see.
- What may leaveServerless network policies and egress controls decide where a workload may connect; data shared outward goes through Delta Sharing under the same catalog permissions; every inference is logged before it is returned.
What you get to see: The audit bundle for a workload shows the grants, the masks, the gateway rules and the inference log, checked against the OWASP Top 10 for LLM Applications.
The proof of concept runs here, and every decision it makes has a record, a lineage and a named owner.
Databricks records what the AI did as a by-product of running it, so the proof of concept shows its evidence as a query rather than a reconstruction.
- Lineage end to endUnity Catalog lineage follows data from source tables through notebooks, jobs and dashboards to the models trained on it and the endpoints that serve them, at table and column level.
- Inference tablesEvery request and response through a serving endpoint lands in a Delta table you own, with the caller and the timestamp, retained on your terms. That is the record a regulator, a customer or a union asks for.
- Models with a registry and a reviewerMLflow tracks every experiment; models are registered in Unity Catalog with versions, aliases and approval steps, so promotion to production is a decision by a named person, recorded.
- Evaluation, recordedAgents and models are scored before release and on a cadence with MLflow evaluation and LLM-as-judge scoring; the scores are stored beside the model they describe.
- Monitoring of the AI, never of peopleLakehouse Monitoring watches data quality, drift and model performance and raises alerts; the audit logs and system tables watch access and usage. What is monitored is the system.
What you get to see: The evidence log points at the lineage graph, the inference table, the registry entry and the monitoring dashboard, each one an artifact your auditor can open.
The tools your people use run here, in production, with a human decision where one is owed.
The same platform that governs the AI puts it in front of your people as a tool they operate, with a human decision where one is owed.
- Human-in-the-loop interfacesDatabricks Apps run inside the workspace, under the same identity and permissions, so an assistant’s recommendation is presented to the person who decides, and the decision is recorded with the recommendation.
- Self-service on governed dataAI/BI Genie lets a non-technical colleague ask questions of governed data in plain language, inside their own permissions. The capability moves to the person; the data stays where it is governed.
- Assistants with bounded toolsAgents built on the Mosaic AI Agent Framework act through the tools they are granted and stop where a human approval is required, so authority is delegated in measured steps rather than handed over.
- Output per person, measuredUsage and query history in the system tables, with the app’s own telemetry, measure what each person can now do that they could not before. That is the engagement’s metric, before and after.
- Skills with every deploymentNotebooks, governed sample data and the platform’s own training paths let your people run what we build; our staff trains them to do more, not less.
What you get to see: The augmentation map names the first workload, the people who use it, and the output-per-person measure the engagement is held to.
Certified where you run.
Databricks runs the same way on Azure, AWS and Google Cloud, and so do we. Our architects hold the platform’s architect credential on all three, each verifiable on the issuer’s site, and a certified data engineer is on staff.
- Platform Architect · Azure
- Platform Architect · AWS
- Platform Architect · Google Cloud
- AI Agent Fundamentals
- Certified Data Engineer Associate · on staff
If Databricks is not your platform. The four layers do not depend on it. We map Protect, Contain, Prove and Augment to the cloud’s native services (its network, identity, catalog, model serving, lineage and monitoring) and build the same evidence. The Pilot’s findings tell you, with a score, which path is shorter for you.