Every AI team I have worked with has a graveyard of projects that should have been killed early but were not. A chatbot that no one uses. A recommendation engine that does not outperform a simple heuristic. A forecasting model that requires so much manual data preparation that the manual process it was supposed to replace is faster. Each of these projects consumed months of engineering time, thousands of dollars in compute, and significant political capital. Each of them should have been stopped at the first evidence that the hypothesis was wrong.

The inability to kill AI projects is not a technical problem. It is a cultural problem. AI projects carry a halo of innovation that makes killing them feel like rejecting progress. The people who champion the projects have careers invested in their success. The executives who approved the budgets have reputations staked on the outcomes. The organizations that most need to kill bad projects are the ones least equipped to do so, because every stakeholder has an incentive to keep the project alive.

Why AI projects are harder to kill than regular projects

Three characteristics make AI projects uniquely resistant to termination.

The uncertainty defense. AI projects have inherent uncertainty — model performance is not guaranteed, data quality issues may emerge, deployment may reveal problems that testing did not. This uncertainty is real, and it provides a permanent justification for continued investment. “We just need more data.” “We just need to try a different architecture.” “We just need another training run.” Each request for more time is reasonable in isolation. The cumulative effect is a project that continues long past the point where the evidence supports termination.

The demo effect. AI projects produce demos that look impressive. A chatbot that answers questions correctly in a controlled demo looks functional. The demo does not show the cases where the chatbot hallucinates, the maintenance burden of keeping the knowledge base current, or the user adoption rate. Executives who see the demo form a positive impression that is resistant to subsequent evidence of problems, because the demo created a cognitive anchor that the performance data has to overcome.

The sunk cost escalation. AI projects are expensive, and the expense creates a sunk cost dynamic. “We have already spent $500,000 on this project. We cannot stop now.” The sunk cost fallacy is well-documented in behavioral economics, but it is particularly strong in AI because the expense is concentrated in compute costs that are easy to quantify and hard to justify abandoning.

Criteria for killing a project

I use four criteria, and a project that meets any one of them should be killed or substantially redesigned.

The hypothesis has been disproven. The project was started with a hypothesis: AI will improve this specific decision, reduce this specific cost, or enable this specific capability. After sufficient testing, the hypothesis is not supported. The model does not improve the decision. The cost reduction does not materialize. The capability is not valuable enough to justify the investment. When the hypothesis is disproven, continuing the project is not persistence. It is denial.

The integration cost exceeds the model benefit. The model works in isolation, but integrating it into the production workflow requires so much additional engineering, process change, and stakeholder management that the total cost exceeds the value the model produces. This is the most common reason to kill an AI project, and it is the least commonly acted on, because the model team measures value in model accuracy and the organization measures value in business outcomes.

The maintenance burden is unsustainable. The model requires ongoing data preparation, retraining, monitoring, and debugging that consumes more engineering capacity than the value it produces. This condition often emerges gradually — the initial deployment is low-maintenance, but as data distributions shift, edge cases accumulate, and integration points multiply, the maintenance burden grows. Killing the project when maintenance exceeds value prevents the slow drain of engineering capacity that degrades the team’s ability to work on higher-value projects.

A simpler solution exists. A rule-based system, a statistical model, or a manual process produces comparable results at a fraction of the cost. This is the most politically difficult reason to kill an AI project, because it requires admitting that the simpler solution — which was considered and rejected in favor of the AI project — was the right answer all along. The political difficulty does not change the economic reality. If a spreadsheet produces the same output as the model, the model is a waste of resources.

How to kill a project without killing the culture

Killing projects poorly is as damaging as not killing them at all. If project termination is perceived as punishment — for the team, for the champion, for the idea — then people will avoid proposing projects, hide problems, and inflate results to avoid termination. The goal is to create a culture where killing a project is treated as learning, not failure.

Separate the hypothesis from the team. When you kill a project, kill the hypothesis, not the people. “This hypothesis was not supported by the evidence” is a different message from “your project failed.” The first message preserves the team’s willingness to propose future hypotheses. The second message teaches them to avoid proposing testable hypotheses.

Document the learning. Every killed project should produce a written record of what was tried, what was learned, and what the team would do differently. This record serves two purposes: it ensures the learning is captured rather than lost, and it provides evidence that the organization values learning over blind persistence.

Redirect the resources visibly. When a project is killed, the freed-up resources should be visibly allocated to higher-value work. This demonstrates that killing a project produces a positive outcome — the team gets to work on something more promising — rather than a negative one — the team is disbanded or demoralized.

Create a regular kill review. Establish a quarterly review where every active AI project is evaluated against clear criteria: is the hypothesis still supported, is the integration cost still justified, is the maintenance burden sustainable, has a simpler solution emerged. Making this review routine — rather than a crisis response — normalizes project termination and reduces the political cost of killing a project.

The organizational maturity test

The ability to kill AI projects is a reliable indicator of organizational AI maturity. Immature organizations measure AI success by the number of active projects and the number of models in production. Mature organizations measure AI success by the quality of the projects that survive and the speed with which unpromising projects are terminated.

The provocation: if your AI team has not killed a project in the last six months, you are either exceptionally good at selecting projects or, more likely, you are not killing projects that should be killed. The first possibility is worth verifying. The second is worth addressing.