The first wave of enterprise AI failure was simple: organisations didn't start. The second wave is more insidious. Organisations are starting, and failing in new ways that feel like progress. Over-engineering, vendor lock-in, governance theatre, and foundation debt are replacing inaction as the primary failure modes.
What You Need to Know
- The failure patterns have shifted. In 2024, the biggest risk was not starting. In 2025, the biggest risk is starting wrong, building in ways that create technical debt, vendor dependency, and organisational dysfunction that's harder to unwind than inaction.
- Four new failure modes dominate: over-engineering (building for scale before proving value), vendor lock-in (single-provider dependency), governance theatre (policies without practice), and foundation debt (standalone projects that resist integration).
- Most of these failures look like progress from the outside. Teams are busy. Models are in production. Dashboards show usage metrics. But the underlying architecture is fragile, the costs are unsustainable, and the compound value isn't materialising.
- The common thread: enterprises are applying 2024 thinking to a 2025 market. The market has matured enough that the approaches that worked for early experimentation actively harm scaling.
- Every failure mode has a specific, diagnosable symptom and a practical correction. None require starting over. They require changing direction.
54%
of enterprise AI initiatives that reached production in 2024 are now classified as 'underperforming' against original business cases
Source: Forrester, Enterprise AI Performance Review, Q2 2025
The Old Failures (Still Happening)
The original failure modes haven't disappeared. Enterprises still fail by:
- Not starting - waiting for perfect conditions, perfect data, perfect strategy
- Starting with technology - choosing a model before identifying a problem
- Piloting without a path to production - proving value without operationalising it
These are Level 1 failures. If your organisation hasn't deployed AI to production yet, the 2024 analysis still applies. What follows is about the organisations that got past the starting line and ran into a different wall.
The New Failures
1. Over-Engineering: Building for Netflix When You Need a Blog
The symptom: The AI platform took 6 months to build before any capability was delivered. It handles enterprise-grade scale, multi-region deployment, and complex orchestration. The problem: you have 200 users and three use cases.
Why it happens: Technical teams design for the architecture they want, not the architecture they need. AI platform vendors sell enterprise-grade infrastructure that's wildly over-specified for most organisations' actual requirements. The result is 6 months of platform building followed by simple use cases that could have run on a fraction of the infrastructure.
The cost: Time-to-value stretches from months to quarters. The organisation loses patience. The platform team is so invested in the infrastructure that they resist simplification. Meanwhile, business teams are solving problems with ChatGPT and spreadsheets.
The fix: Build the minimum platform through delivering the first capability. Let real use cases drive infrastructure requirements. If your platform can't deliver business value within 12 weeks of starting, it's over-engineered.
The Platform Trap
There's a difference between building a platform and building AI capabilities on a shared foundation. The first delays value. The second delivers value while building the foundation. If your platform team hasn't shipped a business capability yet, they're in the trap.
2. Vendor Lock-In: When Your AI Strategy Is Someone Else's Product Roadmap
The symptom: Every AI capability runs on one provider's models, through one provider's platform, using one provider's tooling. When that provider changes pricing (they will), deprecates a model version (they will), or has a major outage (they will), your entire AI operation is affected.
Why it happens: It's easier to go deep with one vendor than to build abstraction layers. Sales teams offer discounts for commitment. Internal teams develop expertise in one provider's ecosystem and resist adding complexity.
The cost: Pricing vulnerability. AI providers have already demonstrated willingness to change pricing dramatically. Capability constraints: no single provider is best at everything. Strategic dependency: your AI roadmap becomes a function of your vendor's product roadmap.
The fix: Build a multi-model orchestration layer from day one. It costs very little to implement upfront and provides enormous flexibility. Start with one provider if you want, but architect so you can add others without rewriting applications.
3×
average price change (up or down) experienced by enterprises on single-vendor AI contracts within 12 months of signing
Source: Gartner, AI Vendor Contract Analysis, 2025
3. Governance Theatre: Policies Without Practice
The symptom: The organisation has an AI governance framework. It's a 40-page document. It was reviewed by legal. It sits in SharePoint. Nobody follows it because it's disconnected from how AI is actually built and deployed.
Why it happens: Governance is treated as a compliance exercise, not an engineering practice. Legal and risk teams write policies. Engineering teams build AI. The two rarely intersect. The policy says "all AI outputs must be reviewed by a human," but there's no technical mechanism to enforce it, no monitoring to detect violations, and no workflow to manage the review.
The cost: False confidence. Leadership believes AI is governed. In practice, the gap between policy and practice creates risk, exactly the risk governance was supposed to manage. When an incident occurs, the organisation discovers that its governance framework was aspirational, not operational.
The fix: Governance must be embedded in engineering practice. Automated monitoring. Technical enforcement of human review requirements. Audit trails generated by the system, not maintained in spreadsheets. If your governance framework can't be demonstrated in a live system, it's theatre.
4. Foundation Debt: Standalone Projects That Resist Integration
The symptom: The organisation has 5-8 AI capabilities in production. Each was built by a different team or vendor. Each has its own data pipeline, model hosting, governance approach, and technology stack. They share nothing.
Why it happens: Urgency. Each business unit wanted AI quickly, so each built independently. The results were fast, individual capabilities deployed in weeks. But the cost compounds: no shared infrastructure means no compound value. Each new capability takes as long and costs as much as the first.
The cost: The organisation spends more on AI each year with diminishing returns. Integration between capabilities requires custom work. Governance is fragmented and inconsistent. The promise of compound AI value (each capability making the next faster and cheaper) never materialises.
The fix: Consolidation. Identify the 2-3 capabilities with the most shared infrastructure potential. Rebuild them on a shared foundation. Use this foundation for all future capabilities. It's painful. It means admitting that fast-but-fragmented was a strategic error. But the alternative is permanent AI mediocrity.
The Diagnostic
| Failure Mode | Key Symptom | Diagnostic Question |
|---|---|---|
| Over-engineering | Long time to first value | How many weeks from project start to first business capability in production? |
| Vendor lock-in | Single-provider dependency | How long would it take to switch your primary AI model provider? |
| Governance theatre | Policy-practice gap | Can you demonstrate your governance framework in a live system? |
| Foundation debt | No compound acceleration | Is your fourth capability faster and cheaper than your first? |
If you answer "more than 12 weeks," "more than a week," "no," and "no," you have all four failure modes. That's not unusual. It's fixable.
The uncomfortable truth about 2025 AI failures is that they look like success from the outside. Underneath, the architecture is fragile, the costs are escalating, and the compound value that justifies the investment isn't materialising.
Isaac Rolfe
Managing Director
What to Do About It
- Audit honestly. Run the diagnostic above. Accept the results.
- Pick one failure mode to address first. Foundation debt is usually the highest-leverage fix because shared infrastructure enables everything else.
- Don't start over. Consolidation is cheaper than rebuilding. The existing capabilities have value; they just need a shared foundation beneath them.
- Set compound targets. Every new AI capability should be measurably faster and cheaper than the last. If it's not, investigate why.
- We've already invested heavily in a single vendor. Is it too late to diversify?
- No, but it requires deliberate architecture work. Build an orchestration layer that abstracts your current vendor's API. Route all new capabilities through this layer. For existing capabilities, migrate incrementally as you extend or update them. You don't need to switch vendors. You need to be able to switch vendors.
- How do we know if our governance is theatre or operational?
- Ask three questions: (1) Can you show me the audit trail for the last AI decision that affected a customer? (2) What happens technically when an AI output falls below confidence thresholds? (3) When was the last governance-triggered intervention? If any answer is "I'd have to check," your governance needs operational work.
- Is foundation debt fixable without rebuilding everything?
- Yes. The approach is incremental: identify the shared infrastructure that would benefit the most capabilities (usually data pipelines and model orchestration), build that foundation, then migrate existing capabilities onto it as they need maintenance or extension. You don't rebuild. You consolidate.