AI governance framework: the definitive guide, from NIST and ISO to runtime

Updated 21 October 2026: expanded into a full guide with a framework comparison, crosswalk, RACI, inventory and tiering templates, policy outlines, MCP controls, metrics and a maturity model; the EU AI Act timeline now reflects the Digital Omnibus text, and the US section reflects Colorado’s replacement law.

An AI governance framework is the set of policies, roles, inventories, risk tiers, controls, monitoring and incident processes an organisation uses to decide which AI systems it builds or uses and to show that it runs them safely and lawfully. In 2026 most enterprises assemble one from three reference points: the NIST AI Risk Management Framework, the ISO/IEC 42001 management system standard and the obligations of the EU AI Act, with US state law and Singapore’s agentic framework increasingly in the mix.

The reference points are not the hard part. They overlap more than they differ, and published crosswalks connect them. The hard part is that a governance framework written in 2023 or 2024 was designed for chatbots and predictive models reviewed before launch, while the AI that staff use in 2026 includes agents that call tools, spend money and change records in real time. A policy that says “only approved models and tools” is now a runtime question, decided per request, and most frameworks have nothing in the request path to answer it.

This guide is for the people who have to build that framework: platform, security, risk and compliance leads at organisations that deploy generative AI. It covers what each reference framework requires as of October 2026, a crosswalk that turns them into one control set, the roles and RACI that make the controls owned, inventory and risk-tiering templates, policy outlines, the specific controls agents and MCP servers need, the metrics that show whether it works, a maturity model and a 90-day rollout. GenAI Brief’s earlier pieces on the EU AI Act’s model rules and shadow AI cover two of the pressures behind it in more depth.

What an AI governance framework is, and what it is not

An AI governance framework answers four questions continuously: what AI do we have, how risky is each use, who is accountable for it, and how do we know the rules are being followed. Everything else, from committees to model cards, exists to answer one of those four.

It is narrower than “responsible AI”, which also covers values and product design choices, and broader than “AI security”, which covers attacks and data loss but not, for example, whether a credit model’s use is lawful. It is also distinct from model governance in the machine learning operations sense (versioning, approvals, rollback). Model governance is one component of the framework, not the framework.

Three properties separate a working framework from a policy document:

• It is complete. It covers every AI system in use, including third-party tools, AI features inside existing SaaS, coding agents and the MCP servers they connect to, not only the models the organisation trains.
• It is proportionate. Controls scale with risk, so a summarisation helper and a hiring screen do not go through the same review.
• It is enforced and evidenced. Each policy statement maps to a control that operates without relying on people remembering it, and that control leaves records an auditor or regulator can inspect.

The third property is where most frameworks fail. The NIST AI RMF says GOVERN “is a cross-cutting function that is infused throughout AI risk management”, which is right, but a cross-cutting function still needs a point of enforcement. For generative AI that point is usually the path a request takes to a model or a tool.

The reference frameworks compared

Seven documents shape almost every enterprise AI governance framework in 2026. They do different jobs, and it helps to be precise about which job each does before mapping them.

NIST AI RMF 1.0 and the Generative AI Profile

NIST released AI RMF 1.0 as NIST AI 100-1 on 26 January 2023. Its abstract describes the framework as “voluntary, rights-preserving, non-sector-specific, and use-case agnostic”. Its core is four functions: GOVERN (culture, policy, accountability), MAP (context and intended use), MEASURE (testing and metrics) and MANAGE (prioritising, responding and recovering). Those functions break into 19 categories and 72 subcategories (GOVERN has 19, MAP 18, MEASURE 22, MANAGE 13), and each subcategory is an outcome rather than a control. GOVERN 1.6, for example, reads: “Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.”

The framework also defines the characteristics of trustworthy AI that most governance policies quote: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed.

The Generative AI Profile, NIST AI 600-1, followed on 26 July 2024. It names twelve risks that are unique to or made worse by generative AI: CBRN information or capabilities; confabulation; dangerous, violent or hateful content; data privacy; environmental impacts; harmful bias or homogenisation; human-AI configuration; information integrity; information security; intellectual property; obscene, degrading or abusive content; and value chain and component integration. It then attaches more than 150 suggested actions to the AI RMF subcategories, focused on four considerations its working group prioritised: governance, content provenance, pre-deployment testing and incident disclosure.

