Governing AI: NIST's Govern and Manage

This is Unit Six of Leading AI at Work, on governing AI with two of NIST's functions, govern and manage. Unit Five closed on routines that ask the right question at the right time. This unit lines those routines up against NIST's AI Risk Management Framework. Carry one question through this lecture: how do a governance framework and a working method fit together? The answer arrives with one pre-filled field, governed end to end. By the end you will be able to explain why the method's documents are also evidence. To apply the govern subcategories Course One left aside. And to take a feature through the manage subcategories, from whether it should proceed to how it is switched off.

Five entries on a regulator's questions, and on what NIST's govern function asks of an organization.

Three questions from a regulator.

LAI 126 The Regulator's Three Questions

The M-CaReM-AI method, by J. R. Carver, imagines a regulator asking three questions about an AI-assisted eligibility tool. How is the decision defined? Where does it show up in code, data and automation? How was it validated with the people affected? One agency needs a month to answer; another answers in an afternoon from its Pack and matrix.

Why the afternoon matters.

LAI 127 Documents as Evidence

The book's lesson is that the method's documents are also its evidence. Defined things make hidden unfairness easier to see, validation brings the right voices in, and traceability shows which rules and systems carried a decision. As AI joins more decisions, the book says, where a decision lives becomes an obligation.

Govern, running through everything.

LAI 128 Govern Runs Throughout

Generative AI at Work introduced NIST's four functions: govern, map, measure and manage. This unit goes deeper into two. NIST describes govern as cross-cutting, running through the other three, with continual attention across a system's life. Governance is not a stage a project passes; it is a condition it keeps.

What govern is for.

LAI 129 What Govern Does

NIST's framework says govern builds a culture of risk management in organizations that design, deploy or acquire AI. It sets out processes, documents and structures, links technical design to organizational values, and covers the whole lifecycle, including third-party systems. Its subcategories are where it becomes practical.

Documentation and accountability.

LAI 130 Documentation and Accountability

NIST says documentation can improve transparency and human review and strengthen accountability. Senior leadership sets the tone; management aligns technical work with policy and operations. The method's Packs, cards and matrices are one way to supply that documentation for the decisions that matter most.

Eight entries on govern subcategories, each paired with one way the method can meet it.

Effort, matched to risk.

LAI 131 Effort Matched to Risk

NIST's Govern one point three asks that risk-management effort follow the organization's risk tolerance. The method's Bronze, Silver and Gold levels, taught in The M-CaReM-AI Method, lesson one hundred thirty-five, are one way to do it. Heavy process everywhere spends effort where risk is low.

An inventory of AI.

LAI 132 Keeping an Inventory of AI Use

NIST's Govern one point six asks for an inventory of AI systems, resourced by risk. The method offers one way to keep it. Check the AI row of each Gold thing's matrix, gather those rows into one list grouped by system, and add every feature that has passed the gate. Compare the two sources and chase any system that appears in only one. Review the list at object reviews. In this course's view, an inventory from purchasing records lists what was bought; one from the matrices lists where AI actually touches decisions.

Retiring a system.

LAI 133 Retiring an AI System Safely

NIST's Govern one point seven asks for safe processes to retire AI systems without raising risk or losing trust. Retiring a drafting tool can leave a Gold thing's process missing a review step the tool's output used to trigger. Retirement is a change, and belongs in the change walk.

Who owns the risk.

LAI 134 Leadership Owns the Risk Decisions

NIST's Govern two point three says executive leadership takes responsibility for AI risk decisions. The book makes a related point about its own limits: if teams are rewarded only for speed, they may skip validation, and only leadership can fix that. No method carries a decision leadership has not made.

Roles for people and AI.

LAI 135 Defined Roles for People and AI

NIST's Govern three point two asks for policies that define and differentiate roles for human-AI configurations and oversight. The book cites it, and the suggest-or-decide boundary from Unit Five is one way to meet it: each output is assigned to a person or the system. An undefined role defaults to whoever happens to click.

Many voices.

LAI 136 Many Voices in Decisions

NIST's Govern three point one says AI risk decisions should be informed by a team diverse in demographics, disciplines, experience, expertise and backgrounds. The book's validation sessions, frontline staff, policy experts and technologists around one thing, are one practical form. A review hearing one discipline serves one perspective.

Feedback from outside.

LAI 137 Feedback From Outside the Team

NIST's Govern five point one asks for practices that gather feedback from people outside the team, on impacts to individuals and society. Complaints and appeals about a decision are one source. Feedback that never reaches a Pack or card changes nothing, so route it into the object reviews.

