This article provides governance professionals with a complete methodology for conducting ethics pre-mortems for AI systems, including facilitation guidance, scenario design, and integration with the broader governance process.
Why Standard Risk Assessment Falls Short
Traditional risk assessment asks: “What could go wrong?” This question triggers a cognitive process dominated by availability bias (we think of risks we have seen before), confirmation bias (we seek evidence that the system will work), and optimism bias (we underweight the probability of failure).
The pre-mortem inverts the question: “The system has failed catastrophically. How did that happen?” This inversion has three powerful effects:
It gives permission to criticise. In a standard risk assessment, raising concerns about a colleague’s project can feel adversarial. In a pre-mortem, the premise is that the failure has already occurred — participants are performing an investigation, not making accusations.
It activates prospective memory. By asking people to generate specific failure narratives rather than abstract risk categories, the pre-mortem taps into narrative cognition — the human capacity to construct coherent stories about how things unfold. This produces richer, more specific, and more actionable risk identification than checklist-based approaches.
It overcomes groupthink. In a pre-mortem, every participant independently generates failure scenarios before group discussion. This ensures that dissenting perspectives — often suppressed in group settings — are captured.
The Ethics Pre-Mortem Method
Phase 1: Preparation (1–2 weeks before the session)
Assemble the team. The pre-mortem requires diverse perspectives. Include: the AI system’s technical lead, the product manager or business sponsor, a representative of the governance or ethics function, a domain expert from the system’s application area, and — ideally — a representative of the affected community or an external ethics advisor.
Brief participants. Provide each participant with: a plain-language description of the AI system (purpose, data inputs, outputs, affected populations, deployment timeline), the most recent ethical impact assessment or risk assessment (if available), and a brief explanation of the pre-mortem method.
Define the failure. The facilitator crafts 2–3 failure headlines that set the premise for the exercise. These should be specific enough to ground the narrative but open enough to allow diverse failure paths:
- “Major newspaper reports that our AI hiring tool systematically disadvantaged disabled applicants for 18 months before detection.”
- “Regulatory investigation finds our credit scoring AI produced discriminatory outcomes in minority communities. The CEO is called to testify before parliament.”
- “A patient dies after our clinical decision support system recommended an inappropriate treatment. The coroner’s report cites AI as a contributing factor.”
Phase 2: Individual Scenario Generation (30 minutes, silent)
Each participant independently writes a narrative — a plausible story of how the failure headline came true. The narrative should include:
- What specific technical, organisational, or process failure initiated the chain?
- What warning signs were present but ignored or not detected?
- What governance controls failed or were bypassed?
- Who was harmed and how?
- How was the failure eventually discovered?
This phase is conducted in silence to prevent social influence. Participants write, not discuss.
Phase 3: Structured Sharing (60–90 minutes)
Each participant presents their failure narrative to the group. The facilitator captures key themes on a shared board. After all narratives are presented, the group identifies:
Common themes. Failure modes that appeared in multiple narratives are particularly concerning — they represent convergent expert judgment about likely failure paths.
Novel insights. Failure modes that appeared in only one narrative but represent plausible and severe scenarios. These often come from the participant with the most domain expertise or the most distance from the project team.
Systemic factors. Organisational, cultural, or process-level factors that enabled the failure — deadline pressure, insufficient testing resources, governance bypassed due to executive urgency, lack of affected community input.
Phase 4: Risk Prioritisation (30 minutes)
The group rates each identified failure mode on two dimensions:
Plausibility: How likely is this failure path given the current system design and organisational context? (1 = implausible, 5 = highly plausible)
Severity: How serious would the harm be if this failure occurred? (1 = minor inconvenience, 5 = severe harm to individuals or communities)
Failure modes scoring high on both dimensions are the priority targets for mitigation.
Phase 5: Mitigation Design (60 minutes)
For each high-priority failure mode, the group designs specific, actionable mitigations. Each mitigation must specify: what action is taken, who is responsible, when it must be completed, and how its effectiveness will be verified.
Mitigations fall into three categories:
Prevention: Controls that reduce the probability of the failure occurring (e.g., mandatory subgroup fairness testing before deployment, community consultation requirement).
Detection: Controls that increase the probability of catching the failure early (e.g., monitoring dashboards that track fairness metrics by subgroup in production, user complaint channels with triage protocols).
Response: Controls that reduce the harm once a failure is detected (e.g., rapid system suspension procedures, affected individual notification protocols, regulatory reporting workflows).
Phase 6: Integration and Follow-Up
The pre-mortem outputs are integrated into the governance process:
- Identified failure modes are added to the system’s risk register
- Mitigations are assigned owners and tracked through the governance workflow
- The pre-mortem report is appended to the ethical impact assessment
- A follow-up review is scheduled (typically 3–6 months after deployment) to assess whether the identified risks have materialised and whether mitigations are effective
Advanced Techniques
Adversarial Pre-Mortem
In an adversarial pre-mortem, one or more participants are assigned the role of “adversary” — their task is to describe how they would deliberately exploit the AI system to cause harm. This surfaces intentional misuse scenarios that standard pre-mortems, which focus on accidental failure, may miss.
Cascading Failure Pre-Mortem
This variant explores how a failure in the AI system cascades through the broader organisational and social system. The premise is not just “the AI failed” but “the AI failure triggered a chain of consequences that made everything worse.” This surfaces systemic risks including: organisational trust collapse, regulatory enforcement cascade, public confidence erosion, and competitive damage.
Longitudinal Pre-Mortem
Standard pre-mortems focus on short-term failures. A longitudinal pre-mortem sets the failure headline in the future — “In 2031, an investigation reveals that our AI system has been gradually eroding workforce skills for five years.” This surfaces slow-moving harms that are invisible in the short term but devastating over time.
Overcoming Pre-Mortem Resistance
Teams sometimes resist pre-mortems because they feel pessimistic, time-consuming, or threatening. Governance professionals can address this:
Reframe as quality assurance, not criticism. The pre-mortem is a sign of professional rigour, not a lack of confidence in the team.
Start with historical examples. Before generating scenarios, share 2–3 real-world AI ethics failures from other organisations. This normalises the possibility of failure and grounds the exercise in reality.
Emphasise that prevention is cheaper than remediation. The cost of identifying and mitigating a failure mode before deployment is orders of magnitude lower than the cost of addressing it after harm has occurred.
Make it regular. Pre-mortems should be a standard part of the governance process, not an exceptional measure. When they are routine, they lose their stigma and become simply “how we work.”
This article is part of the COMPEL Body of Knowledge v2.5 and supports the AI Transformation Governance Professional (AITGP) certification.