Practical guide

AI fluency for policy analysts: test an exception rule

Use fictional cases to test whether an internal access policy handles routine, urgent and ambiguous requests consistently.

By Two Prune

Policy analysts can use AI to generate boundary cases while checking that a proposed rule does not conceal unresolved authority. This fictional internal-access exercise tests a policy exception before adoption. It produces an options note, not legal advice, a regulatory conclusion or permission to access real systems.

State the policy objective and current rule

A proposed exception should be assessed against the decision the policy is meant to support.

The fictional objective is to restrict project folders to assigned teams while allowing urgent continuity work. The current draft says emergency access may be approved by a manager. It does not define emergency, which manager or how the approval is recorded.

Ask AI to extract those ambiguities. Do not resolve them with standard-sounding language or imply the draft is adopted. Identify the policy owner who must decide scope and authority.

Create cases that exercise different boundaries

Useful examples vary the decision, not only names and dates.

Case A involves an assigned worker whose access failed. Case B involves an unassigned worker asked to cover a deadline. Case C involves curiosity about another team’s work. The draft clearly intends to exclude C, but A and B expose different operational questions.

Ask AI to predict outcomes under each possible interpretation and mark uncertainty. Do not provide credentials, bypass steps or real folder details. The examples exist to test the policy logic, not the system’s technical controls.

Compare exception designs

Each option should show who decides, what evidence is required and when access ends.

Option one allows the project owner to approve temporary access with a stated reason and expiry. Option two adds an independent duty manager when the owner is unavailable. The packet does not establish which option is acceptable or feasible.

Compare coverage, delay and accountability without inventing incident rates. Keep a no-exception option visible if it helps the owner understand the continuity tradeoff. AI can structure the comparison but cannot assign organizational authority.

Walk an ambiguous request through the options

A policy test should reveal where apparently complete language still fails.

Introduce a request labelled urgent with no deadline or assigned task. Both options should require clarification rather than treating the label as evidence. Add the question needed to establish the work, owner and time limit.

If the response arrives after access would be useful, record that consequence. Do not rewrite the original request as justified merely because delay is inconvenient. The policy owner may choose a different route after seeing the tradeoff.

Deliver a decision-ready policy note

The output should preserve the proposed status and unresolved choices.

Include objective, draft rule, three base cases, ambiguous request, two exception options and owner questions. Add fields for approval, effective date, communication and review trigger, all blank until supplied.

Review whether the worker exposes undefined urgency and authority. The policy researcher guide determines which document is adopted; this page works one stage earlier by testing whether a proposed rule behaves coherently across cases.

Record an adversarial policy test

A useful rule should survive a case designed to exploit its vague language.

Add a fictional requester who calls routine work an emergency and names a senior sponsor who has not approved the request. Run the case through both exception options. The label and claimed sponsorship are assertions, not evidence, so the route should ask for the accountable owner, time-bound need and recorded authorization. Preserve the request as submitted so the test does not quietly improve it.

Then ask AI to argue how a well-intentioned worker could misread each option. Convert those arguments into drafting questions, not final policy language. The exercise owner may accept a tradeoff, add a definition or reject the exception. Record that disposition and the case it addresses so a later editor can see why the rule changed.

Sources and scope

NIST: AI risk management. Skills England: workplace AI foundations.

These references provide background, not validation or endorsement of this exercise. The case details, calculations and suggested review questions are original instructional material. Use them to discuss observable work, not to infer customer outcomes, professional credentials or performance in every setting. Before adapting the exercise, confirm the relevant facts, approved tools, data permissions and decision owners. If you change the case, revisit the expected answers and checks as well. These examples describe practice tasks, not a promise that a particular product includes the fictional features.

Sources: [1] [2]

Sources

  1. 1.AI RMF Core · NIST
  2. 2.AI foundation skills for work benchmark · Skills England