What You Need to Know
An AI governance framework is the set of controls that tells you what data, models and agents you run, who owns each one, who and what can read it, where its outputs went and what it decided. For a mid-market team, the practical version is eight controls built on one governed lakehouse, with Unity Catalog doing the inventory, access, lineage and audit work.
- Effort: the first working version takes weeks, not a year, if the data already sits in one catalog.
- Cost: most of the mechanics ship with Unity Catalog; the real spend is engineering time and ownership discipline.
- Risk: the biggest gap is data outside the catalog, where no lineage or log exists.
- Fit: it pays off first where AI touches hiring, lending, housing, insurance or health decisions.
Colorado’s replacement AI law, SB 26-189, takes effect on 1 January 2027 and requires developers and deployers to retain records necessary to demonstrate compliance for at least three years. That is a data engineering requirement dressed as a legal one. Somebody has to decide which records, in which table, kept by which job.
The platform defaults do not cover that on their own. The Databricks audit log system table, system.access.audit, is in Public Preview with a default retention of 365 days, and longer retention is configurable only through a separate Beta setting. One year of logs against a three-year duty is the kind of gap a governance framework exists to close.
Most mid-market teams I meet share three problems. Data sits in silos, so nobody can produce one inventory. Models live in notebooks and agents read raw systems, so nobody can say who approved what. Logs are scattered across tools, so an auditor’s first question becomes a scramble.
Why Most AI Governance Stalls at the Policy Document
The usual first move is a policy. The policy is fine; it fails because nothing in the data platform enforces it. “Only approved models touch customer data” means nothing if you cannot list the models, the customer tables, or the path between them.
As a Lean Six Sigma Master Black Belt, I read governance as a process with defects. The defect is an unmeasured process: data moves through orchestration nobody documented, and outputs land in spreadsheets nobody tracks. You cannot control what you cannot see, and you cannot see across silos.
So this framework starts in the lakehouse, not a policy binder. Put data, models and agents under one catalog, and most of the evidence an auditor asks for becomes a query. We use the same sequence in our AI implementation framework: fix and map the process first, then automate the controls.
The Eight Controls of a Working AI Governance Framework
Build these in order. Each one depends on the one before it.
1. Inventory data, models and agents in one catalog
Start with a list you can query. Tables, views and volumes register in Unity Catalog as they are created. Models in Unity Catalog extends the same catalog to ML models, with centralized access control, auditing, lineage and discovery across workspaces. Model aliases, such as a “Champion” alias pointing at the production version, tell you which version is live without reading deployment code.
Agents need the same treatment. Register every agent, its purpose, the model it calls, the tools it can use and the tables it reads in a governed inventory table. An agent that is not in the inventory is shadow AI, whatever vendor built it.
2. Classify what is sensitive
Classification turns “customer data” into something a policy can act on. Unity Catalog’s governed tags and automated data classification reached general availability on 13 May 2026, alongside attribute-based access control, according to Databricks’ announcement. Let classification propose tags; a named data owner confirms them.
3. Assign an owner to everything
Unity Catalog’s ownership documentation is blunt: all securable objects have an owner, and owners hold all privileges, including the right to grant access. Set owners to groups, not individuals, so ownership survives a resignation. Then write the business owner into a tag. Technical ownership says who can grant access; business ownership says who answers for the decision.
4. Control access for people and for agents
Grant access by attribute, not table by table. ABAC policies for row filtering and column masking read the governed tags from step 2, so a column tagged as sensitive is masked everywhere the policy applies. Give each agent its own service principal with the narrowest grants it needs, instead of letting it run on a developer’s personal token.
Microsoft’s Copilot documentation states that an agent does not grant a user access to data the user is not otherwise authorized to access. The corollary is the part teams miss: an agent inherits every over-broad grant you already have. Least privilege in the catalog is the agent control. For the model-side guardrails, see our notes on RAG guardrails.
For models and agents that call external LLMs or MCP servers, Databricks’ Unity Gateway reached general availability on 4 August 2026 as the governance layer for models, agents, MCP servers, skills and tools. Treat its MCP-server governance as Beta until you confirm otherwise in the current release notes.
5. Capture lineage, and find where it breaks
Per the lineage documentation, Unity Catalog captures lineage automatically for queries run on Databricks, down to the column level. The gaps are specific: column-level lineage is not captured through UDFs, or when a table is referenced by path instead of by name. Exports to spreadsheets or outside tools leave the graph entirely, so ban path references in production and route exports through a logged job.
6. Write a decision record for every automated decision
Lineage tells you where data went. It does not tell you what the model decided about a person. For that you need a decision record table in the gold layer: decision ID, a pseudonymised subject key, decision type, model name and version, a pointer to the input snapshot, the output, any notice sent, the human reviewer and the appeal status.
Snapshot the inputs explicitly. Delta time travel only reaches as far back as your VACUUM settings allow, so it is not a three-year archive. Write the record inside the Lakeflow Jobs task that scores the model, so a decision without a record cannot happen.
7. Keep audit logs as long as your rules require
Query system.access.audit for who read, changed or granted what. Because the table is Public Preview with a 365-day default, copy the events you need into your own Delta table on a scheduled job, with retention set by your longest applicable rule. Our guide to Databricks system tables covers the queries.
8. Run a control plan
This is where Lean Six Sigma earns its place. For every control, define the metric, target, owner, check frequency and reaction plan. Examples: share of production tables with a confirmed owner, agents outside the inventory, decision records missing a model version. Publish them on one gold-layer dashboard. A control nobody measures decays within a quarter.
How the Framework Maps to the NIST AI RMF
The NIST AI Risk Management Framework is voluntary, and it organizes AI risk work into four functions: Govern, Map, Measure and Manage. NIST describes Govern as a cross-cutting function that enables the other three. Map frames the risks, Measure analyzes and monitors them, and Manage allocates resources to them.
NIST does not prescribe Unity Catalog or any tool. The mapping below is ours: it shows which function each control mostly serves and what evidence falls out of it.
| Control | NIST AI RMF function | Lakehouse mechanism | Evidence it produces |
|---|---|---|---|
| Inventory | Map | Unity Catalog tables, Models in Unity Catalog, agent inventory table | One queryable list of data, models and agents |
| Classification | Map | Governed tags, automated data classification | Tagged sensitive columns with a confirming owner |
| Ownership | Govern | Object owners set to groups, business-owner tag | A named accountable team per asset |
| Access for people and agents | Manage | ABAC row filters and column masks, service principals, Unity Gateway | Grants and policies you can export and review |
| Lineage | Map, Measure | Automatic column-level lineage | Source-to-output trail for a table or model |
| Decision records | Measure, Manage | Gold-layer decision table written by the scoring job | Per-person record of what was decided and by which model version |
| Audit logs and retention | Measure | system.access.audit copied to a retained Delta table | Who read, changed or granted what, and when |
| Control plan | Govern, Manage | Metrics dashboard on the gold layer | Trend of control health with owners and reaction plans |
One Evidence Base, Several Rules
The reason to build this once is that the same records answer several rules. Colorado’s SB 26-189 covers automated decision-making technology used in consequential decisions about education, employment, housing, lending, insurance, health care and government services. It requires notice before use, a plain-language explanation within 30 days of an adverse outcome, a right to request human review, and three years of records. Your inventory, decision records and retained logs are that evidence.
California‘s CCPA regulations on automated decision-making, according to law-firm summaries of the final text, require notice, opt-out and access-request handling for significant decisions by 1 January 2027. The same decision table, joined to consumer identity data, makes an access request answerable.
In the EU, the Article 50 transparency obligations have applied since 2 August 2026, and the Digital Omnibus moved the application date for Annex III high-risk systems to 2 December 2027. What changes per rule is the retention period, the notice wording and who gets told.
None of this makes you compliant by itself. It produces the evidence a compliance review needs, and it turns each new rule into a change to one lakehouse rather than a new project in a new silo.
Where These Programs Break Down
The failure I see most is scope: teams try to govern every table on day one, stall on tagging thousands of objects, and quietly give up. Start with the data behind a consequential decision or an agent. The second is ownership by committee, where an AI council approves things but no group owns a table, so grants pile up and nobody revokes them. The third is governing the lakehouse while the risky flows run elsewhere, through a spreadsheet export, a personal API key or a SaaS agent wired straight to a CRM. Lineage stops at the catalog boundary, and so does your evidence. The last is treating the audit log as done without checking its preview status and retention. Each of these is a process defect before it is a tooling gap, which is why we map the workflow first and automate second.
Build, Buy or Wait: The Signal That Decides Each
Build it on your lakehouse when your regulated data and your AI workloads already run on Databricks, or will within a quarter. The deciding signal: more than half of the data feeding your models already sits in Unity Catalog. A separate tool would add a second inventory to reconcile.
Buy a dedicated governance or GRC tool when your AI runs across many platforms you do not control and your main need is policy workflow, attestations and vendor risk. The deciding signal: your auditors ask for sign-off trails more than for data evidence. Even then, feed it lineage and logs from the lakehouse.
Wait only when no model or agent touches personal data or a consequential decision, and none will before 2027. The deciding signal: an honest inventory returns nothing in scope. If you cannot produce that inventory, you are not in a position to wait.
If the build path fits, our AI governance and compliance work starts with an assessment of your inventory, owners and logs, then builds the eight controls on your lakehouse. This article is general information, not legal advice; your counsel or a qualified assessor makes the compliance call.
Frequently Asked Questions (FAQs)
What is an AI governance framework?
It is the set of policies and working controls that govern how an organization builds, buys and runs AI: inventory, classification, ownership, access, lineage, decision records, audit logs and a control plan.
Is the NIST AI RMF mandatory?
No. NIST describes the AI Risk Management Framework as intended for voluntary use. Teams adopt its four functions as a structure because auditors recognize it.
Does Unity Catalog make us compliant with AI regulations?
No tool does. Unity Catalog supplies inventory, access policies, lineage and audit data as evidence; counsel or an assessor decides whether your controls meet a rule.
How long should we keep AI audit logs and decision records?
Set retention by the longest rule that applies to you. Colorado’s SB 26-189 requires compliance records for at least three years, while the Databricks audit system table defaults to 365 days, so copy what you need into your own retained tables.
How do we govern AI agents that read company data?
Give each agent its own identity with narrow grants, register it, and log what it reads. Agents inherit existing permissions, so tightening catalog access is your most direct control.
Where does data lineage break in a lakehouse?
Column-level lineage is not captured through UDFs or path references, and it stops when data leaves for spreadsheets or outside tools.
Where should a mid-market team start?
Start with the inventory and ownership of the data that feeds a consequential decision or an AI agent. Every later control builds on those two.