When it comes to AI deployments, IT leaders are often caught in an awkward middle space, trying to reconcile conflicting directives from senior management with constantly changing AI models, capabilities, and costs; data governance and security needs; and the limitations of their own team.
“Very few real benefits can be attained by simply purchasing an AI product and giving it to employees. Vendors have been overselling that fallacy for the past three years,” said Nader Henein, a Gartner VP analyst.
“The reality is that strong AI value and consistent ROI are almost always a result of deep and intentional integration of AI capabilities into existing workflows. For that you need specialized teams, which do not come cheap, and organizations have been recruiting those teams in a variety of ways,” Heinen said.
Among the options available to IT leaders looking for help with AI deployments are traditional IT consultancies, AI-specific consultancies, and independent contractors. Large enterprises with deep pockets can consider acquiring an AI firm and integrating its technology and expert staff. The use of open source to reduce vendor lock-in is a strategy that can sit on top of those others, an approach that Capital One has used.
But the option that has been getting the most attention recently is bringing in forward-deployed engineers (FDEs), teams of experts from AI vendors that embed with a customer’s in-house engineers to oversee AI rollouts within the enterprise environment. Both OpenAI and Anthropic have recently announced FDE offerings, for example, and Microsoft is partnering with consulting giant EY in a new FDE program for agentic AI deployments.
Engineering teams employed by AI vendors have key strengths, such as understanding their models better than anyone else, having experience integrating those models into different types of enterprise environments, and knowing about upcoming model capabilities before they’re announced. But they also have the obvious drawback of vendor lock-in. Even if future rollouts are not within their contracted deliverables, those vendor employees could subtly influence a client’s future AI efforts.
Flavio Villanustre, CISO for LexisNexis Risk Solutions, cautions IT executives to move into FDE programs carefully.
FDEs “are financially incentivized to grow customers’ use of a vendor’s AI products and to create stickiness with that vendor’s services,” he said. “While FDEs may be a reasonable value-added service by the AI vendor, customers should always find other unbiased expert opinions that can evaluate competitive solutions across multiple vendors.”
This is particularly important at a time when “investor-subsidized AI token business models are starting to show cracks,” Villanustre said. “Also, in the current rapid pace of innovation in this field where AI vendors are constantly leapfrogging each other, retaining the agility to move from one vendor to the next could create significant competitive advantages.”
Analysts, consultants, and other industry experts who spoke with Computerworld about FDEs echoed Villanustre’s caution, citing concerns around hidden costs, confidentiality, observability, and vendor lock-in.
Long-term costs and vendor lock-in
A key issue that IT executives need to consider is how long the FDE teams will be needed. The enterprise will likely need an ongoing series of AI deployments synced with the current AI model(s). If help is needed today, why would that change tomorrow?
Enterprises tend to overlook those longer-term costs, said John Sangyeob Kim, an AI engineer at software development vendor Solidroad.
“Deployment is maybe 20% of the total cost. The other 80% is keeping the system running through model upgrades, data drift, and edge cases that only appear after months in production,” Kim said. “Most contracts price the first part and assume the rest. Deployment isn’t the hard part of enterprise AI anymore. The next eighteen months are.”
And whether it’s intentional or not, FDEs will naturally favor their own product portfolio — it’s what they know best.
“FDEs from model labs are good at making their own models work in your environment. They are less suited for multi-model systems, because their incentive is to keep you inside their ecosystem,” Kim said.
Sanchit Vir Gogia, chief analyst at Greyhound Research, said IT leaders should look at the FDE model as a strategy involving ongoing operational power.
“Whoever shapes the deployment pattern shapes the enterprise’s future muscle memory. Whoever owns the evaluation layer owns the truth layer. Whoever controls the integration logic controls the dependency map,” Gogia said. “This is why the FDE model matters. It is not just another delivery option. It is the frontier AI vendor moving closer to the customer’s workflow, operating model, and decision architecture.”
That proximity cuts both ways, Gogia noted. “FDEs are embedded inside the customer’s [environment], but they are also connected to the vendor’s commercial center of gravity. Their instinct will be to build around the model family, tooling assumptions, deployment patterns, and product roadmap they know best. This is perfectly natural. It is also precisely why CIOs must be cautious,” he said.
Allowing AI vendor employees an outsized say in enterprise deployment decisions could lock in model vendor dependency, which in turn will fuel high prices that can’t be fought effectively.
“FDEs can accelerate deployment and deepen dependency at the same time,” Gogia said. “Frontier AI vendors are no longer content to sell access to models. They increasingly want to shape how enterprises deploy intelligence. That is a larger prize.”
What happens when the FDE team leaves?
FDE post-departure risks are severe and often underappreciated, according to Justin Greis, CEO of consulting firm Acceligence and former head of the North American cybersecurity practice at McKinsey.
For one thing, the FDE team learns a massive number of operational details from the enterprise deployment. Although NDAs and confidentiality contracts protect any data accessed, they often don’t regulate observed processes and procedures.
“The learnings are absolutely going to be taken from client to client,” Greis said. “Whoever helps deploy AI will learn far more than what appears in the statement of work. They will learn the real workflows, the undocumented exceptions, the data-quality gaps, the approval bottlenecks, the security workarounds, and the places where the business depends on a few people knowing what to do when the process breaks. That knowledge may be as sensitive and precious as the data itself.”
Another critical but often overlooked issue is how much meaningful control will IT have over the project if and when the FDE team leaves.
“The danger is not using outside help. Most companies will need outside help,” Greis said. “The danger is using outside help in a way that leaves the enterprise less capable and more dependent when the engagement is over.”
It is precisely those operational decisions that IT often neglects, said Solidroad’s Kim.
“The best predictor of success is not the vendor. It is whether one internal engineer truly understands the system before the implementer leaves. What matters is who owns the evaluation loop after the demo,” Kim said.
“What happens to our prompts, scorers, and guardrails when the model version changes? If we paused this engagement tomorrow, what would actually stop working, by design or by accident?” Kim asked. “Where do you want the enterprise’s AI learning, control, and dependency to live after the engagement is over?”
Kim argues that observability — the ability to understand and manage all elements of a complex enterprise environment — is a critical function to which IT often gives insufficient attention. Determining whether the project uses the enterprise’s observability stack or the vendor’s observability stack is crucial.
“If the implementer is using their observability stack, that is fine during the build, but you need a plan to migrate it to something you own before they leave; otherwise the visibility walks out of the door with them,” Kim said. “If they are using yours, that is the best case. It means they are working inside the system your team will operate long-term.”
A major problem crops up when they are using neither the enterprise’s nor the vendor’s observability stack. “Neither means they are building the system without any production observability layer at all, and you inherit a system you cannot see into. The first time something breaks in production, you have no traces, no failure history, and no way to tell whether the issue is a model regression, a data problem, or a code bug,” Kim said.
“If observability was not a priority during the build, evals and regression testing usually weren’t either, so you are inheriting a system you cannot measure and cannot safely change. That’s the worst possible handoff position,” he said.
Weighing the alternatives
While the FDE approach is not new, it is just now beginning a surge in popularity, and there are a finite number of such specialists available. That means not all companies even have the option of using FDEs.
This availability disconnect is especially prominent for non-US deployments, where on-site FDEs are rarer, said Gartner’s Henein. “Where is the development happening? There may not be FDEs available in that region,” he said.
There are plenty of other places enterprises can turn to for AI help. Ishraq Khan, CEO of coding productivity tool vendor Kodezi, encourages IT executives to consider a wide range of options but notes that all approaches have major drawbacks.
“Traditional consultancies are usually stronger at governance, process, compliance, and organizational coordination. They know how large enterprises operate politically and structurally. The downside is that many move slower and often lack deep frontier AI specialization,” Khan said.
Gogia from Greyhound Research put it more colorfully: Traditional IT consulting firms “know how to get legal, risk, security, finance, HR, and business units into the same room without anybody setting fire to the carpet. For regulated enterprises, that matters,” he said.
Specialized AI consultancies have a different set of strengths, Khan said. “AI-native consultancies move much faster and are often more technically current, but many are still immature operationally. Some can build impressive demos without fully understanding long-term maintainability, governance, or production reliability.”
Greis from Acceligence commented on two other options for bringing in outside AI help. Using an independent contractor “can be great for eval design, architecture reviews, red teaming, agent design, or getting a stalled team unstuck,” he said, but it can increase the risk of “key-person dependency,” where a single external person is the only one who understands the system.
As for purchasing an AI firm and onboarding its employees, a practice known as “acquihiring,” Greis said it can work well when the AI capability and expertise being brought in are truly strategic for the acquiring enterprise. But there is a risk that the acquired team will be smothered by the parent company’s bureaucracy: “You buy a speedboat, bolt it to an aircraft carrier, and then wonder why it stopped moving,” he said.
Finally, an open-source strategy can give companies flexibility and reduce vendor dependence, but “many companies underestimate the operational burden that comes with it,” Kodezi’s Khan said. “Open source only helps if the organization has the internal talent and discipline to maintain it properly.”
Bottom line: enterprises need to define their true objectives before deciding on an approach. Khan offered several key questions for CIOs to consider: “Who owns the deployment after implementation? Can we move providers later without rebuilding everything? What happens if the vendor relationship changes or disappears? Are we optimizing for short-term deployment speed or long-term operational resilience?”
In any scenario where outside firms have direct access to enterprise systems, IT needs to be kept fully in the loop. “The worst outcome is when an enterprise successfully deploys AI but no longer fully understands how its own systems operate underneath,” Khan said.
External help for AI deployments: 6 options
| Pros | Cons | |
| AI vendor FDEs | + Best expertise on the main model being used | – Vendor lock-in – Operational detail leaks |
| Traditional IT consultancies | + Best understanding of change management, legacy integration, global rollout, governance, and operating-model redesign | – Can be too slow, too expensive, or too generic |
| AI consulting firms | + More practical AI deployment experience than traditional consultants + Less vendor lock-in than model-provider FDEs | – May not sufficiently understand enterprise-grade requirements: security, identity, auditability, compliance, incident response, cost controls, and long-term maintainability |
| Independent contractors | + Useful for precision tasks: eval design, architecture reviews, red teaming, agent design, or getting a stalled team unstuck | – Risk of ‘key-person dependency’ |
| ‘Acquihiring’ an AI firm | + Works when the acquired capability is truly strategic | – Acquired team can be smothered inside existing bureaucracy |
| Deploying open-source products | + Reduces dependency on one model vendor + Attractive for data sovereignty, control over enterprise systems, cost efficiencies, and regulated environments | – Enterprise takes on full responsibility for security, patching, evaluation, deployment, monitoring, and lifecycle management |
Related reading:
- Here’s one career emerging from the AI shift: ‘forward-deployed engineers’
- The forward-deployed engineer: Why talent, not technology, is the true bottleneck for enterprise AI
- The new AI lock-in
