Responsible AI Practice4 min read

Report an AI Failure So Someone Else Can Reproduce It

“The AI got it wrong” is not a usable report. Capture five safe fields before changing the session so another person can reproduce, contain and learn from the failure.

Bokili EditorialPublished October 17, 2026· Verified October 17, 2026

Five evidence fragments form a reproducible AI failure packet that another reviewer can replay safely

“The AI got it wrong” is not an actionable failure report. It gives the next person no reliable way to repeat the task, compare the output with the expected standard, or decide whether the workflow should pause. By the time someone asks for detail, the reporter may already have changed the prompt, started a new session or lost the exact output.

A useful report does not need a long incident form. It needs a small, safe packet of evidence captured at the moment the problem appears. The goal is not to prove that an AI system is always wrong. It is to make one observed failure reproducible enough for a colleague to investigate, contain and learn from it.

Capture the failure before you repair the prompt

Start with the work, not the model. Record what the person was trying to produce or decide, which standard the result had to meet, and what actually went wrong. Preserve only the minimum evidence needed. Replace personal, confidential or commercially sensitive data with redacted or synthetic examples before sharing the packet.

NIST’s AI RMF Measure guidance links documentation with repeatability and calls for testing near-miss conditions, auditability and incident-reporting mechanisms. Its Manage guidance also treats unexpected behaviour, near misses and failures as signals to monitor and document. The UK AI Risk Management Toolkit similarly connects reporting, monitoring, incident response and staff training. Together, these practices point to a simple operating rule: make the observation repeatable before the evidence disappears.

The five-field reproducible failure packet

1. Task and decision

State the exact action the person asked the system to perform and how the output would be used. “Summarise policy for a customer reply” is more useful than “write an email.”

2. Safe input conditions

Record the input type, relevant template or context, tool or model, and date. Redact sensitive material or build a synthetic equivalent that keeps the failure condition.

3. Expected standard

Name the rule, checklist, source passage or acceptance test the output had to satisfy. This gives the reviewer something concrete to compare against.

4. Observed failure

Capture the exact omission, contradiction, unsupported claim or unsafe behaviour. Keep a short output excerpt when policy allows.

5. Impact and containment

Note who saw the output, what consequence was possible, and the immediate action: pause, remove, correct, restrict or escalate.

Worked example: a missing cancellation condition

Imagine a customer-service team asks an approved AI tool to summarise a refund policy for a reply. The draft sounds clear, but it omits a 14-day cancellation condition that changes the answer. The first report says only, “Bad summary—AI missed the rule.” That description cannot show whether the source, prompt, policy version or review step caused the problem.

A reproducible packet records the task, the policy version and relevant section, the redacted shape of the customer question, the expected checklist item, and the exact omission. It also notes that the draft had not yet been sent and that automatic sending was paused while the team checked similar replies. A reviewer can now replay the task with safe data, see whether the omission recurs, and choose a proportionate response.

Reading is a start. Practice makes it stick.

Start learning

	Vague report	Reproducible packet
Task	“The AI wrote a bad reply”	Summarise policy version 3.2 for a customer reply
Expectation	Assumed to be obvious	Include every condition on the approved reply checklist
Failure	“It was wrong”	The 14-day cancellation condition was omitted
Evidence	Changed prompt or missing session	Redacted input shape, output excerpt, tool and date
Action	Try again	Pause auto-send, review similar drafts, assign an owner

Reproduce once, then route by consequence

One controlled replay can be enough to confirm that the packet is usable. Do not repeatedly expose sensitive data or turn a live production workflow into an experiment. If the failure could affect people, money, access, legal rights, safety or a regulated decision, stop the affected use and follow the organisation’s incident route. A reproducible packet supports that process; it does not replace it.

A safe reporting sequence

1
Stop and preserve
Pause the affected action and save the minimum permitted evidence before editing the prompt or session.
2
Sanitise the evidence
Remove personal, confidential and commercially sensitive details. Use a synthetic example when it can preserve the failure condition.
3
Write the five fields
Describe the task, safe input conditions, expected standard, observed failure, and impact or containment.
4
Replay once
If the use is low risk and policy allows, repeat the task with safe data to check whether another person can observe the same problem.
5
Route and close the loop
Send the packet to the right owner, record the decision, and tell affected users what changed before the workflow resumes.

Turn a report into shared learning

The packet is most valuable when it changes the system around the work. A recurring omission may justify a new acceptance test. A boundary case may belong in an exception library. A meaningful incident may require a verified timeline and a rehearsal of the failed human decision. Link the evidence to the action instead of filing it as an isolated complaint.

Write one packet in ten minutes

Choose a recent low-risk AI output that failed a clear check.
Write the task and the decision the output was meant to support.
Replace sensitive input with a redacted description or synthetic equivalent.
Name the expected standard and quote the smallest useful failure excerpt.
Add the immediate containment action and the owner who must decide what happens next.

A failure report should make the next safe action easier. Five concrete fields are enough to move a team from frustration to evidence: reproduce what happened, contain what matters, and feed the lesson back into training, checks and workflow design.