Is governance only for organizations that train models?

No; organizations buying or using AI also make consequential decisions.

Is it the same as model monitoring?

Monitoring supplies evidence, while governance determines responsibilities and responses.

Does following a voluntary framework establish legal compliance?

No. Applicable legal obligations require their own assessment.

AI Glossary / Governance, ethics and safety / Advanced

AI governance

Definition

AI governance is the system of decision rights, responsibilities, policies and oversight through which an organization directs its development, acquisition and use of AI. It connects stated principles to decisions and operating practices throughout a system's life. Effective governance requires people with authority and evidence they can act on; publishing a policy alone does not establish that the policy works.

What it means

An organization needs answers to practical questions: Which uses are acceptable? Who owns a system? What evidence supports its release? Who can stop it, and what happens when its behavior changes? Governance makes these questions part of ordinary decision-making rather than leaving them to informal assumptions.
This entry focuses on organizational governance. Public institutions also govern AI through broader policy and oversight arrangements. Within a business, governance includes technical, operational and human considerations. It should account for the people affected by AI decisions, not only the team that builds the model or pays the supplier.

How it works

An organization identifies its AI uses, assigns responsibilities and sets decision processes appropriate to their context. Reviews connect intended benefits with potential harms, evidence requirements and operating limits. Monitoring, change management, incident handling and eventual retirement carry those decisions into ongoing practice.
NIST's AI RMF 1.0 treats governance as a function running across mapping, measuring and managing risk, rather than a single preliminary checkpoint. The OECD accountability principle similarly emphasizes responsibilities, traceability and continuing risk management across the lifecycle.
Implementation should specify what happens when evidence is missing or conditions change. A review group that can only receive reports but cannot require action has a different role from an accountable decision-maker. Documentation should preserve that distinction instead of merely listing everyone as responsible.

Three practical examples

A company introduces an internal writing assistant. It defines permitted material, names a service owner, trains staff and establishes how inappropriate outputs or unintended disclosures are reported and investigated.
A manufacturer purchases an AI inspection service. Its review identifies who checks performance after supplier updates and who can switch to an alternative process when inspection quality deteriorates.
A learning website uses AI to draft explanations. It assigns editorial responsibility, records source checks and prevents a draft-completion count from being presented as evidence that every article is ready for publication.

Think of it this way

Think of the operating rules for a shared service: who may change it, what evidence they need, who deals with failures and how affected people can raise concerns. The written rules matter, but so does whether the people doing the work understand and follow them when a difficult decision arrives.

Worked example

Fictional Birch Services inventories 20 AI uses. Its internal policy requires every use to have a named owner and a documented purpose. Sixteen have both, so coverage of those two requirements is 16 / 20 = 80%.
Five uses are assigned enhanced review under the company's own criteria. Of those five, four have review evidence, but only three have both review evidence and an exercised fallback procedure. The second measure is therefore 3 / 5 = 60%, not 3 / 20 = 15%, because the stated requirement applies to that five-use subset.
The leadership report shows the counts and missing items rather than averaging 80% and 60% into a supposed 70% safety score. The measures refer to different requirements and populations, and neither directly measures all actual outcomes.
Suppose the remaining two enhanced-review uses receive fallback documentation. That still does not prove their fallback procedures have been exercised. The company retains the original evidence requirement and records the distinction. This invented example illustrates governance tracking; the categories and percentages are not a NIST scoring scheme or a legal compliance test.

Illustrative case study

Fictional Maple Support approves an AI assistant for drafting replies that staff review before sending. Several months later, a team enables automatic sending for a subset of requests to reduce waiting time. The original approval never assessed that operating mode.
An incident review discovers that the organization tracked model versions but not changes in who could act on outputs. It updates the service record to describe the actual workflow and assigns authority for decisions that expand the assistant's actions.
The team also tests whether staff can recognize and recover from an incorrect reply. It reports the incident, the changed operating boundary and the evidence needed for further use. The lesson is that governance must follow how a system is used, including workflow changes that leave the underlying model unchanged.

Common misconceptions and mistakes

Equating governance with a committee: a committee needs a defined mandate, information and authority to be useful.
Treating approval as permanent: changes in use, data or suppliers can invalidate earlier assumptions.
Assuming procurement transfers all responsibility: the deploying organization still makes decisions about its own use and oversight.
Counting documents as proof of effective controls: implementation and outcomes require evidence.
Using one procedure for every AI use without considering context: review effort should match the relevant consequences and requirements.

Business use

Start with a clear inventory and ownership, then connect policies to real decisions. Define what evidence is needed to proceed, what must be monitored and which changes require renewed review. Test whether escalation routes function when something goes wrong. Governance can support useful deployment by making responsibilities and conditions explicit, while preserving the ability to revise or stop a use when the evidence changes.

Check your understanding

Why is the worked example's fallback measure 60%?

Answer: Three of the five uses subject to that requirement have the specified evidence.

Why does automatic sending matter in the case study?

Answer: It changes the system's operating role and consequences.

What makes a policy operational?

Answer: Defined responsibilities, authority, procedures and evidence that they are implemented.

Related terms

Learn next

Choose one hypothetical AI use and identify its owner, release decision, evidence requirements, monitoring signals and stopping authority. Then describe a workflow change that would require the original decision to be revisited.

Sources

DXC Technology, AI governance glossary, organizational roles and oversight terminology. https://dxc.com/insights/ai-vision/glossary-of-ai-terminology-for-business/ai-governance NIST AI RMF 1.0, AI RMF Core and Govern function; the resource notes that revision is in progress. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ OECD AI Principles, accountability, traceability and lifecycle risk management. https://oecd.ai/en/dashboards/ai-principles/P9 The Birch Services measures and Maple Support case are original teaching illustrations.

Previous: AI-complete Next: AI infrastructure