Ziqqur logoZiqqur
Guide

What Is AI Governance? Frameworks, Roles, Controls, and Implementation

AI governance is the operating system for deciding which AI systems may be built or used, who is accountable, what evidence is required, which controls apply, how changes are reviewed, and when deployment must be limited, escalated, paused, rolled back, or retired. Strong governance turns principles into roles, lifecycle gates, evidence requirements, decision records, and stop authority.

Written by Ziqqur

Foundations

What Is AI Governance?

AI governance is the set of roles, policies, decision rights, lifecycle processes, controls, evidence requirements, and review mechanisms an organization uses to direct and oversee AI.

Strong governance should answer:

  • what is being governed;
  • who owns the system;
  • who may approve deployment;
  • which evidence is required;
  • which controls apply;
  • who may accept residual risk;
  • what changes trigger a new review;
  • who may pause or retire the system;
  • how each decision will be reconstructed later.

Governance does not eliminate uncertainty. It makes authority, evidence, exceptions, and unresolved risk visible and reviewable.

What Does AI Governance Mean in Practice?

In practice, AI governance defines:

  • which AI systems and use cases are in scope;
  • who owns each system and decision;
  • how risk is classified;
  • what evidence is required before deployment;
  • which controls must operate;
  • who may accept residual risk;
  • what changes trigger renewed review;
  • how incidents, exceptions, pause, rollback, and retirement are handled.

Governance is not one policy, committee, dashboard, or software platform. It is the connected operating model that makes AI decisions reviewable and accountable.

At a glance
Governance questionWhat a strong program should define
What is governed?Models, data, prompts, retrieval, tools, agents, vendors, workflows, and downstream decisions
Who owns the system?Named business, technical, data, risk, and control owners
What evidence is required?Intended use, data sources, evaluations, limitations, controls, monitoring, and approvals
Who may approve deployment?An authorized role matched to the risk tier
Who may accept residual risk?A named risk owner with delegated authority
What triggers renewed review?Material changes to models, data, prompts, tools, permissions, vendors, use cases, or decision authority
What happens after deployment?Monitoring, incident response, exception handling, review, rollback, and retirement
How is governance proven?Through decision records, evidence, approvals, exceptions, and change history

The key test is not whether an organization has an AI policy.

It is whether the organization can show:

Who made the decision, what evidence they reviewed, which risk remained, and what would cause that decision to be reconsidered.

Scope

Enterprise AI Governance vs. Public AI Governance

The phrase “AI governance” is commonly used in two different ways.

Public AI governance

Public governance concerns:

  • laws;
  • regulations;
  • public institutions;
  • international coordination;
  • human rights;
  • democratic accountability;
  • social legitimacy.

Enterprise AI governance

Enterprise governance concerns how an organization manages its own:

  • AI systems;
  • vendors;
  • data;
  • models;
  • prompts;
  • agents;
  • tools;
  • workflows;
  • decisions.

This article focuses on the enterprise operating model.

Public rules and social expectations still shape that model, but they are not the same thing.

Distinctions

AI Governance vs. Compliance and Risk Management

These disciplines overlap, but they answer different operational questions.

Governance

Governance asks:

  • who owns the AI system;
  • who may approve it;
  • which process must occur;
  • who may accept risk;
  • who may stop the system.

Compliance

Compliance asks:

  • which obligations apply;
  • whether those obligations are satisfied;
  • what evidence supports the conclusion.

For the software category, see What Is AI Compliance Software?

Risk management

Risk management asks:

  • what could go wrong;
  • how likely and severe the harm may be;
  • which controls reduce the risk;
  • what residual risk remains.

Ethics

Ethics asks:

  • which values should guide the use of AI;
  • which outcomes are acceptable;
  • whose interests and rights matter.

Audit

Audit asks:

  • whether the evidence, controls, and decisions can be independently examined.

Governance organizes these activities and assigns authority.