The profile’s actions are the most practical part of the NIST material for a framework builder. GV-1.6-001 asks organisations to “enumerate organizational GAI systems for incorporation into AI system inventory”. GV-1.3-001 lists factors for defining risk tiers. MG-2.4-004 asks for criteria that warrant deactivating a generative AI system. MG-4.3-002 asks for procedures to record and track reported errors, near misses and negative impacts. Those four actions are, between them, the skeleton of an inventory, a tiering scheme, a kill switch and an incident log.

NIST’s programme page states, as of October 2026, that “the AI RMF 1.0 is being revised as part of the White House AI Action Plan”, with no published draft or timeline, and that NIST released a concept note for a profile on trustworthy AI in critical infrastructure on 7 April 2026. A framework built on AI RMF 1.0 today should expect to be remapped once, not rebuilt.

ISO/IEC 42001 and its companions

ISO/IEC 42001:2023, published on 18 December 2023 by the joint ISO/IEC committee on AI (JTC 1/SC 42), “specifies the requirements and provides guidance for establishing, implementing, maintaining and continually improving an AI (artificial intelligence) management system within the context of an organization”. It is intended for any organisation “providing or using products or services that utilize AI systems”, which covers almost every enterprise.

Its structure will be familiar to anyone who has run ISO/IEC 27001. Clauses 4 to 10 cover context, leadership, planning, support, operation, performance evaluation and improvement. Annex A lists 38 reference controls under nine objectives: policies related to AI (A.2), internal organisation (A.3), resources for AI systems (A.4), assessing impacts of AI systems (A.5), the AI system life cycle (A.6), data for AI systems (A.7), information for interested parties (A.8), use of AI systems (A.9) and third-party and customer relationships (A.10). Annex B gives implementation guidance for each control under matching numbers. Organisations select controls through a statement of applicability, as they would for information security.

The difference from NIST is certification. An accredited body can audit an organisation against ISO/IEC 42001 and issue a certificate, which is why the standard increasingly appears in enterprise procurement questionnaires. Two companions matter. ISO/IEC 42005:2025, published on 28 May 2025, “provides guidance for organizations performing artificial intelligence (AI) system impact assessments for individuals and societies”, the process behind Annex A.5. ISO/IEC 42006:2025, published in July 2025, sets requirements for the bodies that audit and certify against 42001, which matters when choosing a certifier.

The EU AI Act after the Digital Omnibus

The EU AI Act is the only one of the international references that is law. It assigns duties by role (provider, deployer, importer, distributor) and by risk (prohibited practices, high-risk systems, transparency obligations, general-purpose models). The Digital Omnibus on AI, Regulation (EU) 2026/1744, was signed on 8 July 2026, published in the Official Journal on 24 July and entered into force on the third day after publication, 27 July 2026. Its Article 1 rewrites Article 113 of the AI Act. Read against the amending text and the Future of Privacy Forum’s timeline, the position as of October 2026 is:

Correction, 21 October 2026: an earlier version of this table gave 2 December 2026 as the Article 50(2) date for all systems. Under the Omnibus text, that date applies only to systems placed on the market before 2 August 2026; new systems are covered from 2 August 2026.

The Omnibus also softened Article 4. Providers and deployers now “shall take measures to support the development of AI literacy” of staff, and a new sentence clarifies that this does not require guaranteeing any specific level of literacy for any individual. The duty still applies to every deployer today. A new Article 4a lets providers and deployers of all AI systems, not only high-risk ones, process special-category personal data where strictly necessary to detect and correct bias, without creating an obligation to do so. Registration of systems that a provider has assessed as not high-risk under Article 6(3) is simplified, but the assessment must still be documented before the system is placed on the market.

For framework builders, the high-risk chapter is the template even before it applies. Providers need a risk management system (Article 9), automatic record-keeping (Article 12), human oversight by design (Article 14) and a quality management system (Article 17), plus post-market monitoring (Article 72) and serious incident reporting (Article 73). Deployers must use systems according to instructions, assign oversight to people with “the necessary competence, training and authority”, monitor operation and keep automatically generated logs under their control “for a period appropriate to the intended purpose of the high-risk AI system, of at least six months” (Article 26). Some deployers, including public bodies and those using AI for credit scoring or life and health insurance pricing, must also run a fundamental rights impact assessment (Article 27).

