AI Governance Framework: One You Implement, Not Attest To

What a CIO actually needs to decide

A governance framework that no system can enforce is a statement of intent. It can be well written, reviewed by counsel, and approved by a board, and it will still not stop an agent issuing a refund at 2am under a credential nobody scoped.

The NIST framework for AI governance is the AI Risk Management Framework 1.0, published as NIST AI 100-1 in January 2023 and organised around four core functions: GOVERN, MAP, MEASURE, and MANAGE. It is voluntary guidance, not a certifiable standard, and GOVERN runs across the other three rather than preceding them.

That answer is the easy part. Four decisions are the work, and picking a framework name answers none of them.

• Which standard you will be measured against, and by whom. A certificate, a contract clause, and a regulator's deadline are three different pressures.
• What layer gets governed. The model, the data, or the action. Most published frameworks govern the first two and go quiet on the third.
• Who owns each control. A named role. A committee can approve a control and cannot be held to it.
• What artifact proves the control ran. If nobody can produce a dated record on request, the control exists only in the document.

Governance framework versus AI usage policy

An AI usage policy governs people. Its audience is employees, its scope is behaviour, and it says which tools staff may use with which categories of data. Enforcement runs through HR process, training, and access blocks at the SSO layer.

An AI governance framework governs systems. Its audience is the teams that build and operate AI, and it says what must be true before a system reaches production and what must be recorded once it is there. Enforcement runs through gates in the build and deploy path. A usage policy tells someone not to paste customer data into a chatbot. A framework decides whether the agent your team shipped last month may write to the general ledger, and proves what it wrote.

You need both. A usage policy filed under governance framework is the most common way a programme looks complete while governing nothing that runs.

The three frameworks that matter, and how they differ

There is no single mandated AI governance framework. Three reference points carry weight, and the useful distinction between them is legal force, because that determines whether you are choosing or complying.

| Framework | What it is | Certifiable? | Who it binds | Key dates | | --- | --- | --- | --- | --- | | NIST AI RMF 1.0 (NIST AI 100-1) | Voluntary risk management guidance built on four functions, with a companion Playbook and a Generative AI Profile | No. No accredited certification scheme exists against the AI RMF | Nobody by law. It binds when a contract, a customer, or a sector regulator names it | Released 26 January 2023. Generative AI Profile (NIST AI 600-1) issued 26 July 2024 | | ISO/IEC 42001:2023 | A management system standard for establishing, implementing, maintaining, and continually improving an AI management system. 51 pages, from ISO/IEC JTC 1/SC 42 | Yes. Accredited third-party audit, in the same shape as ISO/IEC 27001 | Organisations that choose to certify, and their suppliers through contract flow-down | Published 18 December 2023 | | EU AI Act (Regulation (EU) 2024/1689) | Law. Risk-based obligations on providers and deployers of AI systems placed on or used in the EU market | Not certification. High-risk systems require conformity assessment and CE marking | Providers, deployers, importers, and distributors in scope of the EU market, wherever established | Published in the Official Journal 12 July 2024, in force 1 August 2024, phased through 2 August 2027 |

Sources: NIST AI RMF 1.0, the NIST AI RMF landing page, the IEC Webstore record for ISO/IEC 42001:2023, and the EU AI Act implementation timeline.

The practical read: NIST AI RMF 1.0 gives you a shared vocabulary your engineers will tolerate. ISO/IEC 42001:2023 gives you something a procurement team can put in a data room. Regulation (EU) 2024/1689 gives you dates you do not control. Aligning to NIST and certifying to ISO/IEC 42001 does not make you EU AI Act compliant, and no vendor can sell you that compliance either.

One more piece of precision, because this audience checks. The EU AI Act is widely described as having four risk tiers. Two are real legal categories: Article 5 sets out prohibited AI practices, and Article 6 with Annexes I and III defines a high-risk AI system with specific duties attached. Limited risk and minimal risk are commentary shorthand for transparency obligations and for everything left unregulated. Useful labels, not statutory terms of art, so do not build a control taxonomy that depends on them. See the high-level summary.

The four NIST functions, correctly

NIST publishes the AI RMF Core as four functions, in caps, in this order. Definitions below are NIST's own, from the AI RMF Core in NIST AI 100-1.

• GOVERN cultivates and implements a culture of risk management within organizations.
• MAP establishes the context to frame risks related to an AI system.
• MEASURE is where you analyze, assess, benchmark, and monitor AI risk and related impacts.
• MANAGE entails allocating risk resources to mapped and measured risks.

