How to Build an AI Governance Framework That Teams Can Actually Follow

An AI governance framework is the set of policies, roles, processes and technical controls an organization uses to decide which AI systems it builds or buys, how their risks are assessed, which safeguards each must have, and how they are monitored once they are live. The best frameworks are proportionate, so low-risk uses move quickly and high-risk ones get real scrutiny, and they collect evidence from the platform automatically instead of relying on questionnaires.

This guide lays out the components of a practical framework and shows how they map to the NIST AI Risk Management Framework, ISO/IEC 42001 and the EU AI Act.

The components at a glance

A working AI governance framework has eight parts:

1. Policy. What the organization allows, requires and prohibits.
2. Roles and accountability. Who owns decisions, and who provides assurance.
3. Inventory. A current record of every AI system, model and AI-enabled vendor feature in use.
4. Risk tiering. A consistent way to classify each use case by potential harm.
5. Review and approval. A workflow, scaled to the tier, that decides whether a system can launch.
6. Controls. The specific safeguards required at each tier, implemented in the platform where possible.
7. Monitoring and incident response. How systems are watched after launch and what happens when something goes wrong.
8. Literacy and training. What people need to know to use and build AI responsibly.

Policy: short, specific, and backed by standards

The top-level AI policy should fit on a few pages. It states principles, defines scope (including third-party and embedded AI), names prohibited uses, sets the requirement to register and risk-tier every AI system, and assigns accountability. Detail belongs in standards underneath it: an acceptable use standard for employees, a development standard for builders, a procurement standard for vendors, and data handling rules for prompts, outputs and training data.

A policy that tries to cover every scenario becomes unreadable and goes stale quickly. A policy that points to maintained standards stays useful.

Roles and accountability

Governance fails most often because accountability is diffuse. A structure that works in most enterprises:

• Accountable executive. One named person, often a Chief AI Officer, CDAO, CIO or Chief Risk Officer, owns the framework.
• AI review board or council. A cross-functional group from technology, security, privacy, legal, compliance, risk and the business that sets standards and reviews higher-risk systems.
• System owners. A business owner accountable for each AI system’s purpose, performance and compliance, and a technical owner accountable for how it is built and run.
• Second line. Risk, compliance and, in banks, model risk management (where supervisory guidance such as SR 11-7 already sets expectations for model validation) provide independent challenge.
• Third line. Internal audit tests whether the framework works as designed.

The AI inventory

You cannot govern what you have not listed. The inventory should cover internally built systems, AI features in SaaS products, and models accessed directly. For each entry, capture at least:

Field	Why it matters
Purpose and business owner	Accountability and scope
Users and affected people	Who could be harmed, and how
Models and providers, with versions	Change tracking and vendor risk
Data used, with classifications	Privacy, confidentiality and residency
Degree of autonomy	Whether it advises, decides, or acts
Risk tier and approval record	Which controls apply and who signed off
Evaluation results and monitoring links	Evidence that it works as intended

Keep the inventory connected to the platform. If every model call goes through an LLM gateway, unregistered workloads show up in the gateway’s logs, which makes shadow AI much easier to find. Our AI model inventory template sets out the full field list, a model card template and the other places shadow and embedded AI turn up.

Risk tiering

Tiering keeps governance proportionate. The criteria should reflect your own risk appetite and regulatory environment, but an example structure looks like this:

Tier	Example criteria	Example required controls
Prohibited	Uses your policy or applicable law bans	Not permitted
High	Affects legal rights, credit, employment, health, safety or access to essential services; acts autonomously on customers or regulated records	Full review board approval, documented impact assessment, pre-launch evaluation against defined thresholds, human oversight design, ongoing monitoring, periodic revalidation
Moderate	Customer-facing content or advice with human review; internal decisions with material business impact	Streamlined review, evaluation suite, disclosure where appropriate, logging, owner attestation
Low	Internal productivity with no sensitive data and a human using the output	Registration, approved tools only, standard logging

Tiering should be done with a short structured questionnaire that produces a tier automatically, with the review board able to adjust it. Revisit the tier when the system’s purpose, data, users or autonomy change.

Review boards that do not become bottlenecks

A review board that sees every AI idea becomes the reason nothing ships. Design it to scale:

• Route by tier. Low-tier systems are registered and approved automatically if they use approved components. Moderate-tier systems get a delegated reviewer. Only high-tier systems go to the full board.
• Publish service levels. Teams should know how long a review takes at each tier.
• Review evidence, not promises. Ask for evaluation results, architecture diagrams, data flows and threat models, generated from the platform where possible.
• Pre-approve patterns. A retrieval assistant built on the approved RAG pattern and gateway should need far less review than a novel design.