The European AI Office, inside the Commission, enforces the general-purpose model rules directly and prepares guidelines and codes of practice. The Omnibus widened its exclusive competence to AI systems built on a general-purpose model where the system and model providers are part of the same undertaking; national market surveillance authorities handle most other systems. The Commission published guidelines on Article 50 transparency on 20 July 2026 and draft guidelines on high-risk classification on 19 May 2026, according to the FPF timeline. GenAI Brief’s one-year review of the model obligations covers the provider side in detail.

US state law: Colorado’s replacement and Texas’s NIST defence

The US has no federal AI statute, and the most-cited state law changed shape this year. The original Colorado AI Act (SB 24-205) never took effect. SB 26-189, signed on 14 May 2026, “repeals and reenacts those provisions” as a narrower law on automated decision-making technology (ADMT) used in consequential decisions about education, employment, housing, lending, insurance, health care and essential government services. From 1 January 2027, developers must give deployers technical documentation covering intended uses, training data categories, known limitations and instructions for human review; deployers must give consumers notice at the point of interaction, a plain-language explanation within 30 days of an adverse decision and a route to human review; and both must keep compliance records for at least three years. The Attorney General enforces it under the Colorado Consumer Protection Act, with a 60-day cure period before 1 January 2030. As of October 2026 the Attorney General’s office invites formal rulemaking comments on draft ADMT rules until 26 October 2026.

Texas went the other way: narrow duties, but a direct incentive to adopt a framework. The Texas Responsible Artificial Intelligence Governance Act (HB 149), in effect since 1 January 2026, bars certain intended uses of AI (such as inciting self-harm, unlawful discrimination and sexual abuse material), requires government agencies to disclose when consumers are interacting with AI and sets civil penalties of up to $200,000 per uncurable violation. Its enrolled text gives a defence where a violation is discovered through red-team testing or where the defendant “substantially complies with the most recent version” of NIST’s Generative AI Profile, or another recognised AI risk framework, through an internal review process. That is the clearest case anywhere of a statute rewarding a documented NIST-based framework.

Federal policy pulls against state rules. Executive Order 14365 of 11 December 2025 directed the Attorney General to set up an AI Litigation Task Force to challenge state AI laws inconsistent with federal policy. For a framework builder the practical reading is that US obligations will remain a moving, state-by-state patchwork, which is an argument for building to the EU and NIST structure and treating state requirements as additional notices and records, not a separate programme.

OECD principles and Singapore’s agentic framework

The OECD AI Principles, adopted in 2019 and updated in May 2024, have 47 adherents. Their five values-based principles (inclusive growth and well-being; human rights and democratic values, including fairness and privacy; transparency and explainability; robustness, security and safety; accountability) sit behind the trustworthiness language in both NIST and the EU AI Act. They do not create controls, but they are the right source for the principles section of a corporate AI policy, because regulators across jurisdictions recognise them.

The newest reference is the most relevant to 2026. Singapore’s Infocomm Media Development Authority launched a Model AI Governance Framework for Agentic AI at Davos on 22 January 2026, describing it as a first-of-its-kind framework. It organises guidance across four dimensions: assessing and bounding risks upfront, including placing limits on agents’ autonomy and access to tools and data; making humans meaningfully accountable “by defining significant checkpoints at which human approval is required”; implementing technical controls throughout the agent life cycle, “such as baseline testing and controlling access to whitelisted services”; and enabling end-user responsibility through transparency and training. IMDA calls it a living document and says it is developing testing guidelines for agentic applications.

The crosswalk: NIST AI RMF, ISO/IEC 42001 and the EU AI Act as one control set

The useful way to combine the frameworks is to stop treating them as three checklists and treat them as three views of one control set. Build the control set around the components the organisation actually operates, then record which NIST subcategory, ISO clause or control, and EU AI Act article each component satisfies. One control, three citations, one owner.

NIST maintains a list of community crosswalks that do part of this work, including a NIST AI RMF to ISO/IEC 42001 crosswalk contributed by Microsoft, AI RMF to ISO/IEC 42005 and to ISO/IEC 23894 (both from the US standards body INCITS, 14 August 2025), NIST AI 600-1 to Singapore’s AI Verify (May 2025) and a 2023 illustration relating the AI RMF’s trustworthiness characteristics to the OECD Recommendation and the EU AI Act proposal. NIST notes that listing a crosswalk does not imply endorsement. The table below is a component-level mapping drawn from the primary texts and the Microsoft crosswalk, which maps, for example, GOVERN 1.6 to the A.4 resource controls and MEASURE 2.4 to the operation, monitoring and event-log controls.

