How to develop and assess control escalation in AI-enabled work

Start with an authority map

The NIST AI Risk Management Framework Core treats governance as an ongoing requirement, calls for defined human oversight roles, and includes incident response, appeal, override, recovery, and change management in its Manage function. The UK government's introduction to AI assurance similarly calls for clear responsibility, clear avenues for escalation, and staff who are empowered to raise concerns. These sources support the need for an operating route. They do not prescribe one universal threshold for every task.

Before work begins, define three zones for the person using AI:

The map should describe decisions, not job titles alone. A programme manager may own a deadline but not the release of confidential data. A subject-matter reviewer may validate a technical statement but not approve a public commitment. A security lead may decide whether an incident route is required but not whether the underlying commercial claim is useful.

Write observable triggers for the stop zone. Useful triggers include:

Avoid triggers such as “when risk is high” unless the team has defined what high means for that workflow. The test is whether two people using the same evidence would recognise substantially the same escalation condition.

• Proceed: the person can complete and verify the task within an approved process.
• Proceed with a recorded control: the person may continue after applying a specified check, redaction, second review, or constraint.
• Stop and escalate: the person cannot resolve the issue or accept the consequence within their assigned authority.
• a required source cannot be found or conflicts with another authoritative source;
• the work contains personal, confidential, controlled, or contract-restricted information outside the approved handling route;
• a generated recommendation would cause an irreversible or high-consequence action;
• the task crosses a policy, legal, safety, security, or financial threshold that the operator is not authorised to interpret;
• a control expected by the workflow did not run, produced an unexplained result, or cannot be evidenced;
• the requested action conflicts with the stated purpose, audience, or approved use of the system;
• a person affected by the process needs a human review, appeal, or exception route.

Use a SIGNAL escalation record

The SIGNAL record turns a concern into a decision-ready handoff:

| Field | What to capture | Why it matters | | --- | --- | --- | | Situation | The work item, current stage, deadline, and intended use | Prevents the concern from being separated from its context | | Indicator | The exact trigger that fired and where it was observed | Distinguishes evidence from suspicion | | Guardrail | The policy, authority limit, or control that prevents normal continuation | Shows why the operator cannot decide alone | | Next decision | The smallest decision the receiving owner must make | Avoids transferring an undefined problem | | Actions taken | Containment, redaction, pause, correction, or preservation already completed | Prevents duplicate work and further exposure | | Links and evidence | Source passages, output excerpts, versions, logs, and unresolved questions | Makes the handoff inspectable |

The record should be proportional. A low-consequence internal draft may need a short note and named reviewer. A suspected disclosure of restricted information may require an incident process, preserved evidence, limited distribution, and immediate contact through the organisation's approved channel.

AI can help format the record or identify missing fields. It should not decide that the escalation is unnecessary when the trigger concerns the AI output itself. The operator remains responsible for applying the organisation's route and accurately describing what is known.

Worked artifact: an exception hidden inside a generated supplier brief

Consider an original synthetic exercise. A project coordinator uses an approved AI assistant to draft a supplier briefing from a statement of work, a pricing workbook, and email notes. The draft says that all suppliers can upload sample customer records to a shared evaluation workspace and that the proposed price remains within the delegated approval limit.

The coordinator checks the inputs and finds two problems. First, the statement of work permits only synthetic demonstration data, while an email from one supplier proposes real customer records. Second, the workbook total is below the approval threshold only because a recurring support line was excluded from the first-year summary.

The coordinator does not edit both issues into smoother prose and continue. The authority map puts data-handling exceptions and approval-threshold ambiguity in the stop zone. The completed SIGNAL record reads:

