Share an AI failure as a bounded account of the work, the observed problem and the change being tested. Keep enough context for another colleague to recognize the same situation, while restricting sensitive records to their proper audience. Explain what remains uncertain and what the follow-up actually established. A dramatic bad answer or a promise to “be more careful” gives the next person little to use.
For a knowledge or enablement lead, the aim is to help a colleague make a better decision when a similar case appears. Learning from a failure also needs room for people to describe what they knew at the time, without the shared account becoming a public judgment about their competence.
Deal with the current problem before widening the audience
If an incorrect customer message has already been sent, first use the organization's route for correcting it and reporting the issue. Suspected exposure of confidential information belongs with the people authorized to investigate it. A team discussion or library entry must not become the place where someone first discovers an unresolved incident.
Keep the detailed incident record and the reusable lesson connected, with access appropriate to each. The investigator may need original messages, identities and logs. A colleague learning how to check a course announcement usually does not need the customer list or the name of the employee who prepared it.
For an unavailable or unreliable service, the continuity guide explains how to recognize the affected work and choose an approved fallback. This article addresses the later question of what another team should learn from that experience.
Reconstruct the difference between expected and observed work
Suppose Jamie Lee coordinates courses at a regional adult-training provider. An approved assistant drafts a weekly announcement from a planning sheet. That sheet contains both confirmed courses and provisional courses still waiting for an instructor. The draft presents a provisional course as ready for booking. Jamie catches it before sending the announcement.
“AI gets course details wrong” is too broad to help the next coordinator. Preserve the condition that changed the decision: the source contained a provisional status, and the draft lost that distinction.
Start the account with facts someone can inspect:
- Task and requirement. Prepare an announcement using only courses confirmed for booking.
- Observed departure. A course marked provisional in the supplied planning sheet appeared as available in the draft.
- Consequence and detection. Jamie found the mismatch during source checking; the announcement had not been sent.
- Known limit. The team has not yet established why the status was omitted or whether other cases are affected.
Retain relevant dates, versions, instructions and source references in the permitted working record. Do not infer the model's internal reasoning from its explanation of the mistake. Several different changes can produce a similar-looking symptom.
Anthropic's April 23, 2026 quality report illustrates the value of that distinction. The company separated reports of degraded responses into three application changes with different timing and scope, and said the API was unaffected. It also described changes to its evaluation and release practices. This is a supplier's account, not independent confirmation of every affected experience. Its useful example is the specificity of the explanation, rather than a general conclusion that AI has become better or worse.
Make the discussion factual without erasing responsibility
Ask what information and working conditions shaped the decision. Was the provisional status visible in the material supplied? Did the drafting instructions mention it? Was checking that status part of the receiving person's task? These questions make the work examinable without deciding in advance that someone was careless.
Google's site reliability engineering guidance treats a postmortem as a learning record, rather than punishment. Its practitioners describe reviewing contributing circumstances and preventive actions before sharing the account more widely. That is an engineering practice, not evidence that a particular meeting format will make every employee feel safe.
A reported workplace experience shows why a contributor may hesitate. In an August 2026 Reddit account, a person who described working at an insurance brokerage said they raised incorrect AI-generated policy information in a team discussion. After a wider review, they were asked to help prepare reference guidance, but felt guilty about the consequences for colleagues. In a follow-up, they said colleagues viewed them as a snitch. The employer, documents and consequences were not independently verified.
A manager cannot resolve that concern merely by calling the next meeting “blameless.” Explain what the learning discussion is for, who will see its account and how factual corrections can be raised. Keep necessary investigation and personnel processes separate, under the organization's existing responsibilities. Do not promise immunity you cannot provide or turn a learning note into a public ranking of employees.
Give the people involved a chance to correct the factual account before it is shared. If a colleague disputes the description, preserve the unresolved point rather than asking AI to produce a confident compromise. The team-trust guide covers resolving a specific disagreement against the original records.
Remove sensitive detail while keeping the lesson intact
Choose the audience before deciding what to include. A screenshot can expose names, message history, customer details or information in another open panel. Removing a name does not necessarily prevent someone from identifying a person or event from the remaining context.
Google's postmortem workbook offers a useful distinction. In an example shared for wider learning, names and teams were fictionalized and sensitive capacity values replaced with placeholders. Its note distinguishes that version from the detailed record used internally. The principle to adapt is audience-specific disclosure, not an assumption that every document becomes safe after anonymizing names.
For Jamie's announcement case, review each piece of material before sharing it:
| Material | Possible shared version | Condition the lesson must preserve |
|---|---|---|
Original planning sheet | An approved sample with customer and staff identifiers removed | Some courses are confirmed and others remain provisional. |
Incorrect announcement | The relevant excerpt, with identifying details removed | The draft presented a provisional course as available for booking. |
Prompt or instructions | The permitted task wording and relevant settings | Whether the instruction actually required confirmed courses only. |
Investigation record | A restricted reference for authorized reviewers | Unknown cause and unresolved scope are not presented as settled facts. |
Check the shared version with the appropriate information owner. If removing sensitive context makes the example misleading, narrow its audience or prepare a clearly introduced practice case. Keep the original evidence under its existing access rules. Do not copy an entire customer conversation into a new tool merely to summarize it for a lesson.
Show what the proposed change has earned
A lesson needs more than a repair suggestion. For Jamie, the team might propose supplying a checked list of confirmed courses instead of the mixed planning sheet, with instructions to preserve any remaining uncertainty. That is a change to test, not proof that the problem is solved.
Keep the first test small enough to understand. Use permitted sample material with a known expected result, including the condition that was previously missed.
Check the lesson against the work
Recreate the missed condition
Use a permitted sample containing a provisional course. Record whether the current method preserves that status.
Try the proposed change
Use the checked confirmed-course input and revised instructions. Compare the announcement with the expected booking information.
Check a different case
Try another relevant schedule, including missing or changed status. Record remaining errors before agreeing any wider use.
Publish the tested scope
Name the cases checked, the result and what remains untested. Keep an owner for the next correction.
If the revised announcement passes those checks, report that result at that scope. Do not turn it into “the workflow no longer makes mistakes.” If it fails, retain the negative result and the next decision. The credible-pilot guide explains how to assess a broader claim about whether a changed workflow is worth using.
Help the next colleague apply the lesson
Before distributing the note, ask a colleague who was not involved to explain when it applies. Can they identify the provisional-course problem, the current change and the remaining check? If they only remember that AI can be wrong, the account needs a more specific condition or action.
Put the maintained lesson in one place and link to it from the team's discussion or digest. Include a responsible contact and a reason to revisit it, such as changed planning fields, instructions or booking procedures. The use-case library guide explains how to distinguish an idea, a source team's trial and a reviewed reuse.
Count completed follow-through separately from posts. Useful evidence includes someone recognizing the condition in another task, a checked change to the method or an unresolved problem reaching the right owner. The number of embarrassing screenshots shared does not establish any of those outcomes.
Questions about sharing AI failures
Should a near miss be shared if nobody was harmed?
A near miss can be worth sharing when it reveals a condition another colleague could encounter. Say how it was detected and that the work had not yet caused the proposed consequence. For an unsent course announcement, preserve the distinction between a provisional course and a confirmed booking. Use the expected-versus-observed account rather than exaggerating the harm.
Can we share a screenshot of the bad output?
Only share a screenshot when its content and audience are permitted under your organization's rules. Inspect surrounding messages, identifiers and other visible panels, not just the wrong sentence. A reviewed excerpt or sample may explain the lesson with less exposure. Preserve the important task condition using the material-by-material review.
What if we do not know why the AI failed?
Share the observed problem and label the cause as unresolved. Keep the relevant inputs, instructions and output in the appropriate working record so an authorized person can investigate. You can test a practical change without claiming to have proved the root cause. The course-announcement test separates a proposed remedy from its result.
Does a blameless review mean nobody is accountable?
No. A learning review still needs an accurate account, an owner for changes and follow-through. It examines the conditions around the work without using the shared lesson to shame individuals. Necessary investigation and personnel responsibilities continue through their proper processes. Make those boundaries clear before the factual discussion, rather than promising that reporting a mistake has no consequences.
