AI Governance Framework: A Practical Guide

Practical guide · Build · Version 1.0, October 2026

An AI governance framework is the set of roles, policies, processes, and controls an organization uses to decide which AI it uses, how that AI is built or bought, and how its risks are managed over time. A good one is not a document. It is a working system that produces evidence: proof you can hand a regulator, an auditor, or an enterprise customer.

This guide answers one question: what do you need in place to actually run AI governance? It walks through every component, from ownership and the committee to incidents and board reporting, and gives you the working artifacts: a RACI, a committee charter, a policy outline, inventory fields, risk-rating criteria, an approval workflow, assessment questions, an evidence checklist, and a 30/60/90-day plan.

The seven building blocks of an AI governance framework

Every effective AI governance framework, whatever standard it follows, rests on the same seven blocks. Two form the foundation; five do the daily work.

1. Roles and accountability. An executive sponsor, a cross-functional AI committee, and a named owner for every AI system. Without owners, nothing else gets done.
2. Policy and standards. The written rules: what is allowed, what is banned, and what each risk tier requires.
3. AI inventory. A living list of every AI system, including AI features inside vendor software and the public tools staff use.
4. Risk assessment. A consistent way to rate each system’s risk before it is used, based on what it decides, whose data it touches, and what it can do.
5. Controls and testing. Evaluations, red teaming, access restrictions, and guardrails, scaled to the risk tier.
6. Monitoring and incidents. Logging, output checks, change control, and a clear path for reporting and fixing AI failures.
7. Third-party AI. Due diligence and contract terms for the vendors and models you rely on.

Operating model and ownership

AI governance fails most often for one reason: nobody owns it. Before writing any policy, decide who sets the rules, who runs the program day to day, and who is accountable for each AI system.

Most organizations use a hub-and-spoke model. A small central function (the hub) sets standards, keeps the inventory, and runs the committee. Each business unit (the spokes) owns its own AI systems and their risks. Use your existing three lines of defense: business owners manage the risk, risk and compliance oversee it, and internal audit gives independent assurance.

Core roles

• Executive sponsor: a senior leader accountable for the program, who breaks ties and secures budget.
• AI governance committee: the cross-functional body that approves policy and high-risk systems.
• AI governance lead: runs the program day to day: inventory, intake, tiering, reporting.
• Business owner (per system): accountable for the system’s use, risk, and outcomes.
• Technical owner (per system): builds or configures it, tests it, and monitors it.
• Legal, privacy, security: assess their domain risks and set required controls.
• Internal audit: tests whether the program works, independently.

RACI for AI governance

R = responsible, A = accountable, C = consulted, I = informed.

In a small organization, one person may hold several of these roles. That is fine, with one exception: the person who builds a high-risk system should not be the one who approves it.

The AI governance committee and decision rights

The committee exists to make decisions, not to discuss AI. Write down exactly which decisions it owns and which sit elsewhere, or every question will land on its agenda.

Decision rights

Committee charter template

1. Purpose: oversee the organization’s use of AI so that it is lawful, safe, and aligned with risk appetite.
2. Authority: approve AI policy and standards, high-risk and restricted AI use, and exceptions; pause or withdraw any AI system.
3. Membership: chair (executive sponsor or delegate); AI governance lead (secretary); legal; privacy; information security; risk and compliance; data or technology lead; business representatives. Internal audit attends as an observer, without a vote.
4. Quorum: at least half of voting members, including legal or privacy and security.
5. Meetings: monthly, plus ad hoc for urgent approvals or incidents.
6. Standing agenda: new high-risk requests; open exceptions and their expiry dates; incidents since the last meeting; inventory and metrics; regulatory changes.
7. Decisions and records: decisions by majority of a quorum; minutes record each decision, its rationale, and any conditions.
8. Reporting: quarterly report to the executive team or board.
9. Conflicts of interest: members declare an interest and abstain from deciding on their own systems.
10. Review: charter reviewed annually.

The minutes are evidence. Record each decision, the conditions attached, and who voted, because that is the first thing an auditor will ask to see.

How to write an AI governance policy

Your AI policy should be short enough to read and specific enough to test. If an auditor cannot turn a sentence into a yes-or-no test, rewrite it. “AI must be used responsibly” fails that test. “Every AI system is risk-rated before go-live and approved by the AI Committee” passes.

