An AI governance framework is four answers you can query

On 24 July 2026 the EU published Regulation (EU) 2026/1744, which moved its own AI Act deadline. Obligations for high-risk systems, due on 2 August 2026, now apply from 2 December 2027. Two months earlier Colorado had repealed its 2024 AI Act and replaced it with SB 26-189, which starts on 1 January 2027.

If your AI governance framework was a project plan pointed at a date, you've rewritten it twice this year. If it was a set of controls that record who used which model on what data, nothing about it changed.

What follows won't tell you whether your system is high-risk under the EU AI Act. That's a question for your counsel, and the answer changes what you owe, not what you should build.

The three documents, read closely

Most writing on this blurs three different kinds of document together. They aren't the same kind of thing, and the difference decides how much weight each one carries in a meeting with your auditor.

NIST AI RMF 1.0 (NIST AI 100-1, January 2023) is voluntary guidance. It organises AI risk work into four functions. Govern is the cross-cutting one, "infused throughout AI risk management". Map "establishes the context to frame risks". Measure is the analysis and monitoring, and Manage allocates resources to the risks the other three found. Under those sit 19 categories and 72 subcategories. In July 2024 NIST added a Generative AI Profile (NIST AI 600-1) that names 12 risks specific to generative systems, confabulation and information integrity among them. Nobody certifies you against it, and US federal work and a lot of procurement questionnaires borrow its vocabulary anyway.

ISO/IEC 42001:2023 is a management system standard, the AI equivalent of ISO 27001, and you can be certified against it. It asks you to run an AI management system with policy, roles, risk assessment and improvement, and its Annex A carries 38 controls. Two companion standards landed in 2025: ISO/IEC 42005 for AI system impact assessment and ISO/IEC 42006, which sets the rules for the bodies that do the certifying. NIST publishes a crosswalk from its framework to 42001, though it was drawn against the draft (FDIS) text rather than the final one.

The EU AI Act (Regulation (EU) 2024/1689, linked here as consolidated after the amendment) is law. After the July amendment, Regulation (EU) 2026/1744, the dates that matter are these:

Fines run to €35 million or 7% of worldwide turnover for prohibited practices, and €15 million or 3% for most other obligations. The amendment also softened Article 4. Providers and deployers must now "take measures to support the development of AI literacy", and the text says outright that this doesn't require any specific level. If a slide in your deck still quotes the old "sufficient level" wording, it's out of date.

Four questions cover all three

When I sit down with a security lead to write one, we write it as four questions. Which data may each model and agent read? Under whose identity does it act? What may it do without a person approving? And what gets recorded, so a decision can be reconstructed afterwards?

Those four are the part of all three documents a platform can enforce. The rest, the Act's risk management system and technical documentation or ISO's management clauses, is paperwork that should point at these controls rather than describe new ones.

1. Which data may each model read

The Act's Article 10 is titled "Data and data governance" and applies to the training, validation and test data for high-risk systems. NIST files the same concern under Map, and ISO/IEC 42001 has a group of Annex A controls on the data used by AI systems. None of them says how to enforce it, and enforcement is the part that has to live in the platform.

On Databricks the enforcement is tags plus policy. Create pii as a governed tag in the account first, so its allowed values are enforced, then tag the sensitive columns:

ALTER TABLE prod.customers.profiles
  ALTER COLUMN ssn SET TAGS ('pii' = 'ssn');

Write the mask once as a function, then one attribute-based policy that covers the whole schema:

CREATE FUNCTION prod.customers.ssn_last4(ssn STRING)
RETURNS STRING
RETURN concat('***-**-', right(ssn, 4));

CREATE POLICY mask_ssn ON SCHEMA prod.customers
COLUMN MASK prod.customers.ssn_last4
TO us_analysts EXCEPT admins
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn
ON COLUMN ssn;

A new table with a tagged column is covered the day it lands, which is the property an auditor actually wants to hear about. Attribute-based policies need Databricks Runtime 16.4 or serverless compute. Metastore-level policies and DENY policies are still in Beta, so check what your workspace allows before you design around them.

The evidence is a query you can rerun on the day of the audit:

SELECT catalog_name, schema_name, table_name, column_name, tag_value
FROM system.information_schema.column_tags
WHERE tag_name = 'pii';

2. Under whose identity it acts

Agents make this one urgent. An agent running under a developer's personal token inherits everything that developer can see, and nothing in the logs will separate the two of them.

Run every model and agent under its own service principal and grant it exactly what it needs. One detail in Unity Catalog catches people: a registered model is a function securable, so there's no GRANT ... ON MODEL. The privilege that lets a principal load or serve a model is EXECUTE:

