AI Governance

AI Governance Framework: How to Structure Your Program in 2026

A complete blueprint for structuring an AI governance framework — from committee design and policy hierarchy to risk tiering and metrics — for organizations building one from scratch.

Jasper Claes

May 20, 2026 · 19 min read

AI Governance

Most "AI governance framework" content stops at principles — fairness, transparency, accountability — without ever describing the actual organizational structure needed to make those principles operate. This is the blueprint version: the policy hierarchy, committee structure, risk tiering, review cadence and metrics you need to run a program that survives contact with a real product roadmap.

TL;DR

A working AI governance framework has four layers: principles (rarely change), policy (what's allowed), standards (measurable requirements per risk tier), and procedures (step-by-step instructions).
Structure decision rights before choosing tooling — define who can approve, block, or grant exceptions to an AI system launch.
Risk tiering (commonly 3 tiers) determines review depth per system — most systems should move through governance quickly, with heavier scrutiny reserved for genuinely high-risk cases.
An annual cadence — policy review, risk register audit, training refresh, board reporting — keeps the framework from becoming a one-time project.
The most common structural mistake is designing the framework around compliance alone, without a genuine path for product and engineering to move fast on low-risk work.

What 'AI Governance Framework' Means in This Guide

This is distinct from AI governance tools — that's the software category. This is the organizational design underneath it: the policy hierarchy, roles, and cadence that a tool is meant to support. You can run a lightweight version of this framework with no software at all; tooling becomes necessary once the number of systems and approvers outgrows what a shared document can track reliably.

The Policy Hierarchy

Treat governance as four layers of increasing specificity, each changing at a different pace.

Each layer gets more specific — principles rarely change, procedures change often.

Principles — 3-5 statements defining why AI governance exists at your organization. These should rarely change.
Policy — what's allowed, what's prohibited, and who has authority to decide exceptions.
Standards — specific, measurable requirements per risk tier (e.g. "high-risk systems require a documented bias assessment before launch").
Procedures — the actual step-by-step instructions a product team follows to get a system approved.

Organizational Structure: Committee and RACI

Role	Responsible for
Executive sponsor	Ultimate accountability for the program's existence and resourcing
Governance committee chair	Runs the review cadence, chairs high-risk decisions
Legal representative	Advises on regulatory exposure per decision
Engineering/product representative	Represents delivery constraints and feasibility
System owners (distributed)	Day-to-day compliance of their specific AI systems

Designing a Risk Tiering Model

Three tiers is a reasonable starting point for most organizations: low risk (internal tools, no material decision impact), medium risk (customer-facing but human-reviewed), and high risk (affects employment, credit, health, legal or safety outcomes). The tiering model's job is routing — low-risk systems should clear governance in days, not weeks, while high-risk systems get proportionally more scrutiny.

Writing an Actual Risk Appetite Statement

Vague risk appetite statements ("we take AI risk seriously") don't help anyone make a decision. Specific ones do.

Vague (unusable)	Specific (usable)
We prioritize responsible AI.	No AI system may make a final employment decision without human review of the recommendation.
We manage AI risk carefully.	High-risk systems require documented bias testing before launch and every 6 months thereafter.
We value transparency.	Any customer-facing AI system must disclose that it is AI-generated, without exception.

The Intake and Registration Process

A short intake form captures purpose, data sources, and intended users before any build work is evaluated for risk.
An initial risk tier is assigned based on intake answers, subject to review.
The system is registered in a central record, visible to legal, security and compliance — not just the owning team.
Approval routing follows automatically from the assigned tier.

Review Cadence by Tier

Tier	Review frequency
Low	Annual, or on material change
Medium	Every 6 months, or on material change
High	Quarterly, plus continuous incident monitoring

A simple annual cadence keeps governance from becoming a once-and-forgotten project.

Metrics and Board Reporting

Metric	Why boards care
Number of registered AI systems by tier	Shows the scale of exposure the organization is managing
% of high-risk systems reviewed on schedule	Direct evidence the framework is operating, not just documented
Number and severity of AI-related incidents	Trend line matters more than any single data point
Number of exceptions granted	Signals whether policy is realistic or routinely overridden

Training and Culture: The Part That's Easy to Skip

A governance framework that lives only in a policy document fails the moment an engineer who's never read it ships a feature. Baseline AI literacy training — what the policy requires, why, and how to use the intake process — needs to reach every team building or buying AI, not just the compliance function.

Connecting Governance to Incident Response

When an AI system causes harm or fails unexpectedly, the governance framework should already define who's notified, how severity is assessed, and whether the system's risk tier or approval needs to be revisited. Treating incidents as purely an engineering concern, disconnected from the governance record, means the same failure mode can recur without ever updating the policy that should have caught it.

Common Structural Mistakes

Designing only for compliance, not velocity. If every system — regardless of risk — goes through the same heavy process, teams will route around it.
No executive sponsor. Without genuine authority behind it, a governance committee becomes advisory in name and ignorable in practice.
Static risk appetite. Written once, never revisited as the business or regulatory environment changes.
No connection between incidents and policy updates. The same failure recurs because governance and incident response operate in separate silos.

A Realistic 3-Year Maturity Roadmap

Year	Focus
Year 1	Establish policy hierarchy, committee, and intake process; register existing systems
Year 2	Formalize review cadence by tier; introduce metrics and board reporting
Year 3	Close the loop — incident data and monitoring actively inform policy updates

Primary Sources

NIST — AI Risk Management Framework
EUR-Lex — Regulation (EU) 2024/1689

Where Unorma Fits

Operationalizing the framework

Once the framework is designed, Unorma’s AI inventory and oversight modules operationalize the intake, tiering and review cadence described here, while incident tracking closes the loop back to policy. See AI Governance Tools Explained for how the software layer maps to this structure.

Frequently asked questions

What's the difference between an AI governance framework and AI governance tools?

The framework is the organizational design — policy hierarchy, committee structure, risk tiering, review cadence. Tools are software that operationalizes that design at scale. You can run a lightweight framework manually before you need tooling.

How many risk tiers should we start with?

Three (low, medium, high) is a practical starting point for most organizations — enough to route review effort proportionally without becoming too complex to apply consistently.

Who should chair the AI governance committee?

Typically a compliance or risk leader with genuine executive backing — the role needs both subject-matter credibility and enough organizational authority to make decisions stick.

How often should governance policy be reviewed?

At least annually, and immediately after any AI-related incident or major regulatory change — a policy that's only revisited on a fixed schedule misses lessons from real events.

What's the biggest reason AI governance frameworks fail in practice?

Designing for compliance alone without a fast path for low-risk work — when every system faces the same heavy process regardless of risk, teams find ways to route around governance entirely.

Do we need board-level reporting from day one?

Not necessarily, but building simple metrics (systems by tier, on-schedule reviews, incidents, exceptions granted) early makes it much easier to introduce board reporting later without a scramble to reconstruct historical data.

How does incident response connect to the governance framework?

Incidents should trigger a defined process that can update a system's risk tier or trigger a policy review — treating incidents purely as an engineering concern, disconnected from governance, allows the same failure mode to recur.

Key terms in this article

About the author

Jasper Claes

Compliance Manager & AI Governance Consultant

Compliance Manager and consultant specializing in AI governance for high-scale technology companies operating in regulated markets.

View full profile

Keep reading