AI Governance Framework: One You Implement, Not Attest To

What is an AI governance framework?

An AI governance framework is the set of policies, controls, owners and records that decide how an organisation builds, deploys and oversees AI systems. The one most teams start from is the NIST AI Risk Management Framework 1.0 (NIST AI 100-1, January 2023), organised around four functions: GOVERN, MAP, MEASURE and MANAGE. It is voluntary guidance with no certification scheme behind it. ISO/IEC 42001:2023 is the certifiable alternative.

A framework only governs something when each function names a control, an owner and an audit artifact. Most published frameworks stop at the first of those and never reach the action an agent takes in production, which is where Major comes in. On Major, an agent builds deterministic apps for the repeatable parts of its work, and those apps carry scoped credentials, role-based access and an audit log. The controls in your framework get a surface to attach to.

Which framework do you actually need?

There is no single mandated standard. Three reference points carry weight, and legal force is what separates them.

• NIST AI RMF 1.0: voluntary risk management guidance with a companion Playbook and a Generative AI Profile (NIST AI 600-1, July 2024). It binds only when a contract, customer or sector regulator names it. Use it for a shared vocabulary your engineers will tolerate.
• ISO/IEC 42001:2023: a management system standard for an AI management system, structured like ISO/IEC 27001, with accredited third-party audit. Use it when procurement wants a certificate for the data room.
• EU AI Act (Regulation (EU) 2024/1689): law, in force since 1 August 2024, with obligations phased through 2027 for anyone placing AI systems on the EU market. Aligning to NIST and certifying to ISO does not make you compliant with it.

One precision point for readers who check. The "four risk tiers" of the EU AI Act are partly commentary. Article 5 (prohibited practices) and Article 6 with Annexes I and III (high-risk systems) are statutory categories. "Limited" and "minimal" risk are shorthand, so do not build a control taxonomy that depends on them.

How do the four NIST functions work?

NIST's own definitions, from the AI RMF Core: GOVERN cultivates and implements a culture of risk management. MAP establishes context to frame risks. MEASURE analyzes, assesses, benchmarks and monitors risk. MANAGE allocates resources to mapped and measured risks.

GOVERN is cross-cutting. NIST describes it as informing the other three throughout a system's lifespan, which contradicts the sequential pillar diagrams that circulate under NIST's name. Each function decomposes into categories and subcategories such as GOVERN 1.1, so a control can trace to a named subcategory. That traceability is most of the value of adopting NIST, and vendor summaries tend to drop it.

Framework versus AI usage policy

A usage policy governs people. It tells staff which tools they may use with which data, and it is enforced through HR process and SSO blocks. A framework governs systems. It says what must be true before an AI system reaches production and what must be recorded once it is there. 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, and filing a usage policy under "framework" is the most common way a programme looks complete while governing nothing that runs.

Why do frameworks stop where enforcement begins?

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 being governed is a model deciding what to do next, the only durable objects are the ones around it: the training data, the model card, the evaluation report, the minutes of the approval meeting. So the framework governs those and passes its audit, while the agent calls a tool, writes to a system of record and moves money. That is how a well-run programme still fails to prevent the incident.

Our position: 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 gets treated as one the first time the model is wrong.

What does a framework with teeth look like?

One row per NIST function, each naming a control, an owner and the record an auditor would ask to see. Adapt the roles to your org chart. Do not drop the artifact.

• GOVERN: no AI system or agent receives production credentials until it is in the inventory with a named accountable owner, a stated purpose and a risk classification. Owner: CISO or Head of Risk, with platform engineering running the credential gate. Artifact: a dated inventory record per system.
• MAP: every use case is classified against EU AI Act high-risk criteria and internal thresholds before build starts, with legal review for employment, credit, biometrics or safety. Owner: the product owner, countersigned by legal. Artifact: a dated classification record with the reasoning attached.
• MEASURE: pre-deployment evaluation against a documented numeric threshold, re-run on every model, prompt or tool change, with deployment blocked on failure. Owner: the model risk lead. Artifact: a dated record of the threshold, the result and the change that triggered the run.
• MANAGE: credentials scoped per action path at least privilege, revocation tested rather than documented, every action written to an append-only log. Owner: platform engineering, with security sign-off on each grant. Artifact: a credential grant register plus an action-level audit log showing what ran, under whose authority, with what inputs.

MEASURE is the row most programmes fake, because "evaluate before deployment" is easy to write and a number you will be held to is hard to set. A revised threshold with a dated history is an artifact. An unnumbered commitment is a sentence. Reject any row where the owner is a committee. A committee can approve a control and cannot be held to it.

How to run this framework on Major

The MANAGE row is the hardest to fill, and it is where Major does the work. Here is how the rows map to a running system.

1. Inventory app: build one internal app on Major that holds every AI system, its owner, purpose, classification and approval date in a managed database. Platform engineering gates credentials on a record existing there.
2. Agent for judgment: an agent drafts classification reasoning for new use cases and flags edge cases to legal. The model reasons here because the call needs judgment.
3. Deterministic apps for repeatable work: once the agent has worked out a step, such as pulling a Salesforce account or posting a refund through a payments API, it builds an app for that step and runs the app. Same behaviour every run, no fresh reasoning.
4. Scoped credentials: each app acts through connector credentials issued for one action path. The agent never holds a broad API key.
5. Role-based access: permissions are enforced on the app's data, not in the agent's prompt, so a persuasive input cannot remove them.
6. Audit log at the point of action: every app writes which action ran, under which credential, with which inputs, and what state changed. That log is the MANAGE artifact.
7. Trigger and escalation: a scheduled workflow re-runs the MEASURE evaluation on change and routes failures to the named owner in Slack for approval.

You can start building free on Major and stand up the inventory app first.

What Major does not solve

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. The model still reasons, because judgment calls need judgment. The claim is that it should reason over less, and that the artifact column of your control matrix is only fillable when the work has a runtime with permissions and a log. AI system evaluation is a harder problem and deserves its own piece.

Start building on Major

Stand up the inventory app, scope one agent's credentials to a single action path, and see the audit log fill in the MANAGE artifact your framework has been missing.

• Start building free
• Book a demo

Related articles

• Enterprise AI Governance: From Policy to Implementation
• AI Agent Security: The Threat Model and How to Contain It
• AI Agent Governance: Why Control Must Move to the Point of Action