AI governance framework: a practical guide

What is an AI governance framework?

An AI governance framework connects responsibilities, evidence and decisions across the life of an AI use. It helps a team explain what is being used, who may approve it, what remains uncertain and when to stop or review it. A policy is one part of that arrangement; a collection of completed forms is useful only if someone acts on the findings.

This guide is for small teams evaluating third-party AI, including AI features inside existing software. You will leave with a workable record model and a complete example of a proposed support assistant. The model is our editorial starting point, not an official framework or a compliance assessment. Keep your existing security, privacy, commercial and incident routes wherever they already work.

Already need a document? Open the complete policy draft or choose a record by task. The policy introduction and resource library provides a shorter starting point.

Compare three different kinds of guidance

NIST’s AI RMF resource page says version 1.0 is being revised. Its voluntary approach can organize risk work without claiming that every suggestion applies. ISO’s public catalogue identifies ISO/IEC 42001:2023, edition 1, published in December 2023. It concerns an AI management system, rather than a product approval checklist.

The Commission’s AI Act overview identifies Regulation (EU) 2024/1689 and explains its risk-based approach. Its 27 July 2026 AI Omnibus notice reports changes to implementation timing. Do not reuse an old general deadline for every system: check the current legislation and the obligations for your role and use. This guide does not classify your system or provide a legal timetable.

These are complementary sources, not three interchangeable templates. A team may use NIST to structure a use-case review, ISO to understand management-system work, and legal advice to establish applicable duties. Neither using NIST nor adopting an ISO-oriented process guarantees legal compliance. Start from the decision you need to make and the jurisdictions and people involved.

Use Govern, Map, Measure and Manage together

The NIST Core groups risk work into Govern, Map, Measure and Manage. Govern supports the other functions throughout the lifecycle; these are not four boxes to complete once in sequence.

• Govern: assign responsibility, approval authority, escalation and review expectations. In the fictional AI-001 case below, the Operations Lead is the proposed approving authority; the Support Lead owns the record.
• Map: describe the task, users, data, affected people and boundaries. AI-001 is limited to staff-reviewed draft support replies, excluding automatic sending and consequential customer decisions.
• Measure: select suitable evaluation methods and record evidence and uncertainty. AI-001 needs representative and difficult enquiries, checks for misleading replies and a documented data-handling review. No results have been supplied.
• Manage: decide how to treat risks, what conditions block use and who monitors changes. AI-001 remains awaiting evidence; any pilot would need its own recorded authorization and stopping conditions.

Move between functions as evidence changes. If testing exposes a new data flow, revisit scope and authority rather than simply adding a score. The NIST Playbook offers context-dependent suggestions, not a requirement to implement every action.

A small-team model: six linked records

Use a shared case identifier and link to the current evidence instead of duplicating it. One maintained document or spreadsheet may hold several records; you do not need a new platform. Keep confidential evidence within your own approved systems.

For each handoff, name a recipient, a decision and the open actions. A reviewer can say “evidence missing” without being forced to approve or reject everything immediately. An approver must still decide whether the missing evidence prevents the proposed activity. A pilot decision must specify its limits; it cannot silently authorize production use.

Connect this model to existing processes: link the privacy review instead of copying personal data into a new register, link the security review instead of collecting credentials, and use the existing incident channel. The record should say who can find the evidence and how its scope was checked. Restricted evidence can be referenced without publishing it.

AI-001: a complete fictional working example

Fictional teaching example throughout: a 25-person software team is considering a third-party assistant that drafts customer support replies. No supplier documentation, test result or authorization has been supplied. AI-001 is a proposed evaluation record, distinct from the separate illustrative pilot in the policy page.

The next action is an evidence request, not a green status badge. If the supplier only supplies a general marketing statement, the reviewer records its limited scope and leaves the relevant question unresolved. If a material data-handling question cannot be resolved, the Operations Lead decides whether to stop the proposal or restrict further evaluation to synthetic data under a separately approved plan.

Suppose evidence later supports a pilot: create a dated decision naming the permitted users, data, duration, conditions and who can pause it. Link that decision to AI-001 and update the inventory; preserve the earlier uncertainty. After testing, record the actual findings and a fresh decision about rollout. These are future steps in the fictional scenario, not outcomes claimed here.

Establish the model, then keep it useful

First-time setup checklist

1. Name the policy owner and approving authority. Record who resolves disagreements and who may pause use.
2. List existing AI tools and proposals with service owners; include embedded features and unknown ownership as explicit gaps.
3. Agree intake and evidence fields for one case. Reuse existing privacy, security and commercial reviews.
4. Run the route with a real proposal: record purpose, evidence requests, review findings and a decision or reason for waiting.
5. Link the decision and conditions to the inventory. Tell users where to find permitted scope and report concerns.

Maintenance checklist

• Service owner: check actual use against permitted scope and keep an agreed review date in the inventory.
• Reviewer: recheck evidence when the product, data, model or use changes; record what became outdated.
• Decision authority: resolve incidents and material gaps, recording restrictions, suspension or a new authorization.
• Policy owner: review whether people can follow the route; update responsibilities and remove unnecessary duplicate fields.
• Outgoing and incoming owners: hand over open actions and evidence access; preserve retirement history and the reason for closure.

For AI-001, the first review is due before a pilot decision. An arbitrary annual reminder would not resolve the immediate supplier evidence gap. Later cadence should reflect the use and its changes; the checklist does not impose one universal schedule.

Five practical questions

Does a small team need a committee?

Not automatically. Name an existing authority who can decide and escalate. Use a shared body when responsibilities cross teams and a single authority cannot resolve the decision. This guide does not establish a universal legal committee requirement.

Should we start with policy or inventory?

Start a short inventory while agreeing basic authority. The inventory reveals current use; the policy sets how it is reviewed. Test both against one case rather than waiting for a perfect policy before recording anything.

How do we handle tools already in use?

Name an owner, record actual use and data, and mark evidence and approval gaps. Prioritize review based on potential impact. Existing use is not proof of approval; the responsible authority must decide interim restrictions.

What if the supplier will not provide evidence?

Record the request, limitation and owner. Ask whether alternatives, independent tests or contract commitments can address the actual claim. Do not turn silence into a passing score; escalate material gaps before approval.

Does ISO/IEC 42001 replace the EU AI Act?

No. A management system standard and law have different roles. ISO’s public explanation distinguishes its standard from legal obligations. No certification or legal outcome is promised by this page.

Official sources, review date and limits

Source review: 3 November 2026. NIST AI RMF and Core support the risk functions; the Playbook supports selective use of suggestions. ISO’s public catalogue and explanation support the standard’s type, edition and legal boundary. The Commission’s AI Act overview and July 2026 notice support the legal context and warning about changed timing. Links appear beside the relevant claims above.

The six-record model, AI-001, ownership suggestions and checklists are original AI Gov Library editorial guidance. They do not reproduce the paid ISO standard or provide an official crosswalk, professional assessment, certification or compliance guarantee. Review the current official texts and seek the relevant specialist advice for your own use.