AI Governance Framework: Roles, Policies and Evidence

An AI governance framework defines who can approve AI uses, which rules apply, what evidence supports decisions and how problems are handled. It connects system development and procurement to responsibility during use. NIST’s AI Risk Management Framework treats governance as an activity that continues across the AI lifecycle. NIST AI RMF 1.0, section 5.1

A useful starting point is a system register, clear decision rights and a repeatable review of risks and controls. This guide proposes a practical way to organise those records. It does not prescribe a company methodology, staffing model or universal risk score. Sources were checked on 14 September 2026.

Choose references for the job they do

The references below answer different questions. Select them according to the organisation’s objectives, systems and legal obligations.

ReferenceWhat it providesHow to use it carefully
NIST AI RMF 1.0Voluntary guidance for understanding and managing AI risks, organised around Govern, Map, Measure and Manage.Select relevant outcomes and adapt the work to the use. NIST says a revision is in progress.
ISO/IEC 42001:2023Requirements for an organisational AI management system.Use the full standard when assessing conformity to it. This guide relies on ISO’s public description, not an inspection of its normative clauses.
ISO/IEC 23894:2023Guidance for integrating AI risk management into organisational activities.Its public abstract emphasises adaptation to organisational context. It does not establish a universal operating model.
EU AI Act and other applicable lawLegal requirements with specific actors, scope, dates and exceptions.Maintain an applicability assessment for each use; a management-system label does not establish that each legal duty has been met.

Sources: NIST framework overview, ISO 42001 public summary, ISO 23894 public abstract, AI Act.

NIST’s four functions are connected activities, not four maturity stages or an ordered checklist. Governance supports the other functions throughout the work. Teams can revisit the context, measurements and response decisions when a system or its use changes. NIST AI RMF 1.0, section 5

An internal review should examine who could be affected, how serious an error could be, whether people can challenge an outcome, what data is used and how dependent the organisation becomes on the system. NIST’s Map function supports documenting intended uses, context, impacts and limitations. NIST AI RMF 1.0, Map 1, 2 and 5

Alongside that review, record the legal analysis. Under the EU AI Act, relevant checks include prohibited practices, the two Article 6 high-risk routes, transparency requirements and provider or deployer status. A score chosen by the organisation cannot determine the legal classification or cancel an applicable obligation. AI Act, Articles 3, 5, 6, 25 and 50

RecordWhat it should explain
Legal applicabilityRelevant provision, organisational role, intended use, application date, exception or transition, and supporting reasoning
Operational riskPotential harm, affected people or processes, likelihood and uncertainty, existing controls and remaining concerns
Decision priorityWork that must precede use, issues requiring specialist review, conditions for proceeding and triggers for reconsideration

These are suggested records. If the organisation uses a scoring scale, define what its terms mean and how evidence supports a rating. Keep the underlying reasoning visible; two different failure modes can receive a similar score while needing different controls.

The AI Act timetable also needs precision. Chapter III, Sections 1–3, except Article 6(5), apply from 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Article 6(1)/Annex I systems, subject to sectoral scope and transition rules. Other duties already apply, including amended Article 4 literacy measures and Article 50 transparency within its scope. AI Act, Articles 2, 4, 50, 111 and 113

The EU AI Act compliance guide explains the classification boundaries, current dates and provider/deployer distinctions in more detail.

Assign decisions to people with the authority to act

Start with the decisions that the organisation actually faces. Name the person or function responsible for each decision and specify the information they need. NIST’s Govern function addresses responsibilities, communication, leadership accountability and appropriate training. It does not require every organisation to copy the same committee structure. NIST AI RMF 1.0, Govern 2

The following allocation is a proposed starting point:

DecisionResponsibility to assignEvidence to record
Approve an intended useAn owner who understands the process and its effectsPurpose, expected benefit, affected people and conditions of use
Approve technical readinessA reviewer competent to assess the system and its limitationsEvaluation results, integration checks, known limitations and unresolved faults
Resolve legal or data questionsRelevant legal, regulatory or data-protection specialistsApplicability assessment and the advice supporting the decision
Accept remaining operational riskA decision-maker with authority over the affected activityResidual risk, rationale, restrictions and review triggers
Restrict or stop a systemAn operational owner with access and authority to interveneTrigger, action taken, communication and safe continuation arrangements

