The AI Deployment Wars Have Begun

As AI model vendors and consultancies move deeper into implementation, enterprises need to understand who is defining their problem — and whose interests the solution serves.


For the past several years, the major AI companies have competed primarily through their models. Who has the smartest model? The largest context window? The lowest price? The best coding performance?

That competition continues. But a second—and potentially more consequential—battle is now emerging. The major AI vendors are no longer happy to provide models and software platforms. They’re building deployment companies, hiring forward-deployed engineers, funding consulting ecosystems and forming major partnerships with systems integrators and professional-services firms.

This has major implications for everyone: software vendors, companies trying to roll-out AI, consultancies — and potentially for the structure of the enterprise technology market itself.

As the incentives of vendors and consultancies become increasingly entwined, truly independent advice may become harder to find.


What’s been announced?

OpenAI has launched the OpenAI Deployment Company with more than $4 billion of initial investment. Through its acquisition of Tomoro, it began with approximately 150 forward-deployed engineers and deployment specialists. OpenAI has also created a Partner Network backed by a further $150 million, with an ambition to train and enable 300,000 certified consultants by the end of 2026. Its Frontier Alliance includes Accenture, Capgemini, McKinsey, and Boston Consulting Group. The broader partner network includes most of the other major consulting and systems-integration firms.

Meanwhile, Anthropic has announced a new enterprise AI services company with Blackstone, Hellman & Friedman and Goldman Sachs. Anthropic’s applied AI engineers will work alongside the new company to identify opportunities, build solutions and support customers over the long term. They have strong relationships with Accenture, Deloitte, PwC, KPMG, Cognizant, Infosys, and more.

Not to be left out, Microsoft and EY are jointly investing more than $1 billion in an initiative combining Microsoft’s technology and engineering capabilities with EY’s industry and transformation expertise. Its stated purpose is to help organizations move beyond isolated experiments and achieve enterprise-scale value. They also have a historically deep relationship with Accenture, and partnerships with thousands of consultancies.

This is more than an expansion of the AI services market. It is an implicit admission that access to better AI models is not, by itself, producing enough enterprise value.


The model is no longer the principal constraint

AI adoption is already widespread. McKinsey’s 2025 global survey found that 88% of respondents said their organizations were regularly using AI in at least one business function. However, only around one-third reported that their companies had begun scaling AI programs across the enterprise. That gap matters.

Organizations can buy access to powerful models. Employees can use copilots. Innovation teams can create demonstrations. Developers can build impressive prototypes in days. But moving from an interesting prototype to an operational system remains extremely difficult.

Gartner reported in January 2026 that at least half of generative-AI projects had been abandoned after proof of concept, commonly because of poor data quality, inadequate risk controls, escalating costs or unclear business value. I've seen multiple estimates that claim more than 80% of AI projects fail — twice the failure rate of conventional IT projects.

The more revealing problem may not be outright failure, but the large number of pilots that remain technically functional yet never get rolled into production as the value is not truly understood or communicated.

The primary obstacles to enterprise AI are rarely limited to the intelligence of the underlying model. The difficult questions are much broader:


  • What business problem are we actually trying to solve?

  • Is generative AI the right technology, or would optimization, automation, or predictive analytics be more appropriate?

  • Can the necessary data be accessed, understood and governed?

  • Where must humans remain in the loop?

  • How will employees trust and adopt the system?

  • What happens when the underlying model changes?

  • How will we measure economic value and ROI?


These are not model-selection questions. They are organizational, operational, architectural and strategic questions.

The AI vendors have recognized this. Their response is to move downstream and become much more closely involved in deployment.


The case for vendor-led deployment

There are good reasons to welcome this development. The AI vendors understand their own technology better than anyone else. Their engineers know the capabilities, weaknesses, security architecture, tooling and product roadmaps of their platforms. Embedding those specialists alongside customers can shorten the learning cycle considerably.

Vendor deployment teams can also create much clearer accountability. Too many enterprise AI projects become trapped between the model company, the cloud provider, the systems integrator, the software vendor and the customer’s internal technology organization. It is too easy for each party to explain why another part of the ecosystem is responsible for the failure. An integrated deployment model may reduce that fragmentation.

The vendors also see hundreds or thousands of implementations. Over time, they can develop reusable patterns for common problems, industries, integrations and governance requirements. And there is a genuine shortage of people who understand AI technology while also appreciating process design, organizational change, evaluation, risk and business economics.

AI companies moving into deployment may therefore be both inevitable and necessary. But this also raises a more uncomfortable question.


When deployment becomes distribution

A vendor-led deployment organization has several objectives. It wants to make the customer successful. It wants to increase adoption and consumption of its technology. And it wants to make its platform an increasingly important part of the customer’s operations. Those objectives frequently overlap. But they're not identical.

