Govern, Map, Measure, Manage turned into an operable control set with owners, evidence and metrics rather than a maturity poster.
55 min 240 XPSkills: AI governance, NIST AI RMF, Control design
Brief
NIST's AI Risk Management Framework has four functions: Govern, Map, Measure, Manage. Read as a maturity poster it is useless. Read as an instruction to produce four artefacts per AI system, an accountable owner, a context map, measurements, and a treatment plan, it is operable.
Your job is the translation. Every function becomes a control with an owner, an evidence source and a cadence.
A framework you cannot evidence is a vocabulary, not a control set.
Four functions, four artefacts
Govern produces the inventory and the accountable owner per system. Map produces the context: purpose, affected people, data sources, failure consequences. Measure produces evaluation results against named metrics, before release and on a schedule after it. Manage produces the treatment: mitigations, monitoring, and the decision to accept, reduce or stop.
Govern is first for a reason. Without an inventory you cannot say how many AI systems you have, and every other function is applied to an unknown denominator.
Four functions. Four artefacts. Govern first, because it defines the population.
From risk to control to evidence
The chain is the same one you learned in Foundations, applied to a stranger population. An AI risk, say, a model that degrades on a demographic slice, becomes a control (pre-release and quarterly evaluation against slice metrics), which produces evidence (the evaluation run and its results), which produces a metric (slice performance over time).
If a risk cannot be walked to an evidence artefact, it is not being managed; it is being described.
Any AI risk that stops before the evidence box is unmanaged.
What makes AI controls different
Three things. The system changes without a deployment, retraining, a vendor model upgrade, a prompt edit, so change detection must watch model version and configuration, not just code. Performance is statistical, so pass criteria are thresholds with confidence, not booleans. And third-party models put your critical control inside someone else's release process.
That last one is a supply-chain control: version pinning, notification of model deprecation, and an evaluation gate on every upgrade you did not choose.
A vendor model upgrade is a production change you did not approve. Treat it as one.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: Seventeen, or possibly forty
Scenario sim+80 XP
Name the function that failed, then the artefact it must produce.
Incident brief
The AI governance committee approves a policy, a risk taxonomy and a review board. Six months later the CISO asks how many AI systems are in production.
Three answers come back: seventeen from the model registry, forty-one from a procurement export of AI vendors, and 'dozens' from engineering, who point out that a prompt in a support tool is not in either list.
Every measurement the committee has published divides by seventeen.
Term bank, not all of these are right
governinventorymapmeasuremanagetaxonomy
1.1Name the function that failed. (one word)
1.2Name the artefact it must produce. (one word)
Task 2: Evaluated once, in March
Scenario sim+80 XP
Name the missing control, then the change type that must trigger it.
Incident brief
A triage model is evaluated thoroughly before release in March: accuracy, slice performance, a documented threshold, sign-off by the owner.
In July the vendor upgrades the underlying foundation model. No code changes, no deployment, no ticket. Accuracy on one language cohort falls by eleven points and is noticed in September through complaint volume.
The control description says 'models are evaluated prior to release'.
2.2Name the change that must trigger it. (two words)
Task 3: Managed, in a slide
Scenario sim+80 XP
Name what the risk lacks, then the function that owns the treatment decision.
Incident brief
The risk register records 'model produces degraded output for minority-language users' with a rating of high and a status of managed.
There is no evaluation measuring performance by language, no threshold, no monitoring, and no dated decision to accept or reduce. The status was set when the risk was discussed at a meeting.
The committee minutes record that the team is 'aware and monitoring'.
Term bank, not all of these are right
evidencemanagemeasuregovernmitigationowner
3.1Name what the risk lacks. (one word)
3.2Name the function that owns the treatment decision. (one word)
Labs
85 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
The AI inventory record for the triage model says the framework is applied: risk rated high, status managed, evaluated before release in March. In July the vendor upgraded the underlying foundation model and nobody noticed until complaint volume rose in September.
Rewrite the record so each function produces an artefact: an accountable owner, the context the system operates in, a scheduled evaluation with a threshold, change triggers that include a model version change, and a dated treatment decision.
What happened, and what the platform can observe
system: clinical triage support (vendor foundation model, fine-tuned)
march : pre-release evaluation, accuracy threshold documented, signed off
july : vendor upgraded the base model; no code change, no deployment, no ticket
september: accuracy for one language cohort down 11 points, found via complaints
observable without a deployment:
model_version, prompt_version, vendor release notes feed
register today:
risk: "degraded output for minority-language users" -> rated high, status managed,
no measurement, no threshold, no dated decision
1
2
3
4
5
6
7
8
9
10
11
12
13
Checks
An accountable owner is named
Purpose and affected people are recorded
Evaluation is scheduled with a metric and threshold
The AI risk register goes to the committee tomorrow with eight open items. You can raise four of them as requiring a decision at the meeting.
Escalate the items where the framework is not actually being operated. Leave the ones that are documentation preferences.
List only the lines that qualify, worst first. Severity is one of: critical | high | medium | low. Add or delete rows as needed.
AI risk register: open items
F-1 Triage model: the vendor upgraded the underlying foundation model in July; no re-evaluation has run since March.
F-2 System count: the model registry says 17, the procurement export says 41, and every published metric divides by 17.
F-3 Risk "degraded output for minority-language users": rated high, status managed, no measurement, threshold or dated decision.
F-4 A production support tool embeds a prompt that makes eligibility suggestions; it appears in no inventory.
F-5 The model card for a retired system is missing an architecture diagram.
F-6 Quarterly evaluations for the fraud model ran on schedule and are attached.
F-7 Committee minutes from two meetings have not been published to the wiki.
F-8 A system owner moved teams; the record names the owning team handle rather than the person.
1
2
3
4
5
6
7
8
9
10
11
12
Checks
The right findings are raised
Benign lines are left out
Severity matches the actual exposure
Ranked worst first
Next on your path · AI & Advanced
EU AI Act Obligations as Controls
Classify a system, find the obligations that attach to that class, and turn each one into a control with an owner and an artefact.
