AI Governance

Last verified: 2026-05-26 — primary sources: NIST AI Risk Management Framework (Core functions and the GOVERN function) and ISO/IEC 42001:2023, retrieved 2026-05-26.

AI governance is the operating model an organization uses to decide who is accountable for AI systems, what rules those systems must follow, and how risk is reviewed before and after deployment. It is the organizational layer that sits above an AI compliance framework: the compliance framework maps systems to laws and controls, while governance assigns the decision rights, oversight bodies, and accountability that make the framework operate.

NIST treats this governance layer as foundational. NIST describes the GOVERN function of the AI Risk Management Framework as "a cross-cutting function that is infused throughout AI risk management and enables the other functions," and says it cultivates "a culture of risk management within organizations designing, developing, deploying, evaluating, or acquiring AI systems." Source: NIST AI RMF Core, retrieved 2026-05-26. The framework itself is "intended for voluntary use." Source: NIST AI Risk Management Framework, retrieved 2026-05-26.

Quick answer

An AI governance program assigns four things to every AI system: an owner, a set of rules, a review gate, and an evidence trail. The table below is a minimum operating model.

Governance layerDecision it ownsFramework anchorEvidence artifact
Board / executive sponsorRisk appetite, escalation thresholds, sign-off on highest-impact systemsNIST GOVERN (culture of risk management)Approved AI policy, risk-acceptance record
AI governance committeeCross-functional review of new and changed AI systemsNIST GOVERN; ISO/IEC 42001 leadership and rolesCommittee charter, decision log
System owner / product leadPurpose, data, users, and production status of a specific systemNIST MAP (context)System register entry
Risk / legal / privacyApplicable laws, prohibited uses, disclosure dutiesLegal overlayApplicability map with citations
Model / ML engineeringTesting, monitoring, performance and bias measurementNIST MEASURETest results, monitoring dashboard
Incident responseSuspension, recovery, notification when a system failsNIST MANAGEIncident runbook and log

AI governance vs AI compliance

The two terms are related but not identical, and conflating them is a common program weakness.

  • AI compliance asks whether a specific system meets binding and voluntary requirements. The output is an AI compliance framework: a control map of systems, laws, controls, and evidence.
  • AI governance asks who decides, who is accountable, and how decisions are reviewed. The output is an operating model: committees, decision rights, policies, lifecycle gates, and escalation paths.

A program can be "compliant" on paper and still ungoverned if no one owns the refresh cadence, no body reviews new systems, and no one can suspend a failing model. Governance is what keeps the compliance framework alive after the first audit.

The GOVERN function as the backbone

NIST organizes the AI RMF Core into four functions. GOVERN is the cross-cutting one; the other three run across the AI lifecycle:

  • GOVERN — "a cross-cutting function that is infused throughout AI risk management and enables the other functions," cultivating "a culture of risk management."
  • MAP — "establishes the context to frame risks related to an AI system."
  • MEASURE — "employs quantitative, qualitative, or mixed-method tools, techniques, and methodologies to analyze, assess, benchmark, and monitor AI risk and related impacts."
  • MANAGE — "entails allocating risk resources to mapped and measured risks on a regular basis," including plans "to respond to, recover from, and communicate about incidents or events."

Source: NIST AI RMF Core, retrieved 2026-05-26.

For a governance program, this means GOVERN decisions — policy, roles, and risk appetite — should exist before MAP, MEASURE, and MANAGE activities are assigned to individual systems. A committee that only reviews finished systems is reacting, not governing.

Roles and decision rights

The recurring failure mode in AI governance is unclear accountability. The matrix below assigns the core governance activities to roles using a responsible / accountable / consulted pattern. It is an operating-model template, not legal advice.

ActivityAccountableResponsibleConsulted
Approve enterprise AI policyExecutive sponsorAI governance committeeLegal, security, privacy
Maintain AI system inventoryGovernance committeeSystem ownersProcurement, IT
Classify system risk tierGovernance committeeSystem ownerLegal, risk
Determine legal applicabilityLegal / compliancePrivacy, system ownerExternal counsel
Run impact assessmentSystem ownerRisk / ML teamLegal, affected business unit
Approve production deploymentGovernance committeeSystem ownerSecurity, legal
Monitor live systemsSystem ownerML / opsRisk, support
Trigger suspension on incidentIncident leadSystem ownerLegal, communications

This division is what auditors and regulators look for: a named person accountable for each AI decision, not a diffuse "the team."

