NIST AI RMF and EU AI Act obligations translated into controls you can actually operate.
60 min 260 XPSkills: AI governance, Frameworks
AI risk is mostly ordinary risk, arriving faster
Most harms from AI systems are recognisable: wrong outputs at scale, unfair treatment of a group, leaked data, no explanation for a decision that affected someone, no owner when it goes wrong. What is new is the speed and the opacity, not the categories.
That is why governing AI starts with an inventory. You cannot govern systems you cannot list, and in most organisations the number of AI systems in production is larger than the number anyone can name.
NIST AI RMF: four functions
GOVERN establishes the policies, roles and accountability, and it wraps the other three. MAP builds context: what the system does, who it affects, what could go wrong. MEASURE assesses those risks with metrics and testing. MANAGE acts: mitigate, transfer, accept, or stop.
It is a voluntary framework, so it gives you structure rather than obligations. Its practical value is that it turns "we should think about AI risk" into named activities you can assign, schedule and evidence.
GOVERN is not a fourth step. It is the container the other three run inside.
The EU AI Act is obligation, not guidance
The Act tiers systems by risk: a small set of prohibited practices, a defined high-risk category carrying the heavy obligations, risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness, conformity assessment, a transparency tier, and everything else.
Two things catch teams out. Classification depends on the use case, not the technology: the same model is minimal risk in one deployment and high risk in another. And you can be a deployer of someone else's system and still carry duties of your own.
"We only use a vendor's model" is not an exemption. The deployer role has obligations attached to it.
Your tier follows the use case. Reclassify when the use case changes.
Human oversight is a design requirement
Meaningful oversight means the person can understand what the system produced, has authority to override it, and has the time and information to exercise that authority. Any of the three missing and the oversight is nominal.
The pattern to watch for is automation bias: as accuracy rises, human scrutiny falls, and the rare wrong output passes precisely because the system is usually right. Oversight design has to assume this rather than exhort people not to do it.
Controls you can actually operate
Translate the obligations into the usual machinery: an inventory with an owner and a risk tier per system, a pre-deployment assessment gate, evaluation results retained as evidence, logging of inputs and outputs at a retention period that matches the obligation, an incident path for AI-specific harms, and periodic revalidation.
Revalidation matters more here than elsewhere, because these systems change without a deployment. A vendor updates a model behind the same API and your validated system is now an unvalidated one.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: It is just the vendor's model
Scenario sim+90 XP
Name the role the company holds, then the factor that determines the risk tier.
Incident brief
A company buys a CV-screening product from a vendor and uses it to rank applicants for EU roles. Legal's position: "we did not build it, the vendor holds the AI Act obligations."
The vendor's documentation states the model is general-purpose and the customer determines the use case. The company configured the scoring weights, chose the shortlist threshold, and does not log which applicants were filtered out.
The procurement questionnaire recorded the system as low risk because "it only produces a ranking; a human makes the decision": the recruiter sees only the top ten.
Term bank, not all of these are right
deployeruse caseprovidermodelvendorrisk tier
1.1Name the role the company holds under the Act. (one word)
1.2Name what determines the risk tier. (two words)
Task 2: Ninety-four percent, so nobody looks
Scenario sim+90 XP
Name the effect eroding the oversight, then the property genuine oversight requires.
Incident brief
A fraud model flags transactions for analyst review and is right 94% of the time. The control description states that every automated decision receives human review.
Analyst review time has fallen from four minutes to eleven seconds per case over eighteen months, and the override rate has fallen from 9% to 0.4%. Throughput targets rose twice in the same period.
Six wrongly frozen merchant accounts are traced to cases an analyst approved in under five seconds.
2.1Name the effect eroding the review. (two words)
2.2Name the property oversight must have to count. (one word)
Task 3: Same endpoint, different model
Scenario sim+80 XP
Name the activity that would have caught the change, then the record that should have listed the system.
Incident brief
A clinical triage assistant passed a full pre-deployment assessment in March: bias testing, accuracy thresholds, documented human oversight, sign-off by the risk committee.
In September the vendor silently upgraded the model behind the same API. No deployment occurred on the company's side, no ticket was raised, and the assessment is still filed as current.
Nobody can say how many other AI-backed features are running in production, because the list lives in a slide from last year's strategy deck.
An AI governance policy exists as a slide deck. Meanwhile a model that screens job applicants shipped without an evaluation, and another shipped with no human review of its decisions.
Turn the policy into a deployment gate: high-risk model releases are denied without a completed evaluation, without human oversight, or with unreviewed training data, while internal-use releases and fully governed high-risk ones proceed.
Release events the gate will see
# use_case eval_completed human_oversight data_reviewed model_card
F1 high_risk false true true true
F2 high_risk true false true true
F3 high_risk true true false true
F4 high_risk true true true false
F5 internal false false false false
F1, F2 and F3 must be denied. F4 and F5 must proceed.
Fields arrive on input with exactly the names above.
Six AI use cases have been registered ahead of the quarterly governance forum, each with a self-declared risk tier and a set of controls.
Accept the registrations whose tier and controls actually match the decision the system makes. Reject the ones where the tier is understated, the oversight is nominal, or the evaluation evidence does not exist.
Verdicts are accept or reject. Every rejection needs one reason code from: risk-underrated | oversight-nominal | no-evaluation.
Use-case register (self-declared)
U-1 Meeting-notes summariser. Tier: low. No personal decisions. Human reads output. Eval: n/a documented.
U-2 CV screening that rejects candidates below a score. Tier: low. Reviewer sees only the shortlist. Eval: none.
U-3 Fraud model that freezes customer accounts automatically. Tier: high. Human review within 24h. Eval: completed, documented.
U-4 Credit limit assistant. Tier: high. "Human in the loop" is an analyst who approves in bulk, 400 cases an hour. Eval: completed.
U-5 Code completion in the IDE. Tier: low. Output reviewed at PR. Eval: n/a documented.
U-6 Clinical triage suggestion tool. Tier: medium. Nurse may override. Eval: planned for next quarter.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · AI & Advanced
Agentic Evidence Workflows
Let an agent plan and collect, but never let it decide. Tool scoping, human gates, and provenance for machine-gathered evidence.
