Make AI ownership, risk decisions, evidence, and oversight explicit. Governance should guide a system from its intended use through deployment, change, and retirement.

Content reviewed: October 25, 2026 · Practical guide
Governance starts with a use case
Document what the system is intended to do, who may rely on it, and what happens when it is wrong. The same model can create very different risks in a drafting assistant, a public chatbot, or a workflow that affects a person’s access to a service.
Assign an accountable owner and define who can approve deployment, accept risk, respond to incidents, and retire the system. A policy with no operating responsibilities is difficult to enforce.
Use the NIST functions as an organizing model
| Function | Questions for the delivery team |
|---|---|
| Govern | Who is responsible? Which policies and decision rights apply? |
| Map | What is the context, intended use, affected population, and potential impact? |
| Measure | Which evaluations and evidence reveal the relevant risks and limitations? |
| Manage | What treatment, monitoring, escalation, or discontinuation is appropriate? |
The functions are connected activities, not a one-time checklist or a certification. Use them to organize decisions and evidence at a level proportional to the application’s consequences.
A useful AI system record
- Purpose, owner, users, intended limits, and prohibited uses.
- Model and provider, material configuration, and connected tools.
- Data sources, permitted processing, retention, and access rules.
- Evaluation methods, known limitations, and release decisions.
- Human oversight, incident response, change review, and retirement triggers.
Worked example: a policy-review assistant
Illustrative design: an assistant highlights possible gaps in a draft policy and links each observation to a supplied control reference. A policy owner reviews the observations and makes the final decision. The system does not declare an organization compliant or approve a risk exception.
Before rollout, document which references are authoritative, what constitutes an unsupported finding, who reviews disputed output, and how reference updates are controlled. Preserve evidence of review without retaining unnecessary sensitive drafts.
Review vendors and changes as part of the system
A vendor review should examine the actual service configuration and intended data flow: retention, training use, deployment location, access controls, incident handling, subcontractors, and change notifications. Do not infer those commitments from a generic product label.
Revisit the risk decision when the model, tool permissions, data sources, users, or intended purpose changes. Routine technical updates can alter the system’s behavior even when the user interface looks the same.
Make oversight actionable
A human review step needs information, authority, and time. Show the evidence behind a proposed action, make disagreement possible, and provide an escalation route. Track whether review detects real problems rather than treating the presence of an approval button as proof of effective oversight.
Sources & further reading
Primary references reviewed for this guide. Worked examples and delivery checklists are illustrative design guidance.