Figure 1: The four main reference points do different jobs; a single control set can cite all of them.

Two practical consequences follow. First, an organisation with ISO/IEC 27001 already has most of the management-system machinery (document control, internal audit, management review, corrective action) that ISO/IEC 42001 needs, so the incremental work is the AI-specific Annex A controls and the impact assessment process. Second, the EU AI Act’s high-risk articles are the strictest expression of controls the other two describe loosely. Designing the inventory, logging and oversight components to the Article 12 and Article 26 standard means the framework is already shaped for 2 December 2027 when the Annex III obligations arrive, and the same records double as the “internal review process” Texas rewards.

The seven components of an enterprise AI governance framework

Every mature enterprise AI governance framework has the same seven components, whatever it calls them. The order matters: each depends on the one before. The sections after this one give templates for the first four.

1. An AI inventory that includes what nobody registered

The inventory is the foundation, and the most commonly faked component. A spreadsheet of projects that teams volunteered is not an inventory. NIST AI 600-1 asks inventory entries to include data provenance, known issues, human oversight roles, rights considerations and “underlying foundation models, versions of underlying models, and access modes” (GV-1.6-003). It also asks organisations to define exemptions explicitly for generative AI embedded in application software (GV-1.6-002), which is an admission that AI features inside SaaS are part of the inventory problem.

A complete inventory combines three sources: declared systems (registration at project start), observed traffic (which models and providers requests actually reach, and from whom) and discovered endpoints (AI apps and MCP servers installed on company machines). The second and third sources need tooling; the shadow AI analysis explains why network logs alone miss desktop apps and local tool servers.

2. Risk tiers that decide the depth of review

Risk tiers turn one framework into proportionate treatment. NIST’s GOVERN 1.3 asks for processes “to determine the needed level of risk management activities” based on risk tolerance, and GV-1.3-001 lists factors to weigh, including “dependencies between GAI and other IT or data systems”, harm to fundamental rights and the possibility of malicious use. Each tier should fix three things: which impact assessment applies, who approves, and which runtime controls are mandatory. The last item is the one most frameworks omit.

3. Policies short enough to be enforced

The test of each policy clause is whether a control can enforce it. “Employees must not paste confidential data into unapproved AI tools” is enforceable only if approved tools are distinguishable from unapproved ones at the point of use, and if confidential data can be detected in transit. Policies that cannot pass that test should be rewritten or explicitly marked as training-only.

4. Roles with named owners

The EU AI Act and ISO/IEC 42001 both assume named accountability, and NIST’s GOVERN 2.1 asks that roles, responsibilities and lines of communication be documented and clear. Article 26(2) adds a specific requirement for high-risk deployments: the people assigned to human oversight must have the competence, training and authority to act, which means oversight cannot be a nominal sign-off by someone with no power to stop the system.

5. Controls, split into review-time and run-time

Review-time controls happen before launch: impact assessments, evaluations, red-teaming, supplier due diligence, approval gates. Run-time controls operate on every request: which identities may call which models, which tools an agent may use, how much a team may spend, what content is blocked or redacted, and what is logged. Most written frameworks are rich in review-time controls and thin on run-time ones, because run-time controls require infrastructure. For generative AI the risk is concentrated at run time, where prompts carry data and agents take actions.

6. Monitoring that produces evidence

Monitoring has two outputs: operational signals (cost, error rates, guardrail triggers, unusual usage) and evidence (records that show controls operated). ISO/IEC 42001 control A.6.2.8 covers recording event logs; EU AI Act Article 12 requires high-risk systems to log events automatically, and Article 26(6) requires deployers to retain those logs for at least six months. The design point is to log policy decisions as well as requests: which key, which model, which guardrail fired, which tool call was refused. Separate administrative audit trails, recording who changed a policy, matter as much as request logs.

7. Incident response that knows what an AI incident is

AI incidents include confabulated output that caused harm, data exposure through prompts, an agent taking an unintended action, a jailbreak, a supplier model change that broke behaviour, and cost runaways. NIST AI 600-1 asks for escalation procedures when deactivation criteria are met (MG-2.4-002), after-action reviews (MG-4.3-001) and legally compliant incident reporting (MG-4.3-003). EU AI Act Article 73 requires providers of high-risk systems to report serious incidents to market surveillance authorities “not later than 15 days” after becoming aware, with shorter limits for the most severe cases. The minimum technical capability behind all of this is a kill switch: what NIST’s MANAGE 2.4 calls mechanisms “to supersede, disengage, or deactivate AI systems”, in practice the ability to revoke a key, disable a model or block a tool for one team or the whole organisation in minutes, without a redeploy.