It should not be used as a vague synonym for all of them.

Framework

What an AI Governance Framework Should Cover

AI governance is broader than model governance.

The governed system may include:

  • model;
  • training and evaluation data;
  • prompts and system instructions;
  • retrieval sources;
  • vector or graph indexes;
  • external tools;
  • AI agents;
  • permissions;
  • vendors;
  • human reviewers;
  • downstream applications;
  • final decisions.

NIST AI RMF 1.0 takes a voluntary, lifecycle-oriented approach through the GOVERN, MAP, MEASURE, and MANAGE functions.1 Using the framework does not itself establish compliance with law or policy.

The useful implication is that governance should evaluate the whole system and context—not only model accuracy.

LayerDiagnostic question
Purpose and scopeWhat is governed?
Roles and authorityWho may decide?
Risk and lifecycle gatesWhat evidence is required?
Technical and organizational controlsWhat must the system and organization do?
Monitoring, incidents, and changeWhat triggers review or intervention?
Evidence and auditabilityCan the decision be reconstructed?

AI governance becomes operational when scope, authority, lifecycle decisions, controls, monitoring, and evidence are connected.

Operating Chain

From AI Principles to Policies, Controls, and Evidence

Governance often begins with principles such as:

  • fairness;
  • transparency;
  • accountability;
  • privacy;
  • safety;
  • human oversight.

The OECD AI Principles include human rights and democratic values, transparency and explainability, robustness, security and safety, and accountability.2 The principles were updated in 2024, so any date-sensitive summary should be checked against the current OECD source before publication.

Principles matter, but they are not controls.

A useful operating chain is:

principle → policy → standard → procedure → control → evidence → decision

For example:

  • Principle: Human oversight
  • Policy: High-consequence decisions require authorized review
  • Standard: Reviewers must see source evidence, system limitations, and unresolved conflicts
  • Procedure: Route defined cases into review
  • Control: Prevent final action until approval
  • Evidence: Reviewer identity, evidence viewed, decision, timestamp
  • Decision: Approved, rejected, escalated, or exception granted

The chain is Ziqqur’s synthesis, not a formal template mandated by OECD or NIST. Its purpose is to stop governance from ending at abstract values.

1Principle

Human oversight

2Policy

High-consequence decisions require authorized review

3Standard

Reviewer must see source evidence, limitations, and unresolved conflicts

4Procedure

Route defined cases into review

5Control

Prevent final action until approval

6Evidence

Reviewer identity, evidence viewed, decision, timestamp

7Decision

Approve, reject, escalate, or grant exception

Governance principles become operational only when they are translated into policies, controls, evidence, and decisions.

Roles

AI Governance Roles and Decision Rights

Governance is incomplete when responsibility is distributed but authority is undefined.

ISO/IEC 42001:2023 addresses the establishment, implementation, maintenance, and continual improvement of an organizational AI management system.3 Software may support that system, but purchasing software does not itself establish conformity or certification.

Board or executive leadership

Potential responsibilities:

  • approve AI risk appetite;
  • assign executive accountability;
  • review material risk;
  • approve restricted or prohibited uses.

AI governance committee

Potential responsibilities:

  • define policy;
  • resolve cross-functional issues;
  • review high-risk or exceptional cases;
  • oversee the governance program.

The committee should not become the default owner of every operational decision.

System owner

The system owner should:

  • define intended use;
  • maintain the inventory record;
  • coordinate evidence;
  • operate controls;
  • initiate change reviews;
  • own remediation.

Risk owner

The risk owner may:

  • assess residual risk;
  • accept risk within delegated authority;
  • require additional controls;
  • escalate decisions beyond their authority.

Data, model, security, privacy, legal, and compliance owners

These roles review domain-specific evidence and controls.

Independent audit or assurance

Audit should be able to challenge:

  • the governance process;
  • evidence quality;
  • control operation;
  • decision records;
  • exceptions;
  • risk acceptance.