GOVERN is cross-cutting rather than step one of four. NIST describes it as permeating AI risk management and informing the other three throughout a system's lifespan, a different structural claim from the sequential pillar diagrams that circulate under NIST's name. Each function decomposes into categories and subcategories identified as GOVERN 1.1 and so on, so a control traces to a named subcategory rather than to a theme. That traceability is most of the value of adopting NIST at all, and it is the part vendor summaries drop.

The argument: frameworks stop where enforcement begins

Read the widely-cited AI governance frameworks in sequence and a pattern appears. Strong on principles, credible on model and data lineage, specific about who sits on the review board, silent on the moment an AI system does something irreversible. That silence is structural rather than sloppy.

You cannot apply role-based access control to a paragraph of instructions. You cannot revoke a credential from a sentence in a system prompt. You cannot audit a context window after the session closes, because nothing is left to audit. When the thing you are governing is a model deciding what to do next, the only durable objects available are the artifacts around it: the training data, the model card, the evaluation report, the minutes of the meeting that approved it. So the framework governs those, declares itself complete, and passes its audit.

Meanwhile the agent acts. It calls a tool, writes to a system of record, sends an email, moves money. A policy document has no purchase on any of it, which is how a governance programme stays well-run and still fails to prevent the incident. Closing that gap means control at the point of action rather than control at the point of approval.

The position, stated plainly: a governance framework binds only where the work is code. Scoped credentials, role-based access, and audit logging are enforceable because they attach to an application with a permissions model and a log. They do not attach to reasoning. Any control that depends on a model behaving as instructed is a preference, and it will be treated as one the first time the model is wrong.

What good looks like in practice

Here is the artifact the frameworks are missing. One row per NIST function, each naming a control, a role that owns it, and the record an auditor would ask to see. Adapt the roles to your org chart. Do not adapt away the last column.

| NIST function | Control to implement | Owner | Audit artifact | | --- | --- | --- | --- | | GOVERN | No AI system or agent receives production credentials until it exists in the inventory with a named accountable owner, a stated purpose, and a risk classification | CISO or Head of Risk, with the credential gate enforced by platform engineering | Dated inventory record per system: owner, purpose, classification, approver, approval date | | MAP | Every use case classified against the EU AI Act high-risk criteria and internal thresholds before build starts, with legal review on anything touching employment, credit, biometrics, or safety | Product owner for the system, countersigned by legal | Dated classification record naming the legal reviewer, with the reasoning attached | | MEASURE | Pre-deployment evaluation against a documented numeric acceptance threshold, re-run on every model, prompt, or tool-inventory change, with deployment blocked on failure | Model risk lead, or the senior engineer holding that accountability | Dated evaluation record: the threshold, the measured result, the pass or fail decision, the change that triggered the run | | MANAGE | Credentials scoped per action path at least privilege, with revocation and rollback tested rather than documented, and every action written to an append-only log | Platform engineering, with security sign-off on each grant | Credential grant register plus an action-level audit log reconstructing what ran, under whose authority, with what inputs, and what changed |

Two rows deserve a note. MEASURE is the one most programmes fake, because writing evaluate before deployment is easy and setting a number you will be held to is hard. Pick the number badly and revise it. A revised threshold with a dated history is a governance artifact; an unnumbered commitment to evaluate is a sentence. MANAGE is where the artifact column gets difficult, so understand what observability actually requires before promising an auditor a replay path you cannot produce. On sequencing rather than the control set, we have written separately on getting from policy to implementation.

The control points that actually bind

Three mechanisms carry almost all of the enforcement weight. Each is a mechanism rather than a principle, which is the test for whether it belongs in a framework at all.

Scoped credentials. The agent never holds a broad API key. It acts through credentials issued for a specific action path, with a scope that cannot be widened at runtime and a revocation that takes effect immediately. This one control does more work than the rest combined, because it caps blast radius regardless of how the model behaves. It also requires you to have thought about the agent threat model rather than the model's accuracy.

Role-based access at the query layer. Permissions enforced where data is read and written, rather than in the instructions given to the agent. If enforcement lives in the prompt, a sufficiently persuasive input removes it.

Audit logging at the point of action. Not token logs. A record of which action ran, under which credential, with which inputs, and what state changed, retained on the same schedule as your other operational records.