Roles and a RACI that makes the controls owned

A framework with no named owners decays within two quarters. Six roles cover almost every organisation, whatever the titles:

• Executive owner. Usually the chief risk, chief data or chief information officer. Accountable for the framework, sets risk appetite and chairs management review (ISO/IEC 42001 clause 5.1 and 9.3; NIST GOVERN 2.3).
• AI governance council. Security, legal and privacy, data, platform, HR and at least one business representative. Approves policy, high-tier use cases and exceptions.
• System owner. One named person per inventory entry, normally in the business line that uses it. Answers for its tier, its assessment, its monitoring and its incidents.
• Platform owner. Runs the enforcement layer: gateway, keys, budgets, guardrails, logging and the endpoint agent. Turns policy into configuration.
• Security and privacy. Threat modelling, red-teaming, data protection impact assessments, incident handling.
• Oversight operators. The people who actually watch high-tier systems and can stop them, with the competence, training and authority Article 26(2) demands.

The RACI below assigns Responsible (does the work), Accountable (signs off, one per row), Consulted and Informed. Adjust the names, but keep one A per row.

Two splits matter more than the rest. The platform owner configures controls but should not approve the exceptions to them, or the control set quietly grows holes. And the person accountable for pulling the kill switch must be reachable at any hour, because agent incidents do not wait for the council’s next meeting.

The AI inventory record and the risk-tiering matrix

The inventory is a database, not a document. Each record should carry enough to tier the system, find its owner, reconstruct its supply chain and prove its controls. The fields below combine NIST GV-1.6-003, ISO/IEC 42001 A.4 and the documentation EU deployers and Colorado’s ADMT law expect.

Tiering then reads off those fields. Four tiers are enough for most organisations:

Tiers are reassessed whenever a field changes: a new tool, a new data category, a model upgrade or a move from pilot to customer-facing. A tool agent that gains one write-capable MCP server has changed tier, even if nobody filed a form.

Policy templates in outline

A policy set that works in 2026 has six documents. Each should be short, cite the framework clauses it satisfies and name the control that enforces each enforceable clause. The outlines below are starting points, not legal text.

1. AI policy (the charter). Purpose and scope; principles (OECD wording works well); risk appetite by tier; roles and the RACI; the framework references (NIST AI RMF and AI 600-1, ISO/IEC 42001, EU AI Act, relevant state laws); exception process; review cycle. Owner: executive owner. Satisfies GOVERN 1.1 to 1.4, ISO clause 5.2 and A.2.2.

2. Acceptable use of AI (for all staff). Approved tools list and how to request a new one; data that may never enter an AI tool; disclosure when AI produced customer-facing content; personal accounts and personal API keys; installing desktop AI apps, browser extensions and MCP servers; reporting a problem. Each prohibition names its control (app block, guardrail, endpoint MCP deny). Satisfies Article 4 literacy support and ISO A.9.

3. AI development and procurement standard. Registration at project start; tiering; required assessments and tests by tier; model and vendor due diligence (documentation, data use terms, incident notification); human oversight design; logging requirements; release gates; change management for model upgrades. Satisfies MAP and MEASURE, ISO A.5, A.6, A.10 and the high-risk articles.

4. Agent and MCP standard. Agent identity and key issuance; deny-by-default tool access; which tool actions require human approval; token handling (no passthrough, scoped tokens); approved MCP servers and the approval queue; spending and rate ceilings per agent; sandboxing for coding agents; kill switch. Satisfies IMDA’s four dimensions and the MCP specification’s security guidance, covered below.

5. Data for AI policy. Data classification mapped to what may be sent to which model and where it is processed; retention of prompts and outputs; use of personal and special-category data, including the Article 4a bias-testing route; customer data in vendor training. Satisfies ISO A.7, Article 10 and privacy law.

6. AI incident response procedure. Definition of an AI incident with examples; severity levels; who declares and who pulls the kill switch; evidence to preserve (request logs, guardrail decisions, admin audit trail); regulatory reporting decision tree (Article 73’s 15 days, state law, sector rules); communication; after-action review feeding policy. Satisfies MANAGE 2.3, 2.4 and 4.3, ISO clause 10 and A.8.4.

Agentic AI governance: what changes when systems act