None of that is possible unless approvals, exceptions, and lifecycle gates are recorded as reconstructable evidence rather than a status label. For what that record should contain, see What Is AI Auditability?

Stop authority

Governance should name who may:

  • pause deployment;
  • reduce autonomy;
  • revoke access;
  • rollback a change;
  • retire the system.

Artifact

The AI Governance Decision Record

For each material lifecycle decision, preserve:

  1. system or use case;
  2. owner;
  3. decision requested;
  4. risk tier;
  5. required evidence;
  6. controls;
  7. reviewer or approver;
  8. residual risk;
  9. exception;
  10. decision;
  11. expiry;
  12. material-change trigger.

Examples of material decisions include:

  • approve the use case;
  • authorize data access;
  • approve deployment;
  • accept residual risk;
  • grant an exception;
  • expand agent permissions;
  • approve a material change;
  • resume after an incident;
  • retire the system.

Governance should be judged by the decisions it can support, challenge, and reconstruct.

This is where Ziqqur’s approach is distinct: governance evidence should remain connected to the system, owner, controls, source history, reviewer, unresolved exception, and material-change trigger rather than collapsing into a score or status label.

#Decision-record field
1System or use case
2Owner
3Decision requested
4Risk tier
5Required evidence
6Controls
7Reviewer or approver
8Residual risk
9Exception
10Decision
11Expiry
12Material-change trigger

Three valid decision outcomes:

  • approved with conditions;
  • rejected or escalated;
  • exception granted with expiry.

A governance decision should preserve the evidence, authority, remaining risk, conditions, and trigger for renewed review.

Inventory

What Should Be in an AI Inventory?

An AI inventory should do more than confirm that a system exists.

A useful record may include:

  • business purpose;
  • owner;
  • users;
  • affected persons or systems;
  • risk tier;
  • models;
  • data sources;
  • prompts;
  • retrieval sources;
  • tools;
  • agents;
  • vendors;
  • permissions;
  • deployment environment;
  • downstream decisions;
  • controls;
  • evidence;
  • review status;
  • incidents;
  • material-change history;
  • retirement state.

Relationships matter

The inventory should also show connections.

Examples:

  • one model supports several applications;
  • one data source feeds several systems;
  • one agent can call several tools;
  • one vendor change affects several workflows;
  • one control supports several obligations;
  • one incident invalidates several prior approvals.

A flat spreadsheet may record the objects, but it may not show the dependencies that matter during change or incident response.

AI Use Case

Business owner

Risk owner

Model

Data sources

Prompts

Retrieval sources

Tools

Agents

Vendor

Permissions

Controls

Evidence

Downstream decisions

An AI inventory should connect each use case to its owners, dependencies, controls, evidence, and downstream decisions — one vendor or model change can propagate across several applications, workflows, and prior approvals.

Risk

How to Risk-Tier AI Systems

Governance intensity should match the risk and authority of the use case.

Useful factors include:

  • consequence of error;
  • affected individuals or systems;
  • safety impact;
  • data sensitivity;
  • autonomy;
  • reversibility;
  • external use;
  • regulatory scope;
  • decision authority;
  • scale;
  • vendor dependency.

NIST AI RMF supports context-sensitive risk management, while the EU AI Act applies differentiated obligations according to system category, role, and use context.4

The organization’s internal tiers should not be presented as equivalent to the EU AI Act’s legal categories. Legal applicability depends on the system, organizational role, use context, jurisdiction, and effective date.

For a cross-industry deployment framework, see AI for Regulated Industries

Example governance tiers

Tier 1 — Low-consequence assistance

Examples:

  • internal drafting;
  • search;
  • summarization.

Possible requirements:

  • owner;
  • approved data;
  • user disclosure;
  • periodic review.

Tier 2 — Controlled operational use

Examples:

  • extraction;
  • classification;
  • decision support;
  • workflow triage.