Governance gates across the AI lifecycle

Governance becomes operational through gates — points where a system cannot proceed without a recorded decision.

  1. Intake gate (MAP). Before build or purchase: record purpose, data classes, users, jurisdictions, and a first risk-tier estimate.
  2. Pre-deployment gate (MEASURE). Before production: impact assessment, bias and performance testing, disclosure copy, and legal sign-off for triggered laws.
  3. Monitoring loop (MANAGE). In production: drift and performance monitoring, periodic re-verification, and a defined suspension path.
  4. Change gate. On material change to model, data, vendor, purpose, or jurisdiction: re-run the relevant gate rather than grandfathering the original approval.

Policy stack

A governance program is usually documented as a small stack of policies rather than one document:

  • AI policy — scope, principles, prohibited uses, and the governance body's authority.
  • Acceptable-use standard — what staff may and may not do with internal and third-party AI tools.
  • Risk-tiering standard — how systems are classified and what each tier requires.
  • Vendor-AI standard — due diligence and contractual controls for third-party AI (pair with the vendor role guide).
  • Incident standard — triggers, roles, and notification paths for AI failures.

State-law overlay for governance

US state AI laws increasingly assign governance-style duties — risk-management programs, impact assessments, disclosures, and accountable roles. A governance program should map each system to the laws it triggers and let the linked law page hold the current effective date and duty detail:

  • Colorado AI Act (reenacted by SB 26-189) — risk-management and documentation duties for consequential AI decisions.
  • Texas TRAIGA (HB 149) — disclosure, prohibited-use, and enforcement provisions.
  • NYC Local Law 144 — independent bias audit and candidate notice for automated employment decision tools.
  • Illinois HB 3773 — employment-AI use and proxy-discrimination limits.
  • Utah AI Policy Act — disclosure duties for AI interactions and regulated occupations.
  • California SB 53 — frontier-model safety and transparency duties.

Map the deployer-versus-developer split with the role obligations guide; for the binding-versus-voluntary distinction, see federal vs state AI law.

ISO/IEC 42001 path to certifiable governance

When a board, customer, or regulator wants third-party-verifiable governance, ISO/IEC 42001 provides a management-system structure. ISO describes ISO/IEC 42001:2023 as an AI management system standard for organizations that develop, provide, or use AI systems. Source: ISO/IEC 42001:2023, retrieved 2026-05-26. Its management-system clauses — leadership, policy, roles, planning, and operation — align closely with the governance operating model above and support a certification pathway that a voluntary framework alone does not. See the ISO/IEC 42001 reference and compare with the NIST AI RMF.

90-day governance stand-up sequence

TimeframeWork productPurpose
Days 1-15AI policy + governance committee charterEstablish decision rights before systems are reviewed
Days 16-30AI system inventory and owner mapKnow the population of systems
Days 31-45Risk-tiering standard + intake gateTriage systems by impact
Days 46-60Evidence templates (impact assessment, bias audit, disclosure)Standardize what proves a control operates
Days 61-75Pilot the gates on three high-impact systemsTest the model on hiring, lending, and customer-support use cases
Days 76-90Board / committee review and refresh cadenceApprove risk acceptance and the review calendar

Frequently asked questions

What is AI governance?

AI governance is the operating model that assigns accountability, rules, review gates, and evidence to AI systems. NIST frames the governance layer as the GOVERN function — "a cross-cutting function that is infused throughout AI risk management and enables the other functions."

What is the difference between AI governance and AI compliance?

AI compliance asks whether a system meets requirements; AI governance asks who is accountable and how decisions are reviewed. Compliance produces a control map; governance produces the committees, decision rights, and lifecycle gates that keep the map current.

Is AI governance required by law?

No single US law mandates a named "AI governance program," and the NIST AI RMF is "intended for voluntary use." Several state AI laws do impose governance-style duties — risk management, impact assessments, and disclosures — on specific systems; see the state-law overlay above and each linked law page for current scope.

What is an AI governance framework?

An AI governance framework is the documented combination of an operating model (roles, committee, decision rights), a policy stack, lifecycle gates, and a refresh cadence. Many programs anchor it to the NIST AI RMF GOVERN function or to ISO/IEC 42001 management-system clauses.

Who owns AI governance in an organization?

Accountability usually sits with an executive sponsor and a cross-functional governance committee, with system owners responsible for individual systems. The accountability matrix above shows a common division of responsible, accountable, and consulted roles.

Cross-references