What is AI governance?
Put ownership behind the system.

A model is a component. Governance follows the decisions around it.

AI governance is the way an organization assigns authority and responsibility for AI systems across their lifecycle. It connects purpose, procurement, data, model behavior, product design, deployment, monitoring, and incident response. It answers practical questions: What may this system do? Who approved that use? What must be tested? Who can pause it?

A principles document can set direction, but it cannot decide a release or handle an incident by itself. Principles become operational when teams translate them into named owners, review criteria, permissions, records, and escalation paths. The aim is not to remove judgment; it is to show who is making a judgment and on what basis.

Write down what is actually being used.

A useful inventory describes more than a model name. Record the product boundary and intended purpose; the model, data sources, vendors, integrations, and tools; the people who operate or rely on it; and the decisions its outputs can influence. Include the version and operating context, because a system can change when any of those parts change.

Then identify plausible benefits, failure modes, and affected groups. A drafting assistant, a hiring filter, and an agent with permission to alter records call for different controls. Start from the use and its consequences, rather than assigning the same review to every system labelled “AI.”

1. Purpose: what task is supported, and what uses are explicitly outside scope?
2. Boundary: which model, application, data, tools, vendors, and people make up the system?
3. Impact: who may benefit, rely on the result, bear an error, or need a way to challenge it?
4. Change: which inputs, versions, integrations, or operating conditions could alter its behavior?

NIST gives teams a useful map for managing risk.

The NIST AI Risk Management Framework organizes work into four functions. Govern establishes organizational policies, responsibilities, and risk practices across the lifecycle. Map describes the context, intended use, affected people, and risks. Measure selects and applies evaluations, then documents what they can and cannot show. Manage prioritizes risks and chooses how to respond, monitor, or limit use.

These functions inform one another; they are not a one-way checklist. A production incident may change the risk map. A measurement limit may require a narrower use. A vendor or model change may trigger a new review. NIST describes AI RMF 1.0 as voluntary and its Playbook as suggestions rather than a complete checklist. As of the date on this page, NIST says the framework is being revised.

For generative AI, NIST’s companion profile adds risk considerations and suggested actions for generative systems. It helps teams tailor their review; it does not replace the system’s purpose, local context, or applicable law.

“Human in the loop” means little without authority.

Several teams may take part in an AI system, but participation is not the same as accountability. Name the person or role that owns the use case and the decision to deploy it. Give technical, product, legal, privacy, security, and operational reviewers a clear scope. Set an escalation route for disagreements and define who can restrict or stop use.

When people review outputs, give them enough context, time, and power to act. A reviewer who cannot see the source, question the result, override a decision, or report recurring failures is only providing a ceremony of oversight. High-impact decisions may also need an explanation and a path for an affected person to request review; exact duties depend on the system and the law that applies.

Risk review is a lifecycle practice, not a launch form.

1. Select or acquire: document why AI is appropriate, review vendor claims and data terms, and identify what the organization cannot inspect.
2. Design and build: define permitted uses, data boundaries, access controls, evaluation cases, and requirements for human review.
3. Before deployment: test against realistic tasks and foreseeable misuse; record known limits, unresolved risks, approval, and conditions of use.
4. During operation: monitor signals related to the intended use, receive reports, investigate incidents, and keep review channels available.
5. After a change: assess whether a new model, prompt, dataset, tool, user group, or environment needs a fresh evaluation or approval.
6. When retiring: remove unneeded access, decide how records and data are retained, and tell affected users what changes.

The record should be proportionate to the risk. It can be a short review for a low-impact internal aid or a deeper, cross-functional assessment where people or essential services may be materially affected. The point is to preserve the rationale and evidence, not to create paperwork for its own sake.

Approval is a decision at a moment. Governance keeps checking the conditions.

Record the system version, intended use, reviewer, evidence, limits, and approval conditions. Keep evaluations tied to the version and context they tested. Monitor the failures that matter for the job: unsupported answers, uneven error patterns, unsafe tool actions, unexpected data access, or user reports. A dashboard is useful only when somebody owns the signal and knows what action follows it.

Make incident handling specific: where a person reports a problem, who triages it, how use can be contained, what evidence is preserved, and who decides when service resumes. Feed what the investigation finds back into training, prompts, tests, permissions, and operating instructions. Repeated problems need a system change, not just a reminder to “be careful.”

For practical evaluation methods, see how to test agent outcomes ↗, how to plan an AI red-team exercise ↗, and how to examine bias and impact ↗.

A voluntary framework and a legal obligation are different things.

The NIST AI RMF is guidance for organizations that choose to use it. A law can impose obligations on particular actors, uses, and dates. Following a voluntary framework does not establish legal compliance, and a policy cannot override binding requirements. Identify the applicable jurisdiction, system role, and intended use; then map the legal duties alongside the organization’s own risk controls.

For teams working in Europe, our EU AI Act guide ↗ explains how purpose, role, risk category, and application date affect the analysis. The governance process should give someone responsibility for checking authoritative legal guidance as it changes.

Imagine an assistant that searches internal policies.

This is a hypothetical example. The team first defines the assistant’s role: find relevant policy passages and summarize them, without deciding an employee’s eligibility or replacing HR advice. It inventories the model, search index, documents, access rules, and responsible team. It checks whether each person can retrieve only material they are allowed to read.

Before use, the team tests whether answers are supported by the retrieved text, whether missing evidence produces a clear handoff, and whether hostile instructions inside a document can redirect the system. A named owner reviews changes to the model, policies, and retrieval setup. During operation, employees can flag a wrong or exposed answer; the owner can investigate, remove affected material, and restrict the feature while the issue is resolved.

The governance comes from the boundaries, evidence, and response path—not from calling the assistant “responsible AI.”

Make the next AI decision answerable.

• Can we name every AI system and the purpose for which it is used?
• Who owns each system and has authority to approve, limit, or stop it?
• What evidence shows it works for the people and setting it is meant to serve?
• What can reviewers see, challenge, override, and escalate?
• Which events or changes require a new assessment?
• How can a person report an incident and learn what happened next?
• Which obligations come from law, and which come from our own policy?

Good governance turns intent into visible choices. Explore the AI field guide ↗ for the system concepts behind those choices, or continue to AI literacy at work ↗.