Possible requirements:

  • evaluation;
  • source controls;
  • human review;
  • monitoring;
  • incident process.

Tier 3 — High-consequence use

Examples:

  • customer-impacting recommendations;
  • safety or quality support;
  • regulated reporting;
  • autonomous actions.

Possible requirements:

  • enhanced testing;
  • independent review;
  • exact controls;
  • senior risk acceptance;
  • strong monitoring;
  • rollback;
  • restricted authority.

The exact tier model should reflect the organization, sector, and consequence of error.

Lifecycle

AI Governance Across the Lifecycle

A lifecycle gate should identify the decision requested, the evidence required, the authorized approver, the outcome, and the conditions attached to approval.

1. Use-case intake

Evidence may include: intended use, owner, users, affected stakeholders, decision authority, expected benefit.

2. Initial risk classification

Evidence may include: consequence, data sensitivity, autonomy, reversibility, legal or sector scope.

3. Data and architecture review

Evidence may include: data sources, access permissions, model, prompts, retrieval, tools, vendors, security boundaries.

4. Design approval

Evidence may include: control design, human oversight, failure modes, abstention, fallback, monitoring plan.

5. Testing and evaluation

Evidence may include: evaluation results, limitations, security testing, privacy review, robustness, user testing, adverse-case testing.

6. Deployment approval

Evidence may include: accepted risk tier, required controls, residual risk, monitoring owner, review date, rollback plan.

7. Monitoring review

Evidence may include: performance, incidents, overrides, drift, stale evidence, control failures.

8. Material-change review

Evidence may include: changed component, impact analysis, regression testing, reapproval scope.

9. Incident response

Evidence may include: event, affected systems, containment, root cause, remediation, decision to resume.

10. Retirement

Evidence may include: reason, replacement, open incidents, data disposition, archived governance record.

1Use-case intake

What is the intended use?

OwnerUsersDecision authorityExpected benefit
2Risk classification

How severe is the consequence?

ConsequenceData sensitivityReversibility
3Data & architecture review

What powers the system?

Data sourcesPermissionsModelTools
4Design approval

What controls are designed in?

Human oversightFailure modesAbstention
5Testing & evaluation

Was it evaluated?

Evaluation resultsLimitationsSecurity testing
6Deployment approval

Is residual risk accepted?

Risk tierControlsRollback plan
7Monitoring review

Is it behaving as expected?

PerformanceDriftControl failures
8Material-change review

What changed?

Changed componentImpact analysisReapproval scope
9Incident response

What happened, and what's next?

ContainmentRoot causeDecision to resume
10Retirement

Why is it ending?

ReasonReplacementData disposition
Every gate requires Decision · Evidence · Approver · Outcome · Conditions
A governance gate should require evidence and authority, not only a status label — and should loop back from monitoring to testing, from material change to design review, and from incident response to pause, rollback, or reapproval.

Evidence

Evidence Required at Each Governance Gate

Approval labels are not enough on their own.

A strong governance system should preserve:

  • evidence reviewed;
  • evidence version;
  • reviewer;
  • decision;
  • rationale;
  • residual risk;
  • exception;
  • attached conditions;
  • expiry;
  • next review;
  • material-change trigger.

This is where governance depends on provenance. For the broader concept of evidence lineage and transformation history, see What Is AI Provenance?

Evidence should remain challengeable

A reviewer should be able to see:

  • missing evidence;
  • conflicting evidence;
  • stale evidence;
  • limitations;
  • rejected alternatives;
  • unresolved risk.

The governance system should not force every issue into a green status.

Generative AI

Generative AI Governance

Generative AI governance should cover the application and workflow around the model, not only the foundation model itself.

NIST’s Generative AI Profile highlights risks including confabulation, information integrity, privacy, cybersecurity, human-AI configuration, third-party risk, content provenance, monitoring, and incident disclosure.5 It is voluntary risk-management guidance, not a guarantee that a deployment is safe, responsible, or compliant.