An organisation may combine responsibilities where that remains workable. Consider independent review when the consequences or conflicts of interest justify it. NIST’s Measure function includes input from internal experts outside front-line development or independent assessors. NIST AI RMF 1.0, Measure 1.3

For legally covered high-risk systems, distinguish organisational oversight from the operational human oversight required by the AI Act. Article 14 concerns the system’s design and capabilities; Article 26(2) concerns the deployer’s assignment of competent, trained and authorised people with adequate support. A committee’s approval does not demonstrate either requirement on its own. AI Act, Articles 14 and 26

Write policies people can use during work

Policies should answer the decisions users encounter. Useful topics include:

  • Permitted uses and tools: what has been assessed, which uses are restricted, and how someone requests a new use.
  • Data handling: which information may enter a tool, where it may go, who can access it and what reuse is allowed.
  • Reliance on outputs: when checking is needed, what the reviewer should examine and which decisions require additional assessment.
  • Purchases and changes: evidence needed from a supplier and changes that require a new review.
  • Problems and feedback: how staff and affected people report concerns, who responds and how urgent cases are handled.

These topics draw on NIST Govern 1, 3, 4, 5 and 6. The wording and implementation remain organisational choices, subject to applicable law. NIST AI RMF 1.0, Govern

For personal data, an internal policy needs to reflect the actual GDPR purpose, lawful basis and relevant safeguards. Health and other special-category data require the Article 9 analysis as well. A DPIA is required where Article 35’s conditions are met. Approval by an internal committee does not supply a lawful basis for processing. GDPR, Articles 5, 6, 9 and 35

Keep training tied to these policies and the systems people use. The amended AI Act Article 4 requires measures supporting relevant staff’s AI literacy; it expressly does not require a guarantee of a particular individual’s level. AI Act, Article 4

Keep evidence with the decision

For each system, a review record can bring together the intended purpose, current version, organisational role, owner, data use and legal analysis. Add the evaluation results, known limitations and decision conditions. This is a practical extension of NIST’s inventory, context and measurement outcomes. NIST AI RMF 1.0, Govern 1.6, Map 1–2 and Measure 2

Describe how the evidence relates to the proposed deployment. An evaluation should identify its test conditions, relevant performance measures and limits. Include risks that could not be measured and explain how the uncertainty affects the decision. NIST’s Measure function explicitly addresses appropriate metrics, documentation of unmeasured risks and performance in conditions similar to the intended setting. NIST AI RMF 1.0, Measure 1.1 and 2.1–2.5

A decision record might state that use is approved for a defined purpose and user group, subject to specified controls, while a broader proposed use requires further review. Record who made that decision and what would reopen it. This creates an operational boundary without pretending that a generic model card covers every legal requirement.

For high-risk AI within the relevant legal scope, review the actual documentation and quality-management duties against the Act. Articles 11, 16 and 17 have specific requirements; a useful internal record may cover only part of them. AI Act, Articles 11, 16 and 17

Include suppliers and changes in the review

Purchased AI introduces dependencies that a technical test alone may not resolve. Practical supplier questions include:

  • What is the supported intended use, and what limitations are documented?
  • What information is sent to the supplier, retained or used for other purposes?
  • What evidence supports performance in the intended setting?
  • How will material changes, incidents and discontinued features be communicated?
  • What happens if the service is unavailable or the organisation needs to stop using it?

Record unanswered questions and their effect on the use decision. NIST Govern 6 and Manage 3 address third-party risk, while Manage 4 includes monitoring, incident response, recovery and change management. NIST AI RMF 1.0

Under the AI Act, specified rebranding, substantial modifications or changes of intended purpose can create provider obligations. A contract with the original vendor is not a substitute for checking that role change. Conversely, do not classify every configuration change as substantial without examining the legal test. AI Act, Articles 3(23) and 25

Monitor results and practise stopping safely

