A policy can be signed and still not say what the system is for, who will feel it or whether a person with a checklist would have been the safer tool. The prohibition arrived before anyone had described the work. Staff can follow a ban. They cannot use it to decide a case the ban never pictured.
The Map function in the NIST AI Risk Management Framework is the step that description belongs to. The playbook page is Map. Map 1 says context is established and understood. The note on context is blunt about accuracy. Highly accurate and optimised systems can cause harm. Organisations should expect tools that are widely deployed to be reused, repurposed and potentially misused, whatever the original intention was. Context mapping is described as the first step, before you decide how to manage that.
What the map has to contain
The page asks for the intended purpose, the setting the system will run in, who uses it and the harm it can do to people, groups and the organisation. It also asks for uses you did not intend. A workshop that leaves with a list of approved tools, and no sentence of purpose for the tool staff already use, has not started. The tool's name is not the context. The task is.
Context mapping, on the same page, includes a non-AI or non-technology alternative and a judgement about whether the situation is narrow enough that the harm can be managed. The alternative can be a mostly manual method. That option has to be a real outcome of the day. If every system on the list leaves with a rule for how to use it, and none leaves with a decision to keep the work in human hands, the map was not allowed to finish. Map 1.3 says that writing the business purpose down, against wider values and not only against an internal target, makes a go or no-go decision clearer. Where the risks outweigh the benefit, the page treats not deploying as a legitimate result.
Who has to be in the room
Map 1.2 says mapping context takes a group with a range of experience and the independence to inquire. The benefit is not a guess at what each person believes. It is what more than one perspective will surface. A room of policy writers, mapping a system they do not operate and do not receive, will describe the harm they imagined. Put the person who runs the task and someone who receives the output in the same exercise.
Read the agenda for the page it will produce. You want one system, a sentence of purpose, the people affected, one harm, one use you did not intend and a non-AI alternative someone may prefer. You want a recorded go, a recorded limit or a recorded no. A template of banned inputs, filled in before that page exists, is the rule without the map.
What you should be able to refuse
Bring a system that is already in use, not a hypothetical model. If the day cannot end with that system left unused or left inside a narrower task, you have booked an approval. The playbook's point is that the context comes first so the refusal is available. A sponsor who wants every exercise to end in a control, rather than in a decision not to deploy, has answered the go or no-go in advance.
Collective Campus is building high-performance culture and teams for the AI world. The AI governance workshop is for a group that can map a live system and is allowed to leave it unused. What a board should have on paper by the end of a different day is in what a board should write down. What leaders still have to settle about approval is in what AI governance training for leaders has to settle. The questions a manager will be asked once a written rule exists are in the questions an AI policy will raise.
What to bring
Bring the system, the task it already sits inside and the name of the person who may refuse it. If refusal is off the table, the map has nothing to decide.