GRANT USE CATALOG ON CATALOG prod TO `claims-triage-agent`;
GRANT USE SCHEMA ON SCHEMA prod.ml TO `claims-triage-agent`;
GRANT EXECUTE ON FUNCTION prod.ml.claims_classifier TO `claims-triage-agent`;
GRANT SELECT ON TABLE prod.claims.open_claims TO `claims-triage-agent`;

Service principals are referenced by their application ID in backticks. The names above are illustrative.

If your system is high-risk under the Act, you're far more likely to be its deployer than its provider, and Article 26 gives deployers human oversight, monitoring and log retention to show. The Article doesn't mention identity. We put it on this row because all three are much easier to show when the system has one of its own.

3. What it may do without a person approving

Article 14 of the Act requires human oversight for high-risk systems. NIST puts the same thing under Manage, and it's the question ISO/IEC 42001 auditors ask about operation. In a running system it comes down to three gates.

The first gate is promotion. A model version shouldn't reach production because someone ran a cell. Register it in Unity Catalog, have the evaluation job mark it, and let serving follow an alias that only a person moves:

import mlflow

client = mlflow.MlflowClient()
client.set_model_version_tag(
    "prod.ml.claims_classifier", "7", "validation_status", "approved"
)
client.set_registered_model_alias("prod.ml.claims_classifier", "champion", 7)

Who moved the alias, and when, is in the audit log.

The second gate is evaluation, and for generative systems it's the one that actually catches problems. MLflow 3 runs scorers against a fixed set of cases, so "the new prompt is better" becomes a number you can compare release to release:

from mlflow.genai.scorers import Safety, Correctness, Guidelines

mlflow.genai.evaluate(
    data=eval_cases,
    predict_fn=triage_agent,
    scorers=[
        Safety(),
        Correctness(),
        Guidelines(name="no_payout_promises",
                   guidelines=["Never promise a payout amount"]),
    ],
)

Correctness needs expected_facts or an expected_response in each case, and that's the useful discipline. Somebody has to write down what a right answer is before the system ships.

The third gate is at runtime. Databricks has folded AI Gateway into Unity Catalog as Unity Gateway, and its service policies can allow, deny or require approval, with built-in policies for PII, prompt injection and unsafe content. Those policies are in Beta and switched on through the account Previews page. The older per-endpoint guardrails now live under a page Databricks labels legacy. For an action with money or a customer on the other end, we still put the approval in a durable workflow on Temporal, where it survives a restart and sits in the workflow history.

4. What gets recorded

Article 12 says high-risk systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system". Articles 19 and 26 require providers and deployers to keep those logs for at least six months. NIST's Measure function and ISO's performance evaluation clause assume the same records exist.

Databricks records a great deal of this already, in system tables, each with its own retention:

Ninety days is shorter than six months. If your system is high-risk and its serving usage is part of your evidence, copy it somewhere you control before it ages out:

CREATE TABLE IF NOT EXISTS gov.evidence.endpoint_usage
AS SELECT * FROM system.serving.endpoint_usage WHERE 1 = 0;

INSERT INTO gov.evidence.endpoint_usage
SELECT * FROM system.serving.endpoint_usage
WHERE request_time > (
  SELECT coalesce(max(request_time), timestamp '1970-01-01')
  FROM gov.evidence.endpoint_usage
);

Schedule it daily. The audit table is still marked Public Preview, which is worth a line in your risk register. It's also the table that answers the question auditors ask first:

SELECT event_time, user_identity.email, request_params.operation
FROM system.access.audit
WHERE event_date >= current_date() - 30
  AND service_name = 'unityCatalog'
  AND action_name = 'generateTemporaryTableCredential'
  AND request_params.table_full_name = 'prod.claims.open_claims';

Databricks documents generateTemporaryTableCredential as the event for working out who queried what and when. This version covers one table over thirty days. For request and response payloads, turn on inference tables for the endpoint. They land in a schema you choose, and the first rows can take up to an hour to appear.

The whole map on one page

ISO/IEC 42001 sits across all four rows, because what it certifies is that you run this deliberately and can show it. If you're heading for certification, buy the standard and map its 38 Annex A controls against these rows yourself. A control list copied secondhand is how the names end up wrong in front of an auditor.

What the documents can't do for you

None of the three tells you where the line sits for your system. Whether an agent may issue a refund without approval, how many evaluation cases are enough, and who's allowed to move the champion alias are decisions, and they belong to whoever owns the risk. Write those decisions down in the framework document, and keep it short enough that people actually read it.

What the document shouldn't do is describe controls that don't exist. If a rule in the framework can be broken without anything in the platform noticing, it isn't a control yet.

That's the work at data and AI governance. A common first step is the two-week Databricks Health Check, which reads your Unity Catalog coverage and who can reach what, the starting point for the first two questions.