How to build an AI governance framework

An AI governance framework answers three questions for anyone in the organisation. Who can say yes to this AI use? What do I have to do before, during and after? Who checks? If people cannot answer those for the AI they work with, the framework does not exist yet, however many documents describe it.

This guide builds one in order, with a RACI you can adapt and an operating model that keeps it running.

Step 1: Pick a reference structure

Do not design a framework from a blank page. Two structures dominate, and either works as a spine.

ISO/IEC 42001 is a management system standard. It asks top management to show leadership and commitment (clause 5.1), set an AI policy (5.2) and assign roles, responsibilities and authorities (5.3), then to plan for risks, run AI risk and impact assessments, support the work with resources and competence, operate it, evaluate performance through monitoring, internal audit and management review, and improve. It can be certified, which matters if customers ask for it.

The NIST AI Risk Management Framework organises the work into Govern, Map, Measure and Manage. Its Govern function covers the framework itself, including documented roles and lines of communication (GOVERN 2.1) and executive responsibility for decisions about AI risk (GOVERN 2.3). It is voluntary and widely used outside the United States.

Pick one as the spine and map the other, plus any law that applies to you such as the EU AI Act, onto it. The framework measurement guide covers the mapping.

Step 2: Name the accountable executive

One senior executive answers for AI governance overall. That person needs the authority to pause or stop AI use, a budget, and a direct line to the board. Titles vary. Chief risk officer, chief data officer, chief technology officer and general counsel are all common. The title matters far less than three properties. The person must be senior enough to overrule a business unit, close enough to the work to understand it and not so conflicted that they approve their own projects without challenge.

Accountability cannot be outsourced. A consultant can build the framework and a platform can carry the records, but a named person in the organisation still answers for the outcome.

Step 3: Set risk appetite

Risk appetite tells everyone where the lines are before a specific proposal arrives. A practical AI risk appetite statement sorts uses into three groups.

• Pursue. Uses the organisation wants, with normal controls, for example drafting internal documents, code assistance and search over internal knowledge.
• Pursue with scrutiny. Uses that need committee approval and a full assessment, for example anything that shapes decisions about customers or staff, autonomous agents that act on other systems and customer-facing generated content.
• Do not pursue. Uses outside appetite, for example practices prohibited in markets you operate in, fully automated decisions with legal effect and no human review, or uses that contradict your published commitments.

The board or the executive committee should approve this statement, because it sets the boundary that everyone below them works within.

Step 4: Charter the committee

A governance committee makes the decisions that cut across teams. Its charter is the most important document in the framework, because it sets decision rights. A good charter covers the following.

• Purpose and authority. What the committee decides, such as approving higher-risk AI use, approving policy, accepting residual risk above a threshold and reviewing serious incidents, and what it only advises on.
• Membership. A chair, usually the accountable executive, plus standing members from technology, risk, legal, privacy, security and the business units that use AI most. Add an ethics or customer voice if your AI affects the public.
• Quorum and voting. How many members must be present and how decisions are taken, including how dissent is recorded.
• Escalation thresholds. Which proposals come to the committee and which are decided by the governance team under delegation. Tie this to the risk appetite groups.
• Meeting frequency. Monthly is typical, with an out-of-cycle route for urgent decisions.
• Reporting line. Who the committee reports to, usually the board risk committee, and how often.

Version the charter. A decision taken under last year’s charter should stay associated with the charter in force at the time.

Some organisations run two forums, a governance committee for risk and approval and a separate ethics committee for questions of values and public impact. That works when the hand-off between them is written down.

Step 5: Assign system owners

Every AI system and agent needs three named people, recorded against it in the AI register.

• A designated owner in the business who decides how the system is used and keeps its record current.
• An executive accountable for the system’s outcomes.
• A technical contact who knows how it works and can change it.

Ownership changes over time as people move roles, so keep the history, not only the current name. When an auditor asks who owned a system on a date last year, the answer should be a lookup.

Step 6: Agree the RACI

