The Consulting Industry's Fingerprints on AI Implementation Failures

In the spring of 2024, a global consumer goods company hired one of the Big Four consulting firms to design and implement an AI-powered demand forecasting system. The engagement was scoped at $14 million over eighteen months. Twelve months in, the system was running in a staging environment against historical data. Two months after that, the consulting firm rotated its lead partner to another engagement. Eight months later, the consumer goods company hired a boutique ML engineering firm to rebuild the system from scratch.

The consulting firm’s final report described the engagement as “Phase 1 complete, foundation established for production deployment.” The client’s internal post-mortem described the same period as “eighteen months of learning what doesn’t work.”

This story is not a scandal. It is not particularly unusual. It is what happens when an industry built around selling strategic advice attempts to deliver operational technology, and the structural reasons why this keeps happening deserve more honest examination than they typically receive.

The Business Model of Consulting AI Work

To understand why consulting firms produce AI implementations of inconsistent quality, you first need to understand what consulting firms actually sell.

Related reading

The core product of a McKinsey, Deloitte, or Accenture engagement is not a working system. It is strategic insight, process design, organizational change management, and risk absorption. The client pays the consulting firm partly for the deliverable and partly for the political cover: if the initiative fails, you can say you hired the best. If it succeeds, you can say the consulting firm validated your approach.

This model has worked well for decades in contexts where “success” means a strategic recommendation, a process redesign, or an organizational restructuring. These deliverables can be fully specified upfront, delivered in a bounded timeframe, and judged at a fixed endpoint. The consulting firm produces a report; you either agree with it or you don’t.

AI implementation does not work this way. Building and deploying an AI system is an iterative, empirical process. You form hypotheses, test them against real data, discover that your hypotheses were wrong in specific ways, revise, test again. The path from problem definition to working production system is not a straight line and cannot be planned in full at the beginning of an engagement. This is not a failure of planning sophistication — it is inherent to the nature of the work.

Consulting firms have tried to adapt their model to accommodate this. The adaptation has been mostly cosmetic: agile-ish delivery structures, “sprint” language in presentations, “fail fast” principles in playbooks. But the underlying incentive structure — where the firm’s revenue comes from staffing a large team at high day rates across a multi-month engagement — does not change. The incentive is not to reach a working production system as efficiently as possible. The incentive is to staff as many consultants as can be justified for as long as the client will approve.

The Knowledge Gradient Problem

Beyond incentives, consulting firms face a genuine knowledge gap that is particularly acute in AI work.

Senior partners at major consulting firms understand AI strategy. They have read the research. They attend the conferences. They can give a coherent presentation on foundation model capabilities, enterprise AI trends, and the ROI case for AI investment. This knowledge is real and sometimes genuinely valuable.

What senior partners at major consulting firms typically do not have is the ability to build a production ML system — to architect a data pipeline, select an embedding model, tune a retrieval-augmented generation system, set up proper evaluation harnesses, design for observability, and handle the specific failure modes of a system running against live enterprise data. This requires a different kind of expertise, built through years of doing the work rather than advising on it.

The mismatch gets delivered to clients through staffing. The senior partner who sold the engagement and understands the strategy is present at kickoff and appears at steering committee meetings. The day-to-day work is staffed by consultants who are, on average, two to four years out of school, technically capable in a general sense, and working from internal playbooks that were written for the previous generation of enterprise software projects.

Related reading

This creates a characteristic pattern in consulting-led AI implementations: strong strategic design, thorough process mapping, well-formatted documentation, and technical execution that is either mediocre (when staffed with generalists trying to do specialist work) or decent-but-misaligned (when the firm brought in a technically strong team but did not connect their work to the strategic vision at the top).

The Role Overlap Problem

Consulting firms also create a specific kind of organizational confusion that makes it harder for client engineering teams to do their jobs.

When a large consulting engagement is running inside an enterprise, the client’s internal IT and engineering teams are simultaneously responsible for the same systems and not quite responsible. The consultants are running the project. The internal teams are supposed to transfer knowledge from the consultants. The consultants are supposed to deliver “to” the internal teams but are also responsible for achieving the engagement milestones.

The result is that critical architectural decisions are often made by the consulting team without the depth of input from the internal team that would be required for the internal team to actually own the system afterward. The internal engineers are present but not driving. When the engagement ends, they inherit a system whose design choices they partially understand and partly resent, built on top of dependencies they did not choose.

The knowledge transfer at the end of an engagement is typically the weakest part of it — budgeted as two to four weeks, executed hastily as the client’s attention is already moving to the next project, and documented in presentations that describe what the system does but not why specific choices were made or how to debug the problems that will inevitably arise.

What Actually Works

The enterprise AI deployments that successfully used consulting support did so by treating consultants as advisors and accelerators rather than as builders and owners.

The operational model that works looks something like this: bring in a consulting firm to help define the problem scope, design the evaluation framework, and map the organizational change requirements. Bring in a specialized AI engineering firm (or build internal capacity) to actually build the system. Keep both accountable to the internal team that will own the system in production. Require knowledge transfer to be continuous throughout the engagement, not a checkpoint at the end.

This model is less comfortable for consulting firms because it limits their staffing footprint on the technical work. It is also less comfortable for clients because it requires them to have (or develop) genuine internal AI engineering capability rather than outsourcing the technical judgment entirely.

Related reading

The most honest assessment of the consulting industry’s role in enterprise AI is that it has been better at creating the organizational conditions for AI adoption — executive alignment, process mapping, change management — than at building the systems themselves. That is not nothing. The organizational readiness work is real and often undervalued. The problem is that it was sold as a complete package that included successful deployment, and that promise was overdrawn.

The consulting firms are not uniquely culpable. They responded to client demand and their own incentive structures in entirely predictable ways. The enterprises that hired them knew, at some level, that they were hiring strategic advisors who would staff the technical work with generalists. The pretense that this would produce production-quality AI systems was a collective one.

What has changed since 2025 is that more enterprises have now been through the cycle and have the scar tissue to ask better questions at the start. The RFP for the next AI engagement, at the more sophisticated enterprises, looks very different from the one three years ago. More questions about specific technical experience. More requirements for references from clients with production systems rather than clients with pilots. More attention to who, specifically, will be doing the hands-on technical work.

That is genuine progress. It came at considerable cost.