AI governance 101: from a policy to a reviewable decision

AI governance is the way an organization assigns decisions, responsibilities and oversight across an AI system's life. It is an engineering and organizational practice, not a model, a programming language or a feature you switch on. Compliance means meeting the obligations that actually apply to the organization and use. Responsible legal, security and business specialists establish those obligations; this exercise supplies engineering evidence for their work.

Think of an engineering change request. A diff shows what changed, tests describe observed behavior, and an owner decides whether the proposed change belongs in the operating system. The analogy has a limit: a technically correct change can still affect people, data use, contracts or work practices beyond what a code review covers. Include receiving operators and affected people where appropriate.

A policy states a rule: “the assistant may draft but may not send.” A control implements or supports that rule: the dispatcher excludes sending tools and checks each requested operation. Evidence records a specific observation, such as a denied send proposal against a named configuration. A decision states what an authorized owner accepts, rejects or needs revised, with its conditions. These four things are related; none substitutes for the others.

An FDE connects them. Writing “human review required” in a prompt is not evidence that a person saw the output. Drawing an access boundary is not proof that the server enforced it. A passing sample is not a guarantee that every future request will work.

Our fictional assistant drafts administrative replies from one internal guide collection. It may read a permitted guide and prepare a reply for an operator. Sending tickets, issuing operational instructions and using confidential records are outside this exercise's original scope. The alternative is the operator's existing manual lookup.

The recorded configuration is code C1, model M1, prompt P1, source collection (or corpus) D1, policy POL1, with read-guide and draft-reply tools. These labels are fictional identifiers, not vendor model names. A real record should identify the applicable versions or content digests, route, environment and observation window.

On a narrow screen, scroll the table sideways. The roles describe responsibilities; one person may hold several roles when the organization's rules permit it. The four rows are a small teaching subset, not a complete risk inventory. Privacy, accessibility, retention, data rights, harmful advice and other concerns can require separate work.

Write a risk as a possible event and consequence: “If the source is outdated, the draft could guide the operator to the wrong form.” State what supports your estimate of likelihood and impact. Avoid inventing a precise score when the evidence is thin. A control may reduce the concern without eliminating it; record the remaining uncertainty.

Download fde-governance-evidence-lab.py. Use Python 3.11 or newer; it uses only the standard library and prints to the terminal. It does not need an account, package install or network connection. Before running each case, name the changed field, the affected evidence and the next person who needs to act.

python3 --version
python3 fde-governance-evidence-lab.py compare
python3 fde-governance-evidence-lab.py model-change
python3 fde-governance-evidence-lab.py tool-expansion
python3 fde-governance-evidence-lab.py reported-incident

The program calls a record stale when one of that record's declared dependencies differs from the current configuration. Missing means there is no record for the required check. Fail means the packet supplies a failed observation. Not-run means the packet explicitly says the check was not performed. None of these is a pass.

The incident packet says that a draft reportedly contained private contact details. That is a report, not a confirmed root cause. Preserve a restricted incident reference, avoid copying the private text into general logs, and ask the responsible owner to assess exposure and containment. The program neither confirms the report nor dismisses it.

make_packet creates separate copies of the original configuration, its recorded review and four fictional observations. Each case changes only the listed part. inspect_packet compares fields and shows which declared evidence relationships no longer match. This comparison really executes; the underlying observations are supplied teaching data.

The CHECKS map declares each record's dependencies. For example, the supported-draft check names code, model, prompt and corpus. The dispatcher check names code, policy and tools. This illustrates proportional revalidation: preserve relevant component evidence, then identify the affected behavior and any missing end-to-end work. Do not infer that unchanged dependencies prove a complete application is safe. The dependency map itself can be incomplete.

A timestamp or “pass” label does not establish who ran a check, what happened or whether the record was changed. For actual work, keep the test procedure, inputs, environment, revision, result, accountable source and relevant limitations. Use the organization's evidence storage and access controls. A file comparison cannot authenticate a reviewer, prove a control exists or determine all applicable duties.

The output deliberately contains no approved result. Even the unchanged packet asks for responsible review. The owner must consider scope, incident reports, affected people, missing concerns and whether proceeding is justified. A tool can organize this evidence without taking over that decision.

Make two separate copies of the file. Retain the original output.

Experiment A: record an unrun rehearsal. In the missing-record branch, replace del packet["records"]["manual-fallback"] with packet["records"]["manual-fallback"]["result"] = "not-run". Run missing-record. The counts change from one missing record to one not-run record, with three passes unchanged. Recording an intention did not perform the rehearsal.

Experiment B: expand the data scope. In the model-change branch, replace packet["configuration"]["model"] = "M2" with packet["configuration"]["data_classes"].append("confidential"). Run model-change in this separate copy. All four declared check records now match, but changed_since_review contains data_classes and matches_recorded_configuration is false. None of the four check definitions declares a dependency on data classification. That is a deliberate gap to discover, not permission to process confidential data.

Explain the new handling, access, retention and processing questions this scope change raises. Propose evidence and responsible reviewers before modifying the record. Simply adding a field dependency or editing a result label cannot supply the missing observation.

Choose the tool-expansion or incident case. Fill in this short working record using only the packet's fictional facts:

Proposed use and people affected:
Current boundary and proposed change:
Evidence that still supports a specific claim:
Stale, missing, failed or unrun evidence:
Reported facts versus explanations still unconfirmed:
Possible consequence and control to investigate:
Immediate containment or manual alternative:
Responsible decision owner and receiving operator:
Next observation needed, and who will obtain it:
Review conditions and trigger for reconsideration:

For tool expansion, a defensible answer keeps sending outside the currently reviewed scope. Identify the exact recipient and content authority, duplicate-send recovery and a useful denial before requesting a new decision. Existing tenant-component evidence is retained for its limited claim; it is not relabeled as proof of the proposed sending workflow.

For the incident, a defensible answer preserves the four historical results and the new report together. It names the operational owner, a proportionate containment step and the investigation needed to distinguish a source problem, permission problem, generated content or another cause. Do not assert a breach cause or a successful fix from the report alone.

The U.S. National Institute of Standards and Technology (NIST) publishes the AI Risk Management Framework, a voluntary way to organize risk work. Its core groups that work into Govern, Map, Measure and Manage. Governance runs across the other functions; these are not four one-time approval stages. NIST states that AI RMF 1.0 is being revised; this lesson references the published 1.0 concepts checked on 21 October 2026.

In this exercise, identifying the decision owner relates to Govern; describing the use and affected people to Map; inspecting observations and their limits to Measure; and choosing responses and monitoring to Manage. This mapping is an original teaching aid. It is not a NIST assessment, certification or determination of compliance.

Keep the seven predictions, original outputs, both changed-copy outputs and your working decision record. Ask another engineer to explain the next action without your narration. Continue to Put policy around the model in the protected enterprise AI course, where you configure the small policy and inspect its permitted and denied requests.