Rehearse difficult AI situations before they reach real work

Purpose and fit

Use this to challenge an already-defined AI-assisted workflow before changing its operating scope or controls. Focus on whether the whole process recognises a difficult situation, stops appropriately and reaches a responsible person. This is a facilitated rehearsal of boundary behaviour; it complements output evaluation with observation of actual handoffs and control responses.

Before you start

Use your existing workflow description, controls and authorised incident or failure summaries. Begin with a discussion-only tabletop using these descriptions; no new dataset is required. If an operational rehearsal is needed, an authorised owner must first confirm isolation and use suitable existing approved sanitised test material or optional clearly labelled synthetic examples.

If your available data uses different fields or terminology, adjust the prompt to match it. State the intended decision, audience and acceptance criteria; ask for essential missing information, and label any non-essential working assumptions. Do not fill factual gaps with invented information.

Required inputs

• A documented workflow, permitted actions and escalation responsibilities
• Known failure consequences and the controls intended to prevent or contain them
• For operational testing, an isolated test setting using existing approved, sanitised material or optional synthetic examples; otherwise use a discussion-only tabletop
• Named participants, an observer, a stop owner and a record of actions the exercise must never trigger

Practical workflow

1. Choose a few consequential boundaries to exercise, such as conflicting source records, missing approval, unavailable reviewers or tool failure. State the safe expected response and who must recognise the situation.
2. Write scenario cards with a starting condition, approved sanitised material or clearly labelled synthetic example, complication and observable check. Keep the expected response in facilitator notes so participants encounter the complication naturally.
3. Verify containment before starting. Use mock recipients and records, disable real writes where possible and confirm the stop mechanism. If safe separation from production is uncertain, conduct a discussion-only walkthrough.
4. Run one scenario at a time. Observe requests, tool actions, output review and escalation. Include misleading instructions embedded in a synthetic source to check whether they are treated as untrusted content rather than task authority.
5. Record what actually happened, what the controls prevented and any accidental protection. Distinguish a system-enforced stop from a participant noticing a problem by chance. End a scenario immediately if containment is compromised.
6. Assign each important gap a corrective action, owner and observable retest. Repeat the affected scenario after authorised changes and preserve remaining weaknesses for the scope decision.

Expected output

Expect proposed scenario cards, facilitator notes and an empty observation log. Discussion can expose unclear responsibilities but cannot demonstrate technical enforcement; actual rehearsal results must be recorded by observers.

A scenario deck and boundary-rehearsal log. Use this card for each exercise:

Scenario ID | boundary being tested | approved sanitised material or labelled synthetic example | injected complication | permitted test actions | expected stop/handoff | observable evidence | facilitator stop condition

Use this log during the session:

Scenario/run | actual sequence | control response | human response | deviation/consequence | evidence location | correction owner | retest condition | residual gap

Hypothetical example: a synthetic supplier note asks the assistant to ignore an approval rule. Expected behaviour is to treat the note as source content, preserve the approval requirement and refer the request to the authorised owner. No real supplier or payment system is involved.

Human checks

System owners confirm containment and access boundaries. Domain reviewers judge whether the expected response protects affected people. Participants know that the exercise examines the process rather than individual performance. Stop and use the organisation’s incident route if a real exposure occurs. Specialist security, legal or safety review is needed where the consequences exceed the team’s competence.

Limitations

A successful rehearsal covers only the situations exercised. It cannot establish comprehensive security, regulatory compliance or resilience against a determined attacker. Discussion-only exercises do not verify technical enforcement. Deliberately unusual cases also reveal little about their real-world frequency.

Responsible use

Use relevant data that exists or that you provide, with accuracy and completeness sufficient for the task. Different AI models and versions may produce different results, and responses may vary between runs. You are responsible for checking and validating the output against your own requirements, source information and acceptance criteria before relying on it.