A RACI makes decision rights concrete. R is responsible for doing the work, A is accountable for the outcome (one per row), C is consulted and I is informed. Adapt this to your structure.

Activity	Board	Accountable exec	Committee	Governance team	System owner	Privacy, security, legal	Internal audit
Set AI risk appetite	A	R	C	C		C	I
Approve AI policies	I	A	R	R	C	C	I
Maintain the AI register		I		A	R	C
Decide low-risk AI use requests			I	A, R	C	C
Decide higher-risk AI use requests		I	A, R	R	C	C
Run risk and impact assessments			I	R	A	C
Accept residual risk above threshold	I	A	R	C	C	C
Deploy and maintain guardrails			I	A	C	R
Monitor production and act on alerts			I	C	A, R	C
Handle AI incidents	I	A	C	R	R	R
Vendor AI due diligence			I	C	A	R
Staff AI training		A	I	R	C	C
Report to the board	I	A	C	R		C
Test the framework	I	I	I	C	C		A, R

Two rules keep the RACI honest. Only one A per row. And the person who is A for running an assessment should not also be the only person who approves it, which is why the committee sits above the owner for higher-risk use.

Step 7: Write the policy set

The framework needs a small set of policies, each with an owner and a review date. The usual set is an acceptable use policy, an AI risk assessment policy, an AI ethics and human rights policy, an AI data governance policy, an AI incident response plan and a public AI transparency statement. The governance policies guide covers standing them up from templates.

Step 8: Set the operating rhythm

The operating model is what turns the framework from documents into practice. Split it into what change triggers and what the calendar triggers.

Triggered by change.

• A new AI use request goes through intake, gets an initial risk rating and is routed to the right approver.
• A new or changed system in the register triggers a risk assessment, and an impact assessment where people are affected.
• A vendor model update, a change in data or a change of purpose triggers reassessment and a guardrail review.
• A monitoring alert waits for a person to accept, dismiss or defer it.
• An incident opens the incident process.

Triggered by the calendar.

• Monthly, the committee decides escalated requests, reviews open findings and incidents and accepts residual risk.
• Quarterly, the accountable executive reports to the board. The board reporting guide sets out what the report contains.
• Annually, policies are reviewed, owners confirm their systems’ records are still accurate, vendor due diligence is refreshed, staff training is renewed and the framework is tested.

One view of recurring work helps. For each system, show when each piece of work was last done and flag what is going stale. That single view tells the governance team where to spend the week.

Step 9: Test and improve

Once a year, have internal audit or an external reviewer test the framework against the reference structure you chose in step 1. The audit preparation guide covers what they will ask for. Between audits, the maturity assessment gives a quicker read on which areas are ad hoc, defined or managed.

Sizing the framework

A framework for an organisation running six AI tools looks different from one running two hundred models and agents. Size by the AI you actually run.

• A handful of tools, none deciding about people. An accountable executive, an existing committee with an amended charter, a register, an acceptable use policy and a light intake form.
• Dozens of systems, some shaping decisions. A dedicated committee, a governance lead, full risk and impact assessments for higher-risk systems and guardrails on live AI traffic.
• Hundreds of systems and agents. A governance team, delegated decision rights by business unit, routing of requests to the right approvers, continuous monitoring and integration with your GRC platform.

Where Aicura fits

Steps 4, 5 and 8 are the ones that decay without a system behind them. In Aicura the three owner roles from step 5 sit on every system’s register record with their history, so the “who owned it last March” question is a lookup. At Pro, committees hold versioned charters, each decision is recorded against the charter in force when it was taken, and AI use requests route to the approvers named for a business unit and escalate to a committee when they need to.

The cadence view, Aicura’s screen for recurring work, is the operating rhythm made visible. It shows how long ago each piece of work was last done for each system, vendor, policy and course, and marks what is going stale. The framework design, and every decision in it, stays with your organisation.

A note on this page

This is a practitioner’s method, not legal advice. Where a framework or law that applies to you sets specific governance requirements, the primary source takes precedence.