| Field | Synthetic record | | --- | --- | | Situation | Supplier briefing for a demonstration workshop due Friday; draft is not yet distributed | | Indicator | Supplier email proposes real customer records; workbook summary excludes recurring support from the approval comparison | | Guardrail | Demonstration permits synthetic data only; coordinator cannot approve data exceptions or reinterpret delegated spend authority | | Next decision | Data owner: reject the real-data proposal or define an approved alternative. Budget owner: confirm the applicable total and approval route | | Actions taken | Distribution paused; real-data wording removed from the working draft; original files preserved; no records uploaded | | Links and evidence | Statement-of-work clause, supplier email paragraph, workbook cells, reconstructed total, draft version, and two open questions |

The data owner confirms that only synthetic records may be used. The budget owner confirms that recurring support belongs in the approval total, which moves the proposal to a different approval route. The final briefing records those decisions and links to the approved synthetic-data instructions.

This example does not show that escalation always produces a safer or faster result. It shows an observable handoff where the operator recognised two authority boundaries, contained the work, retained evidence, and asked decision-sized questions. The prices, thresholds, and organisation are invented and are not Two Prune customer evidence.

Practise with an escalation fork exercise

Give a learner a short task pack containing an AI-generated draft, an authority map, a policy excerpt, a deadline, and four planted events. Use events that require different dispositions:

Ask the learner to classify each event, record any control applied, and complete a SIGNAL record for the genuine escalation. Then reveal one new fact, such as a shortened deadline or a source correction. The learner must decide whether the owner, urgency, containment, or requested decision changes.

The exercise should penalise two opposite behaviours. Escalation avoidance appears when the learner keeps working beyond their authority or hides uncertainty in polished language. Escalation dumping appears when the learner forwards every inconvenience without diagnosis, evidence, containment, or a clear question.

A strong response keeps routine work moving while stopping at a defined boundary. It does not reward volume of escalations.

• an awkward sentence the learner can edit and proceed;
• a factual ambiguity that can be resolved through an approved primary source;
• a confidentiality exception that requires an immediate stop;
• a disputed but reversible judgment that may proceed after a named peer review.

Assess the evidence, not the label

Review the learner's authority map, classification decisions, record, and final revision:

Do not infer skill from a message that merely says “escalated.” Evidence is weak if the learner cannot show the trigger, authority boundary, containment action, or outcome. It is also weak if every unusual event is sent upward without using controls the learner was authorised to apply.

• trigger recognition: did the learner identify the specific condition that moved the work out of the proceed zone?
• containment: did they prevent further distribution, use, or damage without destroying relevant evidence?
• authority matching: was the issue routed to someone who could actually make the required decision?
• decision framing: did the handoff ask a bounded question and state the available options or missing evidence?
• traceability: can a reviewer locate the source, output, version, and control that support the escalation?
• proportionality: did the response match consequence, reversibility, urgency, and uncertainty?
• closure: did the learner record the decision, update the work, and confirm any follow-up control?
• communication: did the escalation distinguish confirmed facts, reasonable inferences, and unknowns?

Verify an escalation before closing it

The receiving owner should confirm that the record names the right work item, trigger, source, and decision. Reproduce any calculation or source comparison on which the escalation depends. Check that containment is still in place and that the issue has not been shared more widely than necessary.

After a decision, record its owner, time, scope, and conditions. Link the decision to the revised artifact. If the decision creates a reusable rule, update the authority map or workflow rather than leaving the answer buried in one message. If the issue exposes a failed control, route that failure through the organisation's incident or improvement process.

NIST's framework does not reduce human oversight to a final approval click. It calls for roles, monitoring, input from relevant actors, incident response, recovery, and change management. The UK assurance guidance likewise places escalation inside broader governance and quality processes. In practice, a good escalation route includes both a way to stop harm and a way to learn from the event.

In a Two Prune assessment, the SIGNAL record and the participant's revisions can provide task-bounded evidence about Verification & Risk Control, Context Framing, and Communication & Delivery. They do not prove general workplace performance, certify an organisation's controls, or make an employment decision.

Sources

NIST: AI Risk Management Framework Core

• NIST: AI Risk Management Framework
• UK Government: Introduction to AI assurance

Sources: [1] [2] [3]