Agentic AI governance is the part of the framework that most 2024-era documents lack. An agent is a system that plans, calls tools and acts on the results, often with credentials that let it change data, send messages or spend money. Three properties make agents different from the systems the original frameworks had in mind.

• The decision happens at run time. A model reviewed before launch behaves within a range; an agent composes tool calls dynamically, so the set of actions it takes cannot be fully enumerated in an approval meeting.
• Identity is delegated. An agent acts on behalf of a user or service, frequently through an MCP server holding a token. The question “who did this?” has two answers, and logs need both.
• Tools are the new attack surface. The OWASP Top 10 for Agentic Applications, published on 9 December 2025, centres on risks such as agent goal hijacking through injected content, misuse of legitimate tools, and identity and privilege abuse. Each of these is a run-time failure that a pre-launch review cannot prevent; GenAI Brief’s prompt injection explainer shows how the injection half works in practice.

IMDA’s agentic framework answers with “bounding” as the first dimension: choose use cases where errors are recoverable, and limit autonomy and access to tools and data. That translates into four concrete controls for any agent in the inventory: a scoped identity per agent or per team; an allow-list of tools, deny-by-default; spending and rate ceilings per identity; and defined checkpoints, by action type, where a human approves before execution.

Figure 2: Each step up in autonomy adds controls that only operate at run time.

MCP-specific controls

The Model Context Protocol is now the default way agents reach tools, and its own specification sets several rules a governance framework should adopt as policy. The current revision is dated 2026-07-28. Its tools chapter says that, for trust and safety, “there SHOULD always be a human in the loop with the ability to deny tool invocations”, and that applications should show which tools are exposed and ask for confirmation. Its authorization chapter says MCP servers “MUST only accept tokens that are valid for use with their own resources” and “MUST NOT accept or transit any other tokens”. The security best practices name token passthrough as an anti-pattern, describe the confused deputy problem for proxy servers, and recommend scope minimisation because broad tokens expand the blast radius when stolen.

Translated into controls, with the framework clause each one satisfies:

Agents also change the inventory problem. Coding agents and desktop assistants now arrive on employee laptops with MCP servers configured locally, which is why GenAI Brief’s explainer on MCP gateways argues that tool access needs the same central control point as model access. A framework that inventories models but not tools has inventoried half of the agent. Coding agents add one more decision: whether staff may run them with permission prompts disabled, which the companion piece on Claude Code’s skip-permissions flag treats in detail; the governance answer is a written rule plus managed settings that enforce it.

From paper policy to runtime control

The gap between paper policy and runtime enforcement is the defining weakness of enterprise AI governance in 2026. Closing it means translating each enforceable policy clause into a control that sits in the path every AI request takes, and making that control produce evidence by default.

The translation is mechanical once written down:

Figure 3: A policy clause becomes governance only when a control in the request path enforces it and leaves a record.

Why the gateway is the natural enforcement point

An AI gateway sits between applications and model providers, authenticates callers, applies policy and records each request. GenAI Brief’s explainer on what an AI gateway is covers the architecture, and the roundup of AI governance tools compares products for each layer. For governance, the gateway’s value is that every row of the table above can be enforced in one place, once, rather than reimplemented in every application.

Several products occupy this layer. Microsoft’s AI gateway in Azure API Management offers a token limit policy for per-consumer token limits and quotas, content safety checks through Azure AI Content Safety, and prompt and completion logging to Azure Monitor, and can expose and pass through MCP servers. The LiteLLM proxy supports budgets and rate limits on keys, users and teams, and its documentation advises that, where a budget must stay a hard ceiling, operators keep reservation enabled and also configure fail-closed enforcement. Kong and Cloudflare offer AI gateway features on top of their API platforms. The right choice depends on where workloads run and how much of the control set the gateway covers natively.

Worked example: Bifrost as the enforcement layer

Bifrost, an open-source AI gateway written in Go by Maxim AI, is a useful worked example because its documentation covers most rows of the translation table directly, and because it can be self-hosted, so prompts and logs stay inside the organisation’s network. Its AI governance capabilities map closely onto the framework components above.

The identity layer is the virtual key, which the docs call “the primary governance entity”. Each key carries model and provider filtering, its own budgets, token and request rate limits, an optional expiry and an active or inactive switch, and belongs to one team or customer (in Enterprise, also a business unit or user). Turning a key off is the kill switch from component 7. Budgets are hierarchical: the docs say each budget “must have sufficient remaining balance” for a request to proceed, so a team ceiling holds even if an individual key has headroom.