AI policy outline

Keep the policy to a few pages. Put the detail in standards and procedures underneath it, so the policy stays stable while the procedures change with the technology.

Supporting standards to write under the policy

• AI risk classification standard: the tiering criteria and what each tier requires.
• AI development and procurement standard: documentation, testing, and approval steps for systems you build or buy.
• AI acceptable use standard: rules for staff using AI tools, including what data may be entered.
• AI monitoring and incident standard: what is monitored, thresholds, and how incidents are handled.
• AI vendor standard: due diligence and required contract terms for third-party AI.

Prohibited and restricted uses

A short, explicit list removes most of the guesswork for staff. Use three categories: prohibited (never allowed), restricted (allowed only with committee approval and extra controls), and permitted (allowed under the normal process).

Prohibited (examples to adapt)

• Entering confidential, client, or regulated personal data into AI tools that are not on the approved list.
• AI that manipulates people’s behavior in ways that could harm them, or exploits vulnerabilities related to age, disability, or financial situation.
• Social scoring of individuals, or inferring sensitive traits (such as health, religion, or sexual orientation) from biometric or behavioral data.
• Emotion recognition of employees or students, except for medical or safety reasons.
• Fully automated decisions with legal or similarly significant effects on people, with no human review.
• Generating content that impersonates a real person without consent.

Several of these mirror practices prohibited under the EU AI Act. If you operate in the EU, have legal confirm your list against the Act’s current text.

Restricted (committee approval required)

• AI used in hiring, promotion, termination, or performance evaluation.
• AI used in credit, insurance, housing, healthcare, or education decisions.
• Customer-facing AI that gives advice or makes commitments on the organization’s behalf.
• AI agents that can take actions in production systems, send external communications, or move money.
• AI trained or fine-tuned on personal data.
• Biometric identification or categorization.

The AI inventory: fields to capture

The inventory is the backbone of the program: every other control is applied to what is on it. Track use cases, not just tools, because the same tool can be low-risk in one use and high-risk in another.

Find AI in four places: systems you build, AI features inside software you already license, standalone AI tools bought by teams, and public tools used by staff. Procurement records, expense reports, SaaS discovery tools, and a simple survey of department heads will surface most of it.

Review the inventory at least quarterly, and require an update whenever a system’s purpose, data, model, or user base changes.

Intake and approval workflow

Every new AI use case, and every material change to an existing one, enters through a single front door: a short intake form. One process for everything keeps the inventory complete and stops teams from going around governance.

Intake form fields: use case name and purpose; business owner; vendor or build; AI type; data involved; who is affected; decisions it supports; actions it can take; countries of use; planned go-live date. These map directly to the inventory fields, so an approved request becomes an inventory record automatically.

Set service levels so governance does not become a bottleneck. For example, low-risk requests decided within a week, and high-risk requests reach the next committee meeting. If the process is slow, people will skip it.

Risk classification: how to tier AI systems

Tiering lets you spend effort where the risk is. Three tiers are enough for most organizations. Rate each system on the criteria below; the highest rating on any single criterion sets the tier, and any restricted use is automatically high.

Risk-rating criteria

What each tier requires

AI risk and impact assessment questions

A risk assessment asks what could go wrong for the organization; an impact assessment asks what could go wrong for the people affected. For medium-risk systems, use the first five groups. For high-risk systems, use all of them.

1. Purpose and context

• What problem does the system solve, and what happens today without it?
• Who uses it, and who is affected by its outputs?
• Is AI necessary here, or would a simpler approach work?

2. Data

• What data does it use for inputs, retrieval, and training? Does any of it include personal, confidential, or client data?
• Do we have the right to use this data for this purpose?
• Where is data stored and processed, and for how long? Does the vendor train on it?

3. Performance and limitations

• How accurate does it need to be, and how will we measure that?
• What are the known failure modes, such as hallucination, outdated information, or misreading edge cases?
• What happens when it is wrong, and who notices?

4. Security and access

• Can it reveal information a user should not see?
• Could someone manipulate it through its inputs (prompt injection)?
• What systems can it reach, and under whose permissions?

5. Oversight and accountability

• Where does a human review outputs, and can they realistically override them?
• How will users know they are dealing with AI?
• Who is accountable if it causes harm?

6. Impact on individuals (high risk)