When a vendor fails.

LAI 138 When a Third Party Fails

Generative AI at Work covered reviewing a vendor; NIST's Govern six point two adds contingency plans for failures in high-risk third-party data or AI. If a vendor's model is withdrawn, the team needs a known fallback for every Gold thing it touched. Mapping vendor fields to Gold things makes that fallback findable.

Nine entries on NIST's manage function, generative AI, and one feature governed from start to finish. The opening question is answered here.

What manage does.

LAI 139 What Manage Does

NIST's manage function allocates resources to the risks that mapping and measuring found, regularly and as governance defines. It includes plans to respond to, recover from and communicate about incidents. NIST is plain that manage continues after deployment, as methods, contexts and risks change.

Should it proceed?

LAI 140 Should It Proceed at All?

NIST's Manage one point one asks whether a system achieves its intended purpose and whether it should proceed at all. The book's checklist starts the same way: what the feature is for, and what it is not for. A purpose stated only after launch cannot be tested against.

Choosing a response.

LAI 141 Choosing a Risk Response

NIST's Manage one point two and one point three ask teams to prioritize risks and plan a response to each high-priority one. List the risks, such as a drafted notice softening a denial's reason. Rank them by impact, likelihood and resources. For each high-priority risk choose one of NIST's four responses: mitigate, transfer, avoid or accept. Write the choice and reason into the documentation, linked from the Gold Pack, and for mitigation name the control and its test. Teams reach for mitigation first, but avoidance, keeping the feature away from the Gold thing, is sometimes cheaper and safer.

Writing down what remains.

LAI 142 Residual Risk, Written Down

NIST's Manage one point four asks that negative residual risks, the sum of all unmitigated risks, be documented for downstream acquirers and end users. For a drafting feature, one might be a reviewer under time pressure approving a flawed draft. A risk accepted but not written down was never really decided.

The option without AI.

LAI 143 The Non-AI Alternative

NIST's Manage two point one asks teams to weigh the resources needed to manage AI risks against viable non-AI alternatives. For notices, an approved template with merge fields may give most of the speed with far less review. The question is whether AI is the best way, risks included.

Planning the off switch.

LAI 144 Planning to Switch It Off

NIST's Manage two point four asks for mechanisms, with assigned responsibility, to disengage AI whose outcomes stray from intended use. Write the signal that would show that. Name who can disengage the feature, and a deputy. Describe the fallback and test it once before launch. Record in each Gold Pack what happens to records the feature already changed, and add the plan to its matrix row. The book's checklist asks the same in plainer words, and a fallback never tried is a hope, not a mechanism.

Watching after release.

LAI 145 Monitoring After Release

NIST's Manage four point one and four point three ask for post-deployment monitoring and incident communication. Write a monitoring plan that draws on users, appeals and overrides, with triggers for decommissioning, and feed in the override log Generative AI at Work taught. Set incident response and recovery, linking that course's incident route. Decide who is told of errors, including affected communities where relevant, and feed lessons into the Pack and the next review. Watching only technical performance misses most of this; appeals and overrides are where people show a decision went wrong.

Generative AI, specifically.

LAI 146 Generative AI Warrants More Review

NIST's Generative AI Profile says generative AI is typically less well understood than other AI and may need different oversight, possibly more human review, tracking, documentation and management attention. The book cites this point. Gold things touched by generative AI are where that extra review belongs first.

One field, governed end to end.

LAI 147 A Pre-Filled Field, Governed

A worked example, constructed for this course, follows a generative feature that pre-fills the reason field on each Eligibility Determination. Sam, the AI Safety Lead, adds it to the inventory from the matrix, under Govern one point six. The boundary test shows an unedited pre-fill becomes the reason a family receives, so every reason must be confirmed by a caseworker, under Govern three point two. The purpose is written, consistent reasons citing the rule applied, not choosing outcomes. A wrong-rule risk is mitigated by checking the rule-set version; a hurried approval is recorded as residual risk. The program manager can switch it off, with the old free-text field as fallback. Appeals route back, overrides are reviewed monthly, and because it is generative, the review sample doubles at first. That answers this lecture's question: NIST says what governance must cover, and the method gives each answer a concrete place to stand.

Look at what you can now do. You can explain why the method's documents are also evidence, answering a regulator in an afternoon instead of a month. You can apply the govern subcategories Course One left aside, from matching effort to risk and inventorying AI to retirement, roles, voices, outside feedback and vendor failure. And you can take a feature through manage, from whether it should proceed to residual risk, the non-AI option, the off switch and monitoring. Unit Seven turns to teaching the method.