Governance may need to cover:

  • prompt design;
  • system instructions;
  • retrieval sources;
  • grounding;
  • output review;
  • source quality;
  • content provenance;
  • tool use;
  • vendor model changes;
  • data leakage;
  • monitoring;
  • abstention.

Hallucination controls as governance requirements

Governance should define:

  • which outputs require source support;
  • which claims require verification;
  • which tools may be called;
  • which cases require review;
  • when the system must abstain.

For the control architecture, see How to Reduce AI Hallucinations

Exact controls should remain inspectable

Where a condition can be checked exactly, use:

  • rules;
  • validators;
  • queries;
  • policy engines;
  • workflow state.

For the broader distinction, see What Is Deterministic AI?

Agents

AI Agent Governance

Agent governance should define delegated authority.

A strong governance record should preserve:

  • agent identity;
  • owner;
  • delegated purpose;
  • permitted data;
  • permitted tools;
  • permitted actions;
  • approval threshold;
  • transaction logs;
  • revocation mechanism;
  • exception process;
  • incident owner.

NIST’s 2026 initial public draft concept paper on software and AI-agent identity emphasizes identification, authentication, authorization, auditing, non-repudiation, visibility into agent actions, data-flow tracking, and provenance for prompts and inputs.6

Because it is an initial public draft, it should be treated as emerging official guidance rather than a final standard.

Agent authority should be revocable

Governance should define how to:

  • narrow scope;
  • disable tools;
  • revoke credentials;
  • pause the agent;
  • require approval;
  • roll back an action;
  • investigate misuse.
1Human or system owner

Delegates a bounded purpose

2Delegated purpose

Defines what the agent is authorized to do

3Agent identityBlocked: expired delegation

Distinct from the owner's own account

4Permitted dataBlocked: scope reduced
5Permitted toolsBlocked: tool disabled
6Permitted actionsBlocked: credential revoked
7Transaction log

Full action history preserved for investigation

Agent governance should define what the agent may access and do, on whose authority, and how that authority can be narrowed, disabled, revoked, paused, or investigated.

Vendors

Third-Party AI Governance

Outsourcing the model does not outsource accountability for the organization’s use of it.

Third-party governance may require:

  • vendor due diligence;
  • documented intended use;
  • data-use restrictions;
  • model and service versioning;
  • change notification;
  • evaluation rights;
  • incident notification;
  • security review;
  • audit and export rights;
  • exit plan;
  • fallback or rollback;
  • subprocessor visibility;
  • dependency mapping.

The governance program should also define:

  • who approves the vendor;
  • who monitors changes;
  • what happens when terms or models change;
  • what evidence must be retained if the vendor relationship ends.

Change Management

What Counts as a Material AI Change?

Prior approval should not be treated as permanent or unlimited.

Governance should define which changes require renewed review.

Potential triggers include:

  • model or provider version;
  • prompt or system instruction;
  • retrieval corpus;
  • data source;
  • tool;
  • permission;
  • action scope;
  • deployment environment;
  • intended use;
  • user population;
  • decision authority;
  • monitoring threshold;
  • downstream integration;
  • legal or sector scope.

Not every change requires full reapproval.

The process should use risk-sensitive thresholds.

The important point is that the trigger should be defined before the change occurs.

Review

Human Review, Exceptions, and Residual Risk

Human review

“Human in the loop” is not a governance control unless the organization defines:

  • review trigger;
  • authorized reviewer;
  • evidence shown;
  • allowed decisions;
  • override conditions;
  • escalation;
  • record;
  • expiry;
  • competency requirements.

Human review does not guarantee correctness.

Exceptions

An exception record should preserve:

  • affected policy or control;
  • reason;
  • owner;
  • approver;
  • compensating control;
  • residual risk;
  • start date;
  • expiry date;
  • remediation plan;
  • closure evidence.