The organization helping an enterprise define its AI strategy may also be the organization selling the technology that the strategy recommends. The deployment team may be deeply capable and entirely sincere. Nevertheless, it is structurally incentivized to see problems through the lens of its own platform.

When the solution is being designed, how likely is a model vendor to conclude that the organization should use less of its model? Realistically, how likely is it to recommend a competitor’s technology, an open-source model, a traditional optimization engine – or no generative AI at all?

Likewise, the preferred implementation partners have little commercial incentive to recommend an architecture that minimizes reliance on the ecosystems through which they receive training, support, referrals and commercial opportunities.

This does not make the advice wrong, necessarily. It does mean the incentives should be understood very clearly.

The truth is that deployment can become a highly effective form of distribution. Once a model is embedded inside workflows, data architectures, operating processes and employee behavior, replacing it becomes much harder.

The ultimate competitive advantage may no longer be owning the best model. It may be owning the customer’s deployment, and critically, influencing how the customer defines the problem itself.


The new “Nobody ever got fired for buying IBM”

For decades, the phrase “Nobody ever got fired for buying IBM” described the personal and organizational safety of selecting the established technology provider. The decision might not produce the most innovative or cost-effective solution. But it was defensible. If the project failed, the executive could argue that the organization had selected a reputable, market-leading vendor. Choosing the familiar provider reduced personal career risk, even if it did not always reduce strategic risk for the company.

We may be approaching an AI version of the same phenomenon.


  1. Choose a leading frontier-model company.

  2. Appoint one of its major consulting or integration partners.

  3. Standardize on the resulting platform.

  4. Commit every business unit to finding use cases.

  5. Then describe the resulting concentration as an enterprise AI strategy.


There are advantages to this approach. Organizations cannot operate effectively with every team independently selecting its own models, tools, security and architecture. Excessive technological optionality can create cost, duplication and chaos.

But there is an important distinction between standardizing after understanding the portfolio of business problems, versus selecting a platform first, then viewing every problem through it. As they say, to the lumberjack, everything looks like a tree.

Choosing a single vendor strategy is especially risky in a market changing as quickly as AI. Models are improving. Costs are shifting. Open-source alternatives are developing. Agent architectures are evolving. New regulatory requirements are emerging. Today’s clear market leader may not remain the best answer for every workload — or even for the same workload a few months from now.


Standardization versus independence

Enterprises do need strategic technology relationships. The answer is not to avoid major vendors, create an unnecessarily complicated multi-model architecture, or insist on theoretical neutrality in every decision.

The goal should be to combine enough standardization to enable scale, with enough independence to continue challenging the strategy. Some use cases will justify deep commitment to a single platform. Others may be better served by specialist models, traditional machine learning, optimization, workflow, human judgment, or no AI at all.

The starting point should therefore be the business problem and the decision being improved, not the technology being promoted. A useful AI strategy should ask:


  • Which business decisions matter most?

  • Where is uncertainty creating cost or lost opportunity?

  • Which workflows are genuinely constrained by a lack of intelligence?

  • Which problems require language-based reasoning, vs math-based optimization?

  • What processes require predictive models?


And perhaps most critically, which processes simply require reliable data, clearer accountability or a better process rather than another technology layer?


The missing role: independent challenge

This is where experienced individuals and independent organizations may become increasingly important. Their role should not be to add another large consulting layer or supervise every technical decision. It should be to provide independent challenge, architectural perspective and value assurance.

Vendor deployment teams are well placed to answer: How can we make our technology work effectively in this organization?

An independent advisor should begin one step earlier: What outcome or decision are we trying to improve, and what combination of technology, process and human judgment is most likely to improve it?

That independent role can challenge assumptions about whether the organization is solving the right problem, and whether AI is actually necessary. The role can help determine if a vendor is being chosen for technical suitability, rather than organizational comfort.

This is not an argument against vendors or their partners. Independent thinking is most valuable when it works alongside deep vendor expertise, not when it tries to replace it.

An independent advisor also helps ensure that the definition of success remains grounded in the customer’s outcomes rather than the provider’s ecosystem. And yet, the growing alliances between large consultancies and major AI vendors are making the choice of a genuinely independent advisor more difficult.


Who will own the problem?

The expansion of AI companies into services and deployment is an understandable, and probably necessary, phase in the market’s development. But the trend also creates a new governance question.

When the model provider, deployment team, preferred systems integrator and strategic advisor all belong to the same commercial ecosystem, who remains responsible for asking whether that ecosystem is the right answer?

The winners in deploying enterprise AI will be the organizations that combine deep vendor capability with independent judgment: standardizing where scale demands it, preserving choice where uncertainty demands it, and evaluating AI by the business decisions it improves rather than the platform they have purchased.

The model wars are not over. But the larger strategic prize for AI is shifting. Whoever owns the deployment may ultimately own the customer’s definition of the problem — and therefore the solution.


Next
Next

If food could talk