For agents, MCP tool filtering attaches a tool allow-list to each virtual key and is deny-by-default: a key with no MCP configuration gets no tools except from clients explicitly marked as allowed by default, and the allow-list is enforced again at tool execution time. That is IMDA’s “controlling access to whitelisted services” expressed as configuration.

The content layer is guardrails, which validate inputs and outputs for model traffic and, through MCP guardrails, “the actual tool-execution boundary”, inspecting tool arguments before a call and results after it. The documented providers include Gitleaks-backed secrets detection, custom regex with a PII template, LLM-as-judge prompt guardrails for organisation-specific policies, and integrations such as Microsoft Presidio, AWS Bedrock Guardrails, Azure Content Safety and Google Model Armor. A monitor mode records what output guardrails would have done without blocking, which suits the first weeks of a rollout. Built-in observability records each request with inputs, outputs, tokens, cost and latency, and stores the redacted form when guardrail redaction is on. Separately, audit logs record administrative activity (who changed what, and when), can be signed with an HMAC key, and can be archived to S3 or GCS for long-term retention. That split between request logs and admin audit trails is the evidence pair that ISO/IEC 42001 and Article 26 reviews ask for.

At scale, Enterprise access profiles package providers, models, budgets, rate limits and MCP tools into a reusable policy applied to users, roles, teams, business units or customers; editing a profile takes effect without issuing new keys, and a profile can rotate users’ virtual keys on a schedule. Performance matters for a control that sits on every request: Bifrost’s published benchmark reports 11 µs of added overhead per request at 5,000 requests per second on an AWS t3.xlarge. Guardrails, audit logs, access profiles and role-based administration are part of the Enterprise tier.

Reaching the laptop

A gateway governs only traffic configured to reach it. Desktop chat apps, browser AI and coding agents running on personal keys bypass it, which leaves the inventory incomplete and the acceptable-use policy unenforced. The response is to move the routing decision onto the machine.

Bifrost Edge applies that model as the endpoint layer of the same gateway. According to its documentation, it runs on macOS, Windows and Linux, deploys through MDM tools such as Jamf, Intune and Kandji, and routes AI traffic from desktop chat apps, browser AI, coding agents and their MCP servers through the organisation’s Bifrost, so the virtual keys, budgets, rate limits, guardrails and audit logs already configured at the gateway apply on the laptop. App governance lets administrators allow or block AI apps fleet-wide, with an approval workflow for newly detected apps, and MCP governance builds an inventory of MCP servers configured across supported apps, such as Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex and Cursor, and enforces allow or deny decisions on the device. For framework purposes, that discovered inventory is the third source behind component 1, and the per-device enforcement is what turns an acceptable-use clause into a control.

What runtime controls cannot do

Runtime enforcement is necessary but not sufficient. A gateway cannot tell whether a hiring use case is lawful, whether an impact assessment was honest, or whether the person assigned to oversight has real authority. It does not evaluate model quality, and it cannot see AI used on personal devices outside management. Those remain review-time and organisational controls. The argument is not that infrastructure replaces governance, but that governance without infrastructure produces paperwork rather than control.

Metrics that show the framework works

ISO/IEC 42001 clause 9.1 requires monitoring, measurement, analysis and evaluation, and NIST’s MEASURE function asks for metrics, but neither says which. A governance dashboard needs three kinds: coverage (is everything inside the framework), control health (are controls operating) and outcomes (is risk going down). Report them to management review quarterly and to the council monthly.

Two cautions. A rising guardrail trigger rate in the first month usually means the guardrails are finally seeing traffic, not that behaviour got worse. And a metric nobody acts on is decoration; each one should name the role in the RACI that responds when it moves the wrong way.

An AI governance maturity model

Maturity models are useful as a shared language for “where are we” and “what next”, not as a score. Five levels describe most organisations in 2026.

A policy and a committee with an inventory built from forms is level 2, however polished the documents. The step that matters most is from 2 to 3, because it is where written rules start operating without anyone remembering them. Level 5 is not required for the EU AI Act, but levels 3 and 4 are, in practice, what Article 12 logging and Article 26 oversight assume for high-risk systems.

A 90-day plan to stand up the framework