• Could outcomes differ unfairly across groups, such as by age, gender, ethnicity, or disability? How will we test that?
• Can affected people understand, question, or appeal a decision?
• What is the worst realistic harm to a person, and how is it prevented?

7. Legal and regulatory (high risk)

• Which laws apply in each place it is used?
• Does it fall in a regulated high-risk category, and are we the provider or the deployer?
• What notices, disclosures, or registrations are required?

End every assessment with three outputs: the risk tier, the required controls, and any conditions on approval.

Human oversight in practice

“A human in the loop” means little unless that human has the time, information, and authority to disagree with the AI. Oversight is only real if reviewers sometimes overturn outputs, and you can show it.

Design oversight around four questions:

1. Where does a person review the output: before it takes effect, after, or only by sampling?
2. Who reviews, and are they trained and senior enough to override?
3. What do they see: the output alone, or also the inputs, sources, and confidence?
4. How is an override recorded, so you can prove reviews happen?

Watch for automation bias. If reviewers accept nearly every output, either the system is excellent or the review has become a rubber stamp. Sample their decisions to find out which.

Testing and validation before go-live

The rule that matters most: set pass criteria before you test. Results judged against thresholds chosen afterward prove nothing.

Document the test plan, the test data, the results, and who signed off. Keep the test set, because you will rerun it after every model or prompt change.

Monitoring after go-live

AI systems change even when nobody touches them: vendors update models, source documents change, and users find new ways to use the tool. Monitoring catches the drift.

What to monitor

• Quality: rerun a sample of the test set on a schedule; track user feedback and complaint rates.
• Usage: who is using it, how often, and for what. Watch for use beyond the approved purpose.
• Safety and security: blocked prompts, guardrail triggers, attempted injections, unusual access patterns.
• Fairness: outcome rates across groups, for high-risk systems affecting individuals.
• Human oversight: override rates and review times.
• Change: vendor model updates, prompt edits, new data sources, and new tools or integrations.

Set a threshold for each metric and name who gets alerted when it is crossed. A dashboard nobody acts on is not a control.

Logging: keep enough to reconstruct what happened: who asked, what the system retrieved, which model and prompt version answered, what it output, and any actions taken. Balance this against privacy: log what you need, restrict access to logs, and set a retention period.

AI incidents and escalation

Define an AI incident broadly: any event where an AI system causes, or nearly causes, harm or a breach of policy. Examples include a chatbot revealing restricted data, an agent sending an unauthorized email, a biased outcome pattern, or a confidently wrong answer that a customer relied on.

Route AI incidents through your existing incident process rather than building a new one. Add AI-specific triage questions and these severity levels:

After every critical or high incident, run a short review: root cause, what control failed, and whether the risk tier or assessment needs updating. Some laws impose reporting duties for serious AI incidents or data breaches, so involve legal early.

Exceptions

Some teams will need to deviate from policy: a pilot that cannot meet every testing requirement yet, or a vendor that will not accept a contract clause. A clear exception process keeps these visible instead of hidden.

Every exception should record:

• The policy requirement being waived, and why it cannot be met now.
• The risk created, and the compensating controls in place.
• Who requested it and who approved it (the AI committee for anything medium or high risk).
• An expiry date: 90 days to 6 months, never open-ended.
• The plan to close it.

Review open exceptions at every committee meeting. An exception that is renewed again and again is a sign the policy needs to change.

Training: who needs what

Track completion. Under Article 4 of the EU AI Act, providers and deployers must take measures to support AI literacy among staff who deal with AI systems. The Digital Omnibus softened this duty in July 2026 (it no longer requires guaranteeing a specific level for each person), but it remains mandatory, and training records are your evidence.

AI governance documentation: the minimum evidence pack

When an auditor, regulator, or customer asks how you govern AI, these are the documents they expect. If you can produce all of them quickly, with current dates, your program is real.

Evidence retention

Evidence that cannot be found is evidence that does not exist. Store it in one place, organized by AI system, and set retention periods with legal.

• Keep governance records (policy versions, committee minutes, approvals, exceptions) for at least as long as your organization keeps other compliance records, typically several years.
• Keep system records (assessments, test results, model cards, change logs) for the life of the system plus your standard retention period after it is retired.
• Keep operational logs as long as needed for investigation and monitoring, then delete them under your privacy rules. Logs often contain personal data.
• Where a law sets a specific period (for example, documentation duties for high-risk AI under the EU AI Act), that period wins.