Write these rules down. Our AI architecture review board charter template covers scope triggers, members, decision rights and service levels.

Agents that take actions need a few controls of their own, including an agent registry, autonomy tiers and approval rules. We cover those in AI agent governance.

Mapping controls to the NIST AI RMF

The NIST AI Risk Management Framework (AI RMF 1.0, published January 2023) is voluntary guidance organized around four functions. Govern is cross-cutting; Map, Measure and Manage apply across the life of each system. NIST also published a Generative AI Profile, NIST AI 600-1, in July 2024, which describes risks specific to generative AI and suggested actions against them.

Function	What it covers	Example controls in your framework
Govern	Culture, policies, accountability, and processes for managing AI risk	AI policy and standards, named owners, review board charter, training, third-party AI procurement rules
Map	Understanding context: purpose, users, affected people, data, and potential impacts	Inventory entry, use-case intake, risk tiering, impact assessment for high-tier systems
Measure	Assessing and tracking risks with quantitative and qualitative methods	Evaluation suites, bias and robustness testing where relevant, red teaming, security testing, monitoring metrics
Manage	Prioritizing and acting on risks, including response and recovery	Launch approval, human oversight design, incident response, rollback, decommissioning, periodic revalidation

Using these functions as the organizing structure gives you a common vocabulary with auditors, customers and regulators who already know the framework. Our NIST AI RMF implementation guide goes through each function in more detail.

ISO/IEC 42001

ISO/IEC 42001:2023 specifies requirements for an AI management system. It follows the same high-level management system structure as standards such as ISO/IEC 27001, so organizations already certified for information security will recognize the pattern: context, leadership, planning, support, operation, performance evaluation and improvement, plus an annex of AI-specific controls.

The practical difference from the NIST AI RMF is that ISO 42001 is certifiable. An accredited certification body can audit you against it, which some customers and partners now ask about. The two fit together well: the NIST functions shape how you manage risk for each system, and ISO 42001 wraps that in an auditable management system. See our ISO 42001 readiness guide.

The EU AI Act

The EU AI Act, Regulation (EU) 2024/1689, entered into force on 1 August 2024 and applies in phases. It takes a risk-based approach: certain practices are prohibited, high-risk systems carry substantial obligations (risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy and robustness), some systems carry transparency duties such as telling people they are interacting with AI, and providers of general-purpose AI models have their own obligations.

The prohibitions have applied since February 2025, and the general-purpose AI model obligations since August 2025. The Digital Omnibus amendments, published in July 2026, moved high-risk obligations for Annex III systems to 2 December 2027 and for product-embedded systems to 2 August 2028, so confirm current dates with counsel before planning around them.

The Act can reach US companies whose AI systems or outputs are used in the EU. If your inventory and tiering are already in place, mapping systems to the Act’s categories becomes a classification exercise rather than a discovery project. Our guide to the EU AI Act for US companies covers scope in more depth.

Build the controls into the platform

The most effective governance is evidence the platform produces as a side effect of normal work:

• The gateway records which models each workload uses, with what data classification, and at what cost.
• The evaluation harness stores results for every release, so reviewers see measured quality rather than claims.
• Architecture decision records and design templates capture data flows and threat models once, for reuse.
• Approvals are recorded in the same system that deploys the workload, so nothing reaches production without one.
• Monitoring alerts owners when quality, safety or cost metrics drift beyond agreed thresholds.

Common failure modes

• Policy without inventory. Rules exist, but nobody knows which systems they apply to.
• One-size review. Every use case gets the same heavy process, so teams route around it.
• Launch-only governance. Systems are reviewed once and never again, even as models and data change.
• Vendor AI ignored. Embedded AI features in SaaS tools escape review entirely.
• No incident path. When an AI system misbehaves, nobody knows who can pause it or how.

Getting started

1. Appoint an accountable executive and charter a small review group.
2. Publish a short policy and an acceptable use standard.
3. Build the inventory, starting with what the gateway, procurement records and a short survey reveal.
4. Define tiers and required controls per tier.
5. Pilot the review process on three to five real systems across tiers, and adjust.
6. Automate evidence collection through the platform.
7. Map your controls to the NIST AI RMF functions, and to ISO 42001 or the EU AI Act where they apply.

How we help

We design AI governance frameworks that are proportionate to risk and built into the platform, from policy and tiering to review workflows and automated evidence. Our AI governance and risk work is especially relevant in regulated sectors such as financial services. To assess where your governance stands today, contact us.