Then the sequence.

1. Pick the standard you will be measured against. ISO/IEC 42001:2023 for a certificate, NIST AI RMF 1.0 for a vocabulary your engineers will use, both if you sell into the EU.
2. Build the inventory before writing the policy. Every AI system, agent, and third-party AI feature in use, with an owner. Most organisations find more than they expected, and the surprises are the risk.
3. Classify each entry against the EU AI Act criteria and your own thresholds, recording the reasoning. The classification will be challenged.
4. For each NIST function, name one control, one owner, one artifact. Reject any row where the owner is a committee or the artifact is documented process.
5. Set numeric acceptance thresholds for the MEASURE controls. Write down what fails.
6. Move the repeatable parts of each workflow into code, so the control has a surface to attach to. A step that exists only as an instruction to a model cannot be gated.
7. Wire artifact production into the runtime. A manual quarterly audit record becomes a manual quarterly fiction.
8. Run a dry audit against your own framework at 90 days, using someone who did not write it. The rows that fail are the rows where enforcement was assumed.

Where vendors are getting this wrong today

Three category behaviours, worth naming as behaviours rather than as a list of companies.

Governance scoped to the model and the data, then sold as governance of the system. Lineage, versioning, model cards, and drift monitoring are real controls that answer questions about the model. They do not answer what the agent did on Tuesday.

Committees substituting for controls. Nearly every published framework's answer to enforcement is a cross-functional body with a charter. A body decides. It does not gate.

Governance capabilities behind a plan tier. Audit logs, SSO, and fine-grained permissions get treated as upgrades rather than as the conditions under which the product should run at all. If the controls your framework depends on sit behind a commercial upgrade, your framework has a procurement dependency worth surfacing to your board, so be precise about what enterprise-grade actually means before accepting the term.

Timelines you are actually working to

If the EU AI Act applies to you, these are the dates, from the official implementation timeline.

The Act was published in the Official Journal on 12 July 2024 and entered into force on 1 August 2024. Prohibitions on certain AI systems and the AI literacy requirements started to apply on 2 February 2025. The rules on notified bodies, general-purpose AI models, governance, confidentiality, and penalties began applying on 2 August 2025. The remaining provisions apply from 2 August 2026, except Article 6(1), which applies from 2 August 2027. Providers of general-purpose AI models placed on the market before 2 August 2025 have until 2 August 2027 to comply.

Two dates get missed. Member States were required to have at least one operational national AI regulatory sandbox by 2 August 2026. And high-risk systems intended for use by public authorities have until 2 August 2030, a long runway that has produced considerable deferred work.

What we're doing about this at Major

Governance frameworks stop at policy because the thing they are trying to govern has no handles on it. A prompt has no permissions model. A context window has no audit log. So the framework governs the objects that do persist, the model, the dataset, the approval record, while the actions an agent takes in production stay outside its reach. That gap is why programmes pass audits and still fail to prevent the incident.

Major's answer is to change what the agent produces. On Major, when an agent works out how to handle a repeatable part of a task, it builds an app for that part and then runs the app instead of reasoning through the work again. That app carries scoped credentials, role-based access, and its own audit log, and it holds its state in a managed database. The control points stop being clauses in a document and become properties of where the work runs. An action is attributable, scoped, and logged because it happened inside an application rather than inside a model's reasoning. Reason once, run forever.

The honest limits. This does not make you ISO/IEC 42001:2023 certified, and buying a platform is not a governance programme. Policy, training, classification, and a named accountable executive all still matter, and code replaces none of them. The model still reasons, because judgment calls need judgment; the claim is that it should reason over less. This article also leaves aside AI system evaluation, which is harder than governance and deserves its own treatment. The narrow claim we will defend is that the artifact column of that control matrix is only fillable when the work has a runtime with permissions and a log, and every framework skipping it skips it for that reason.

If you are filling in that column and cannot name the artifact, that is the part worth testing against a real runtime rather than a diagram. You can see how Major scopes credentials and logs agent actions at the point they happen.

Related articles

• AI Agent Governance: Why Control Must Move to the Point of Action
• Enterprise AI Governance: From Policy to Implementation
• AI Agent Observability Isn’t a LangSmith Feature

Related articles

• AI Agent Governance: Why Control Must Move to the Point of Action
• AI Agent Observability Isn’t a LangSmith Feature
• AI Agent Security: The Threat Model and How to Contain It