Evidence checklist

• Approved AI policy and standards, with version history
• Committee charter, membership list, and minutes with decisions
• Current AI inventory with last-review date
• Intake records for every new use case
• Risk tier and rationale for every system
• Risk and impact assessments for medium- and high-risk systems
• Approval records dated before go-live
• Test plans with pass criteria set in advance, results, and sign-off
• Model or system cards for high-risk systems
• Human oversight design and override logs
• Monitoring reports, thresholds, and alerts
• Incident log and post-incident reviews
• Exception register with expiry dates
• Vendor assessments and AI contract clauses
• Change log for models, prompts, and data sources
• Training completion records
• Board and executive reports

Metrics and reporting

Report a small set of metrics that show whether the program is working, not just how busy it is. A quarterly one-page report to executives or the board is usually enough.

Add a short narrative: the top three AI risks, decisions the board needs to make, and what changed since last quarter.

How to build an AI governance framework in 90 days

You do not need a year-long program to start. In 90 days you can have the foundation in place and the first evidence in hand.

Start with the inventory, not the policy. Most organizations discover far more AI than they expected, especially AI features switched on inside existing software, and that discovery shapes every rule you write. By day 90 the goal is not perfection. It is a program that runs, with records to prove it.

The 30/60/90-day plan in detail

After day 90, plan an internal audit or independent review within the first year to confirm the controls operate as designed.

How the major AI governance frameworks fit together

You do not need a separate program for each framework. Build one internal framework from the seven building blocks, then map it to whichever of these apply to you.

Treat the extra time as runway, not a reprieve. Risk management, documentation, and human oversight take longer to build than most teams expect. Our COMPLY guides map each framework requirement to an action, an owner, and the evidence to keep.

How to check that your framework works

An AI governance audit asks one question: do the controls described in the policy actually operate? Every test follows the same chain.

1. Risk: what could go wrong.
2. Control objective: what must be true to prevent it.
3. Control: the specific activity that makes it true.
4. Evidence: the record the control leaves behind.
5. Test: how you check the evidence, usually by sampling.
6. Conclusion: effective, partially effective, or not effective.

Here is that chain applied to six common controls.

The permission test in that table is the one most audits skip. Reading a policy is easy; re-performing a control as a real user is what separates assurance from paperwork. For full audit procedures, including sampling, evidence requests, and how to write findings, see our AUDIT guide.

Common mistakes that fail audits

• A policy with no inventory. Rules mean little if you cannot list the AI they apply to.
• Vendor AI left out of scope. Copilots and AI features in existing SaaS tools are often the largest AI footprint.
• Approvals after launch. An approval dated after go-live is a finding, not a control.
• Testing without pass criteria. Results that were never measured against a threshold prove nothing.
• Trusting the system prompt as a control. Instructions to a model are not access control; permissions must be enforced outside the model.
• No change control for prompts and models. Swapping a model version or editing a prompt can change behavior as much as a code release.
• Governance that never meets. A committee with no minutes is a committee that does not exist, as far as evidence goes.

Frequently asked questions

What is the difference between an AI governance framework and an AI policy?

The policy is one component: the written rules. The framework is the whole system around it, including roles, inventory, risk assessment, controls, monitoring, and the evidence each produces.

Which AI governance framework should we follow?

Most organizations use NIST AI RMF as the practical risk method, ISO/IEC 42001 when they want a certifiable management system, and the EU AI Act where they have legal obligations. You do not have to choose one; build one internal framework and map it to each.

Do small companies need an AI governance framework?

Yes, but scaled down. A short policy, an inventory, a risk tier for each system, and named owners cover most of the risk for a small team.

How long does it take to build?

A working foundation (policy, inventory, risk process, approvals) can be in place in about 90 days. Maturity, meaning evidence that controls operate over time, takes longer.

Who should own AI governance?

A named executive sponsor, with a cross-functional committee drawing on legal, privacy, security, risk, and the business. Ownership of each individual AI system stays with the business owner who uses it.

Can AI governance be audited?

Yes. Internal audit can test it like any control environment: sample systems, check approvals and testing evidence, and re-perform key controls such as access restrictions.