Consider a 3,000-person software company that sells into the EU and has US customers in Colorado and Texas, uses three model providers across a dozen internal applications, and has engineers running coding agents with MCP servers. A realistic first quarter takes it from level 1 or 2 to level 3, with the start of level 4.

Figure 4: The first quarter moves a framework from paper to enforced controls; certification comes later.

Days 1 to 30: see and own.

1. Appoint an executive owner and a governance council with security, legal, data, platform, HR and one business representative. Publish the RACI.
2. Build the first inventory from all three sources: a registration form for declared systems, provider invoices and API logs for observed usage, and an endpoint scan for installed AI apps and MCP servers.
3. Adopt the AI RMF function names and the AI 600-1 risk list as the shared vocabulary, so risk discussions use the same twelve categories, and keep the records Texas’s defence would expect.
4. Run the Article 5 check across the inventory, including the two prohibitions that apply from 2 December 2026, and block anything that fails.

Days 31 to 60: tier and enforce.

1. Assign every inventory entry a risk tier and a system owner. Flag Annex III categories and Colorado consequential decisions for a full impact assessment using ISO/IEC 42005 as the method.
2. Put a gateway in the path for internal applications. Replace shared provider keys with one scoped key per application or team, set model allow-lists and budgets, and turn on secrets and PII guardrails, starting in monitor mode where available.
3. Give agents their own keys with deny-by-default tool lists, define which action types need human approval, and write the agent and MCP standard.
4. Publish the acceptable-use policy and start role-based AI literacy training, which is also the Article 4 evidence.

Days 61 to 90: extend and evidence.

1. Extend routing to managed endpoints, starting with a volunteer group, and switch pending apps and MCP servers from allowed to blocked once the approval queue is under control.
2. Write the incident runbook around the kill switch: who can revoke a key, who decides on Article 73 and state-law reporting, and how after-action reviews feed the policy. Run one drill and record the time.
3. Stand up the metrics dashboard with the coverage and control-health measures above.
4. Produce the first crosswalk document: each control with its owner, NIST subcategory, ISO/IEC 42001 clause or control and EU AI Act article. That document is the backbone of a later 42001 certification.

By day 90 the company will not be certified, but it will be able to answer the four governance questions with data rather than assertions, and it will have fourteen months of operating evidence behind it when the Annex III obligations arrive on 2 December 2027.

Counter-arguments and the limits of the evidence

Four objections deserve a serious answer.

“Frameworks are paperwork; ship controls and skip the framework.” Controls without a framework drift. Without a risk tier, nobody knows which guardrails are mandatory for which system; without an owner, nobody reviews the logs. The framework is what tells the infrastructure what to enforce.

“The EU AI Act was delayed, so there is time.” Only the high-risk dates moved, and the Omnibus added a prohibition rather than removing one. Prohibited practices and AI literacy have applied since February 2025, general-purpose model duties since August 2025 and transparency obligations since August 2026. More practically, building inventory and logging takes quarters, and the Annex III date of 2 December 2027 is roughly fourteen months away.

“US state law is collapsing, so there is nothing to comply with.” Colorado’s law was narrowed and delayed, not abandoned: notice, documentation, human review and three-year record-keeping start on 1 January 2027. Texas is in force. And the federal push against state rules makes the requirements less predictable, which favours a framework built on stable references over one built around a single statute.

“NIST is being revised, so wait.” NIST says the AI RMF is being revised but has published no successor. The four functions and the inventory, tiering and incident outcomes are stable concepts that every other framework shares; a revision will change citations, not the work. Texas’s defence already points at “the most recent version” of the Generative AI Profile, so the citation update is built in.

There is also a limit to the evidence. No public study yet measures whether organisations with runtime enforcement have fewer AI incidents than those relying on policy and training. The case for runtime control rests on the structure of the problem, that agents decide at run time, rather than on outcome data. That is a reason to measure it inside the organisation: track guardrail triggers, blocked tools, kill-switch times and revoked keys, and review them alongside incidents.

The judgement

We think the right way to build an AI governance framework in 2026 is to treat NIST AI RMF as the vocabulary, ISO/IEC 42001 as the operating system and the EU AI Act as the strictest requirement set, to map all three onto one set of seven components with one owner per control, and to treat US state laws as extra notices and records on top. The component that decides whether the framework is real is not the policy or the committee but the control in the request path. Start with the inventory, put every model and tool call behind scoped identities with budgets, guardrails and logs, extend that to the laptops where agents and MCP servers now run, and let the metrics those controls produce drive the next round of policy.