An approved exception is not the same as a passed control.

Residual-risk acceptance

Residual risk should not disappear into a score.

A decision record should preserve:

  • remaining risk;
  • affected stakeholders;
  • control limitations;
  • accepting authority;
  • rationale;
  • scope;
  • expiry;
  • monitoring;
  • escalation threshold.

The authority to accept residual risk should be explicit.

Operations

Monitoring, Incidents, Pause, Rollback, and Retirement

Monitoring should cover more than model performance.

It may need to include:

  • data and source changes;
  • prompt changes;
  • retrieval changes;
  • tool changes;
  • agent permissions;
  • incidents;
  • user behavior;
  • control failures;
  • reviewer overrides;
  • residual risk;
  • exceptions;
  • downstream outcomes;
  • vendor changes.

Monitoring does not prove safety or compliance. It makes changes and failures visible.

Incident response

Governance should define:

  • reporting channel;
  • severity;
  • owner;
  • containment;
  • investigation;
  • evidence preservation;
  • remediation;
  • decision to resume;
  • external notification where required.

Pause authority

Pause may be appropriate after:

  • material control failure;
  • evidence loss;
  • authorization failure;
  • severe drift;
  • unsafe behavior;
  • unresolved incident;
  • vendor change;
  • new legal restriction.

Rollback authority

Rollback may be appropriate after:

  • harmful model or prompt update;
  • failed deployment;
  • degraded performance;
  • tool or permission change.

Retirement authority

Retirement may be appropriate when:

  • the use case is no longer valid;
  • control requirements cannot be met;
  • vendor support ends;
  • risk exceeds appetite;
  • monitoring is no longer maintainable;
  • a replacement is deployed.

Incident, Material Change, Control Failure, or Evidence Loss

Continue with conditions

Pause

Rollback

Restrict authority

Remediate and reapprove

Retire

Governance should define who may pause, rollback, restrict, or retire an AI system and which evidence triggers that decision.

Tooling

What AI Governance Software Should Support

Governance software can support:

  • system inventory;
  • ownership;
  • dependency mapping;
  • risk tiering;
  • lifecycle workflows;
  • evidence requirements;
  • approvals;
  • exceptions;
  • residual-risk acceptance;
  • material-change triggers;
  • incidents;
  • agent permissions;
  • audit export;
  • pause and retirement records.

It should not be confused with the governance operating model itself.

The organization must still define:

  • legitimate authority;
  • policy;
  • risk appetite;
  • evidence standards;
  • review requirements;
  • stop conditions.

A platform can coordinate and preserve governance decisions.

It cannot decide who should legitimately have authority unless the organization defines that authority first.

Implementation

How to Build an AI Governance Framework

1. Define scope

Decide which systems are included: internal models, third-party AI, embedded vendor AI, agents, experimental tools, shadow AI, low-code automation.

2. Assign ownership and authority

Name: system owner, risk owner, data owner, approver, reviewer, stop authority, audit role.

3. Build the inventory

Record the system, purpose, dependencies, decisions, controls, evidence, and status.

4. Create risk tiers

Match governance intensity to consequence, autonomy, evidence burden, and reversibility.

5. Define lifecycle gates

Specify: decision, evidence, approver, outcome, conditions, expiry.

6. Create governance decision records

Preserve the basis and authority for every material decision.

7. Define change and incident triggers

State what requires: renewed review, escalation, pause, rollback, retirement.

8. Monitor governance effectiveness

Measure: overdue reviews, stale evidence, unresolved exceptions, incidents, unauthorized systems, control failures, repeated overrides, unowned risk.

9. Improve the operating model

Use incidents, audits, and changes to improve: policy, controls, evidence requirements, role clarity, review thresholds.

1Define scope

All relevant internal and third-party AI is included

2Assign ownership and authority

Every material decision has an authorized role

3Build the inventory

