How to Rescue a Failed AI Project Without Repeating the Same Mistakes

One page, blameless, factual: what was promised, what was delivered, what the evidence shows about why. Involve the original team — they know where the bodies are buried — but have someone else write the document, because the authors of a plan are rarely its best critics.

This document is the boundary between the old project and the new one. Without it, the rescue inherits every unexamined assumption that caused the failure.

Choose the single workflow with the clearest user, the best data, and the most measurable outcome. Everything else goes on an explicit "later" list. A rescue that tries to preserve the original scope is not a rescue — it is a continuation.

Define the proof up front: the metric, the baseline, the threshold that means "this works", and the date by which you will know. Credibility with stakeholders is rebuilt by hitting a small, dated target, not by promising a bigger one.

In most failed projects the pipeline is the problem: source data access, document quality, integration into the system where work happens, and the human review step. Repair these first. They are unglamorous and they determine whether anything the model does matters.

Only then revisit the model choice — and start with the simplest configuration that could work on the repaired data path. Teams often discover the "insufficient model" was fine all along.

Treat the rescue as a new project with a new name, a new owner, a new success metric, and a short delivery cadence with visible checkpoints. The psychological reset matters as much as the technical one: stakeholders fund futures, not repairs.

Keep the old system running in its current (possibly manual) state until the new one has proven itself in parallel. Big-bang replacements of failed systems are how rescues become the second failure.