Ninety percent of AI projects fail behind the scenes: prompt debt, retrieval debt, and evaluation debt are dragging down enterprise deployment

In 2025, 42% of companies are halting multiple AI projects, more than doubling the 17% from the previous year. The issue isn't that models aren't powerful enough, but rather that a new form of technical debt is silently accumulating within enterprise AI infrastructure—prompt debt, retrieval debt, evaluation debt.
(Background: What is Harness Engineering? Breaking down the 7 major engineering modules for AI Agent deployment (AI Governance Engineering))
(Additional context: GPT-5.5 Instant is now available to all users, OpenAI teaches you how to write smarter, more effective prompts)

Table of Contents

Toggle

• Three new types of debt, harder to detect than bugs
• Invisible monitoring gaps
• The solution isn't in the models, but in system design

In 2025, 42% of companies are stopping multiple AI projects, which is one and a half times the previous year's figure. Data from S&P Global Market Intelligence shows that AI failures are not isolated incidents but systemic issues. A study by MIT the same year indicates that 95% of AI pilots never truly enter production or generate measurable business value.

These failures are often attributed to insufficient model capabilities, poor data quality, or unclear ROI. But Vikram, head of Cota Capital, believes the real cause is more covert: a new form of technical debt is quietly accumulating in the prompt layer, model dependency layer, and evaluation layer of AI systems—completely different from traditional code debt, yet equally deadly.

Three new types of debt, harder to detect than bugs

Traditional technical debt exists within codebases; bugs can be reproduced, tested, and fixed. AI debt, by contrast, is fundamentally different: it is distributed across prompts, model APIs, data pipelines, and infrastructure layers.

It is intermittent because AI systems are inherently probabilistic—same input doesn't guarantee the same output; it is almost invisible because the system "appears" to be functioning normally until a critical moment causes a total collapse.

Prompt Debt is the most obvious of the three. It involves temporary adjustments without record, prompt modifications without version control, and "prompt stuffing"—forcing a large amount of irrelevant background information into prompts in an attempt to make models understand more.

The result is that prompts become informal code without types, testing, or version management. Each fine-tuning is performed on an opaque system, and as this accumulates, the system's fragility grows exponentially.

Model Dependency Debt stems from enterprises' heavy reliance on external foundational model APIs. Application logic is built around calling external models, but these models are updated silently without the company's control.

When model providers upgrade versions quietly, prompts carefully tuned for older versions may become invalid, or output behavior may drift unpredictably. Reproducibility is lost.

Retrieval Debt appears in most enterprise AI deployments using RAG (Retrieval-Augmented Generation) architecture. The problem is that data warehouses are often cluttered with disorganized data, duplicate files, and outdated information. As a result, AI responses may technically be correct at the time, but no longer applicable. This is even harder to detect than hallucinations because it looks perfectly reasonable and can pass casual review.

Invisible monitoring gaps

Evaluation Debt is the most underestimated among the four new types of AI debt. Existing AI benchmarks mostly focus on narrow, point-in-time evaluation results, failing to reflect real-world performance after deployment. Most enterprises lack consistent testing standards, benchmark datasets, or real-time monitoring mechanisms for deployed models.

Compared to mature CI/CD (Continuous Integration/Continuous Delivery) processes in traditional software development, AI deployment still lacks an equivalent "prompt continuous integration" system.

In plain terms: when engineers merge code, automated tests tell you where things break; but when prompts are modified, no system provides immediate alerts. As a result, CIOs and CTOs lack visibility into actual model performance and cannot track whether performance is deteriorating.

These four new types of debt compound on top of existing code-related technical debt, accelerating their accumulation. To make matters worse, ownership of AI systems is inherently dispersed: engineering, product, data, and business teams each own different parts, making accountability unclear when issues arise.

The solution isn't in the models, but in system design

Stronger models won't solve this problem. Vikram's argument is straightforward: high failure rates are unrelated to model accuracy; the root cause lies in system design, integration controls, and organizational culture.

Specifically, prompts must be treated as code—version-controlled, documented, and rigorously tested across all configurations before deployment.

Evaluation mechanisms need to be embedded throughout the AI infrastructure stack, establishing continuous assessment pipelines that cover technical metrics and business KPIs, integrated with AI observability systems to monitor output quality, failure rates, model drift, and data drift.

Furthermore, all AI outputs should include explainability by default—source data, models used, steps taken—making them transparent and auditable, enabling quick correction when systemic errors occur.

This requires establishing clear plans and dedicated budgets for AI debt elimination, similar to past investments in cybersecurity or cloud modernization, driven by CXO-level leadership.

After all this, you should now understand: 95% of failures are not due to AI being insufficiently intelligent. Instead, they stem from building AI systems as black-box API calls rather than as complex, engineering-intensive systems. Technical debt never disappears on its own; it only accrues at higher interest, to be paid off at some future point.