Dependencies and decisions are visible

4Create risk tiers

Controls scale with consequence

5Define lifecycle gates

Evidence and approvers are defined

6Create governance decision records

Basis and residual risk are preserved

7Define change and incident triggers

Material changes and incidents route correctly

8Monitor governance effectiveness

Stale evidence and unresolved exceptions are visible

9Improve the operating model

Incidents and audits update policy and controls

Build governance as an operating system, not as a one-time policy project.

Frequently asked questions

What is AI governance in simple terms?

AI governance is how an organization decides which AI systems may be used, who is responsible, what controls and evidence are required, and when a system must be reviewed, restricted, or stopped.

Is AI governance the same as AI compliance?

No.

Governance defines the operating model and decision rights.

Compliance evaluates whether specific obligations are satisfied and evidenced.

Is AI governance the same as model governance?

No.

Model governance focuses on models.

AI governance may also cover data, prompts, retrieval, tools, agents, vendors, human reviewers, and downstream decisions.

Who is responsible for AI governance?

Responsibility is usually shared across executive leadership, system owners, risk owners, legal, compliance, security, privacy, data, model, and audit functions.

Authority should still be explicit for each decision.

Do we need an AI governance committee?

A committee can coordinate policy and high-risk decisions.

It should not replace clear ownership and delegated authority for operational decisions.

What should be in an AI inventory?

At minimum: purpose, owner, risk tier, models, data, vendors, permissions, controls, evidence, decisions, incidents, status.

What is a material change?

A material change is a change significant enough to affect prior risk, evidence, controls, or approval.

Examples may include a new model, prompt, data source, tool, permission, use case, or deployment environment.

What is residual-risk acceptance?

It is the explicit decision by an authorized person to accept the risk that remains after controls are applied.

The scope, rationale, conditions, and expiry should be recorded.

How should AI agents be governed?

Agents should have identifiable owners, bounded purpose, scoped permissions, permitted tools and actions, transaction logs, approval thresholds, and revocation mechanisms.

Can governance software ensure responsible AI?

No.

Software can coordinate inventories, evidence, approvals, exceptions, and monitoring.

The organization must still define authority, policy, risk appetite, and control standards.

When should an AI system be paused or retired?

It may need to be paused or retired after serious incidents, control failures, evidence loss, authorization failures, unsupported changes, unacceptable residual risk, or loss of monitoring and vendor support.

Closing

Conclusion

AI governance is not a committee, a dashboard, or a list of principles.

It is the operating system for making and recording decisions about AI.

A mature program should be able to show:

  • what is governed;
  • who owns the system;
  • which evidence was required;
  • who approved deployment;
  • which risk remained;
  • what exception applied;
  • what change triggers renewed review;
  • who may pause or retire the system.

The goal is not to eliminate uncertainty. It is to make authority, evidence, exceptions, and unresolved risk visible, bounded, and reviewable.

That is the difference between having AI policies and operating an AI governance system.

References
  1. 1.

    National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf

  2. 2.

    OECD.AI. OECD AI Principles. updated 2024. https://oecd.ai/en/ai-principles

  3. 3.

    International Organization for Standardization. ISO/IEC 42001:2023 — Artificial intelligence management system. 2023. https://www.iso.org/standard/42001

  4. 4.

    European Union. Regulation (EU) 2024/1689, Artificial Intelligence Act. 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng

  5. 5.

    National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

  6. 6.

    National Institute of Standards and Technology, National Cybersecurity Center of Excellence. Accelerating the Adoption of Software and AI Agent Identity and Authorization (Initial Public Draft Concept Paper). February 2026. https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd

Related reading

What Is Trustworthy AI?

Why a confident interface isn't the same as evidence that reliance is justified.

Read the guide

About this article

This guide was produced using our research and sourcing methodology, including AI-assisted tools during research and drafting.

Read the full editorial policy, including corrections and update practices.