Failed AI project rescue starts by treating the programme as a governance incident, not a vendor dispute. The board should pause irreversible spend, preserve evidence, name an accountable owner, test whether the use case is still worth saving, and approve only fixes that restore control.
This applies when a pilot has stalled, a production system has lost trust, or a supplier delivery has produced a tool nobody can sign off. It pairs with our AI project rescue service and the evidence review in why AI projects fail, but the first decision belongs to the board: is this work still worth saving?
Key takeaways
- A rescue should begin with containment: freeze the evidence, stop uncontrolled changes, and appoint one accountable owner.
- The board decision is not "can the model be improved?" It is "does the use case still justify recovery under explicit stop criteria?"
- Evidence recovery comes before technical repair. Logs, prompts, data lineage, evaluations, decisions and vendor claims are the raw material of the diagnosis.
- Most failures sit across governance, data, model, process and control layers, so a model-only fix usually misses the defect that caused the stall.
- The board report should show options, evidence, residual risk, spend to date, regulatory touchpoints and a dated decision path.
- If the project is structurally unsalvageable, a clean stop is governance working, not a defeat.
Failed AI project rescue triage in the first 72 hours
The first move is to stop the project changing shape while the diagnosis is being made. Do not let a supplier rerun the demonstration, rewrite prompts, swap data, change thresholds or remove logs before the evidence has been captured. A working model can still be an evidential mess; a clean evidence pack can explain why a model did not work.
The NCSC guide for CEOs responding to cyber incidents is useful by analogy. It treats a serious technical incident as a governance, continuity, communications, legal and board-reporting problem, not only as a technical problem. A failing AI programme in a regulated organisation deserves the same discipline: one Senior Responsible Owner, a cross-functional response group, a record of technical facts translated into board consequences, and a route for decisions under time pressure.
| Triage question | Evidence to capture | Owner | Initial board action |
|---|---|---|---|
| Is any live service, customer, resident, employee or regulated process affected? | Use-case map, live-user count, incident log, complaints, manual overrides | Executive sponsor | Contain the use case, define escalation rules and stop any unmanaged rollout |
| Is personal, sensitive, confidential or regulated data involved? | DPIA, data-flow map, processor terms, access logs, retention position | DPO or data lead | Freeze data handling changes until lawful basis, minimisation and security are clear |
| Can the team explain what success meant at approval? | Original business case, success metric, baseline, board paper, supplier proposal | Programme owner | Continue only if a dated metric and stop condition can be reconstructed |
| Can the defect be localised to one component? | Evaluation results, prompt and model versions, integration logs, user workflow evidence | Technical lead | Approve a bounded recovery sprint only if the component has a hard edge |
| Would recovery breach a legal, ethical or sector boundary? | Legal review, regulator guidance, risk appetite, customer impact analysis | General counsel or risk lead | Stop, or redesign the use case before any rebuild |
The table is deliberately blunt. A project that cannot identify its affected people, data, metric, component and boundary is not ready to be fixed. It is ready to be contained.
Decide whether to stop, continue or contain
RAND's 2024 research report on AI project failure root causes was based on 65 interviews with experienced AI practitioners and identified five recurring causes: the wrong problem, insufficient data, technology-led work, inadequate infrastructure and problems beyond the current capability of AI. For a board, the value of that list is not the taxonomy. It is the decision test.
Stop where the use case was wrong, prohibited, disproportionate or dependent on data the organisation does not have and cannot lawfully obtain. Do not relabel that as a delivery problem. The governance decision is to close the project, record what was learned, and prevent the same approval pattern recurring.
Continue under containment where the problem is still worth solving but the approval basis has failed. That means no expansion, no additional supplier commitment and no live-user increase until a fresh metric, owner, risk assessment and control set are approved.
Recover where the defect is bounded: a document pipeline that cannot cite its sources, a classifier that needs a confidence floor, a workflow that lacks human approval, or an integration that failed because no one mapped the operational process. The project may still be worth saving, but only as a smaller piece of work with new evidence requirements.
The board should ask for three options in writing: stop now, continue in containment, or recover one component. Each option should carry the cost to date, the next cost, the risk to users or customers, the evidence gap, and the decision date when the option expires.
Recover the evidence before changing the system
Evidence recovery is not administrative tidying. It decides whether the board is looking at a failed model, a failed process or a failed approval. The minimum pack is practical:
- The original board paper, business case, supplier proposal and approval conditions.
- The intended users, affected people and regulated processes.
- The data-flow map, DPIA, access permissions, retention position and processor terms.
- The prompts, model versions, evaluation datasets, test results, thresholds and known limitations.
- The integration logs, exception logs, manual overrides and user feedback.
- The decision trail: who accepted risk, who approved live use, who paused or escalated issues.
The ICO's guidance on AI and data protection covers accountability, transparency, lawfulness, accuracy, fairness, security, data minimisation and individual rights. It is also explicit that the guidance is under review following the Data (Use and Access) Act coming into law on 19 June 2025, so a rescue pack should date its data-protection assumptions and not treat an old DPIA as permanently settled.
The evidence pack should separate fact from interpretation. "The model produced unsupported summaries in 17 test cases" is a fact if the test cases exist. "The supplier failed" is a conclusion. Boards need both, but not mixed together.
Map defects to governance, data, model, process and control
A common mistake is to fold every issue into "model performance". That hides the repair path. The GOV.UK AI Playbook is written for government, but its principles translate cleanly into regulated board work: know AI's limitations, use it lawfully and responsibly, keep meaningful human control, manage the full life cycle, choose the right tool and put assurance in place. The NIST AI RMF Playbook gives a second lens through Govern, Map, Measure and Manage. The UK's AI regulation response adds the local regulatory language: safety and security, transparency and explainability, fairness, accountability and governance, contestability and redress.
| Defect layer | What the rescue tests | Framework mapping | Board-level fix |
|---|---|---|---|
| Governance | Owner, risk appetite, success metric, stop criteria, board approval basis | UK accountability and governance; NIST Govern | Name the owner, approve the metric, set the stop date and record the risk appetite |
| Data | Lawful basis, minimisation, quality, lineage, permissions, retention | ICO data protection duties; NIST Map and Measure | Rebuild the data pack before changing the model |
| Model | Fitness for the task, accuracy, hallucination risk, bias, drift, confidence thresholds | AI Playbook testing and monitoring; NIST Measure | Define tests the model must pass and when a person must intervene |
| Process | Workflow fit, user adoption, escalation, handover, exception handling | RAND workflow and problem-definition causes; AI Playbook life-cycle discipline | Redesign the work around the user and the regulated decision point |
| Control | Audit trail, human approval, disclosure, incident response, user redress | UK transparency, contestability and redress; NIST Manage | Build the control into the system, not into the post-mortem |
The board should resist a single green status for the whole programme. A project can be technically promising and legally under-evidenced. It can be lawful but operationally unusable. It can work in a demonstration and fail the human-review pattern. The report should show each layer separately.
Report the rescue as a board decision, not a technical update
The board paper should not read like a sprint note. It should read like a decision record. A chair should be able to see what happened, what is known, what is still unknown, what options exist, and what authority the board is being asked to grant.
Use this pack as the minimum board report:
- Current position: what was approved, what was built, where it stalled, and whether any live process is affected.
- Evidence recovered: which logs, data records, evaluations, approvals and user feedback have been secured.
- Root-cause view: governance, data, model, process and control defects, with confidence in each finding.
- Stop, contain or recover options: cost, risk, benefit, timebox and expiry date for each.
- Regulatory touchpoints: data protection, security, equality, sector rules, contractual terms and any reporting duties.
- Decision requested: the owner, metric, budget limit, stop criteria and next board reporting date.
Common mistakes are easy to spot. The first is letting the vendor run a fresh demo before the original evidence is frozen. The second is defining success as accuracy alone, when the real issue is legal basis, workflow fit or human accountability. The third is bringing the DPO, CISO, legal team or risk lead in as late reviewers, after the design has already failed. The fourth is keeping the pilot alive because no one wants the reputational discomfort of stopping it. The fifth is reporting activity as progress.
Activity is not recovery. A recovery has a dated decision, a named owner and an evidence threshold that can close the work.
Next step: route the work to the right intervention
If the project has already failed or stalled, start with AI Project Rescue. The offer is deliberately narrow: diagnose why it failed, scope one component, rebuild it against an agreed success metric, then decide. That structure is suitable when the board needs a fast stop, contain or recover decision.
If the symptom is wider than one project, route the work to the GovernIQ Diagnostic. That is the better path where the organisation has several pilots, unclear ownership, no common approval route, weak evidence records or uncertainty about how its current controls map to AI risk.
For the wider failure pattern, read why AI projects fail. For the control standard we expect in our own work, see how we hold ourselves to account and the broader services offer.
Last reviewed: 18 June 2026.
Sources: GOV.UK AI Playbook · UK government AI regulation response · ICO AI and data protection guidance · NIST AI RMF Playbook · NCSC CEO guide to cyber incidents · RAND AI project failure root causes
