How to Run a Blameless Postmortem for an AI Failure

After an AI feature fails in public, such as an assistant giving wrong advice or exposing internal notes, there's pressure to find out who made the mistake. That approach teaches people to hide problems. A blameless postmortem looks at how the system allowed the failure and what would stop it happening again.

Step 1: Stabilize first

Postmortems come after the incident is contained. Turn the feature off or roll back, confirm the impact has stopped and preserve the evidence: logs, traces, prompt versions and example conversations.

Step 2: Build a timeline

Within a few days, write down what happened, in order and with timestamps:

• When the change or trigger happened.
• When the first user was affected.
• When someone noticed, and how.
• Which actions were taken, and when.
• When the impact ended.

Build it from logs and messages rather than memory. Timelines written from recollection are often wrong.

Step 3: Describe the impact

Record who was affected, how many users or customers, what they saw and what it cost, including support time and any commitments made to customers.

Step 4: Ask how, not who

For each part of the timeline, ask questions about the system:

• How did the prompt change reach production without the problem being caught?
• Why didn't the evaluation set include this kind of input?
• How long did detection take, and which signal finally revealed the problem?
• What made the rollback slower or faster?

AI failures usually have several contributing factors, such as a gap in test cases, a missing quality alert and a manual release process all at once.

Step 5: Agree on actions

Choose a few concrete actions with owners and dates, for example "add 20 pricing questions to the eval set" or "put prompt releases behind a flag". Avoid vague actions like "be more careful".

Step 6: Share it

Publish the postmortem internally, because other teams building AI features will have the same gaps. For customer-facing incidents, share a shorter version with the affected customers.

Things to watch

• Blame language. Phrases like "should have known" shut down honest discussion. The facilitator should turn them into questions about the system.
• Blaming the model. "The model hallucinated" describes a symptom, not a cause. Ask why the system trusted that output.
• Follow-up. Review open actions in a regular meeting, or they won't get done.

Use a simple template for the next incident, even a small one. Practicing on minor issues makes the major ones easier.