A monitoring plan should identify what is observed, who reviews it and what action follows. Select measures for the actual use: output errors, service availability, incidents, complaints, human interventions or changes in affected outcomes may be relevant. NIST’s Manage function covers response, recovery, monitoring and deactivation. NIST AI RMF 1.0, Manage 2.4 and 4

Set review frequency according to the risks, rate of change and available evidence. Add event-triggered reviews for a new purpose, significant model or data changes, a serious incident or newly identified limitations. A fixed quarterly meeting cannot address an urgent failure as it occurs.

Test the fallback process with the people who would use it. Check whether the system can be disabled, whether staff know how to continue the activity, and whether records needed to investigate an incident remain available. Keep legal reporting requirements separate from internal response targets so a convenient internal deadline does not obscure an applicable statutory duty.

Review the governance process itself

The process needs evidence of its own effectiveness. Suggested measures include:

MeasureWhat to examine
Register coverageKnown in-scope systems missing an owner, purpose, current version or decision record
Review completionUnresolved conditions and overdue actions, with their consequences
Decision timeWhere reviews wait and whether the delay reflects missing evidence or an unclear responsibility
Incidents and feedbackRecurring problems, whether concerns reach an owner, and whether corrective actions work
Change controlMaterial changes discovered after use rather than considered in advance

These measures are suggestions, without universal targets. Review their usefulness as the organisation learns. NIST Govern 1.5 calls for planned monitoring and review of the risk-management process with clear responsibilities. NIST AI RMF 1.0, Govern 1.5

Begin with a defined set of systems, identify evidence gaps and assign the work needed to resolve them. Resource estimates should follow the actual review, technical remediation and specialist work required. A revenue band or number of AI tools alone cannot establish a defensible budget or implementation duration.

Frequently Asked Questions

What should an AI governance framework contain?

A practical framework needs decision rights, policies, system records, risk assessment, evidence review and arrangements for monitoring and responding to problems. Adapt the work to the organisation’s uses and obligations. NIST’s Govern function offers reference outcomes for organising it. NIST AI RMF 1.0, section 5.1

Are NIST’s four functions a sequence of implementation stages?

No. Govern, Map, Measure and Manage are connected functions. NIST describes governance as supporting the others throughout the lifecycle and says the actions are not an ordered checklist. The work can be revisited as context and evidence change. NIST AI RMF 1.0, section 5

Does ISO 42001 certification establish EU AI Act compliance?

It does not, by itself, demonstrate that each applicable AI Act obligation has been met. ISO’s public description concerns an organisational AI management system. The Act has separate scope, actor and conformity requirements; Article 40’s presumption concerns requirements covered by harmonised standards whose references are published in the Official Journal. ISO 42001 summary; AI Act, Articles 6, 16, 26, 40 and 43

Does every organisation need an AI ethics board or centre of excellence?

The voluntary NIST framework supports clear accountability, suitable expertise and review adapted to context. A separate board or centre is one organisational option. Determine how the necessary decisions and responsibilities will work, and check any applicable sector-specific governance rules. NIST AI RMF 1.0, Govern 2 and Measure 1.3

Can a small organisation use this approach?

Yes. NIST permits selecting outcomes according to organisational resources and capabilities. Start by documenting the uses, responsible people, relevant rules and evidence needed for decisions. Scale review work to the consequences of the use, while meeting applicable legal duties. NIST AI RMF 1.0, section 5

Do we still need governance when all our AI comes from suppliers?

Supplier systems still create operational and data dependencies, which NIST addresses in Govern 6 and Manage 3. The EU AI Act also gives deployers their own duties where applicable; purchasing a system does not complete that analysis. NIST AI RMF 1.0; AI Act, Article 26

How should we estimate the cost and time needed?

List the systems in scope, existing controls, missing evidence and work needed before use. Include specialist review, technical changes and ongoing operation. Assign owners and dependencies, then estimate the work. This is a planning recommendation; the guide does not set a standard staffing level, fee or completion period.

Contact The Thinking Company.


Related reading


From strategy to systems in production

Book a briefing with a Transformation Lead — we confirm scope and recommend the right place to start.

Book a briefing