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

Heads-up, my fellow Android-appreciating animals: Google’s in the midst of rolling out a subtle change to its privacy settings that’s well worth your while to notice.

The change includes a new clause that says the company can use images, files, video, and audio from your interactions with Google Lens, Search, and Gemini Live to train and improve its AI models.

By default, that switch will soon be on and active for your account.

But with about 20 seconds of one-time effort, you can opt out and flip it off (both literally and metaphorically, if you’re so inclined) once and for all.

Lemme show ya how.

[Get level-headed knowledge in your inbox with my free Android Intelligence newsletter. Something new and useful every Friday — from my keyboard to your email.] 

Google’s new AI training privacy default

First things first — the nature of the change: According to Google, starting in the next few days, a new “Search Services History” section within the general Google account settings will lead to a significant-seeming policy shift. As per an email the company sent out to users this week:

Your media [will now be] saved when Search Services History is on. Saved media includes your images, files, audio, and video from your interactions with Search services to help improve your experience. … Your saved media is also used to develop and improve Google services and technologies, including AI models and safety measures.

Riiiiiiiiiiight.

Now, to its credit, Google does say the data will never be associated with your account or identity once it’s used for these purposes, and it’ll rely on “filters” to “automatically remove a broad range of identifying info or sensitive personal information.” But still, whether you’re working with important corporate info or simply put off by the idea of your personal media being fed into the AI training machine, this may be news you aren’t exactly thrilled to hear.

If you’re finding AI increasingly creepy or you’re just not so keen on knowing whatever media you submit to search-related services will be used to train and develop AI for the future, now’s the time to proactively speak up and change your Google account settings to shut down this setup before it begins.

That, unfortunately, is where things get slightly complicated — ’cause for most of us, this new Search Services History section doesn’t seem to be present and available just yet.

But that doesn’t mean you’re plum out of luck.

Your 20-second opt-out roadmap

To start on your AI training opt-out adventure, make sure you’re signed into whatever Google account you rely on for work and/or personal purposes, then head to the Google Activity Controls page and see if you see a section there called “Search Services History.”

If you do, this is especially easy for you: Just use the option right then and there to disable the “Save Media” setting within that section, which will stop any media files from being saved and used without eliminating the entire history of things you’ve searched. (If you’d rather eliminate all of your Google Search history from being saved and used even for your own future discovery and recommendations, you can also opt to turn that entire section off. Just be aware that it may have some wide-reaching effects on the personalization you see across a lot of Google services.)

If you don’t see that section — and, again, that appears to be the case for most of us at this point — you’ve got two options for the moment:

1. You can completely disable all of “Web & App Activity.” Google says if you do this, once your account transitions over to the new approach, all of those “Search Services History” settings will stay off as well. Just be aware that doing so will prevent any and all search history from being saved for you from here on out — which, again, means you won’t be able to revisit your search history yourself and won’t see suggestions and personalization based on past searches throughout Google apps in the future.
2. If you want to avoid entirely eliminating all of your search history, you can for now uncheck the boxes only for “Include voice and audio activity” and “Include Visual Search History.” That’ll stop search-related media from being saved to your Google account for the time being — though I’d also suggest setting yourself a reminder to look back at that same page once a week or so until you see “Search Services History” appear and can confirm that “Save Media” is unchecked as a result of that previous preference. Right now, Google isn’t explicitly saying that such a preference will carry over, so I’d put it on yourself to double-check and make sure (and then make the needed adjustment in the new interface, if not).

The choice is ultimately 100% yours — but in this case, it’s up to you to take action and opt yourself out if you aren’t comfortable with the default. It’s an unfortunate position to be put in, but now you at least know what’s happening and how you can make your own decision to take back control.

Find the tips and tools that’ll *actually* help you with my free Android Intelligence newsletter. No hype, no nonsense — just useful new stuff in your inbox every Friday, from one (alleged) human to another. 

Modern AI systems have evolved beyond the simple chatbots that quickly became popular. Now they use semantic tools to manage workflows and link machines to machines, providing a flexible and effective framework for the next generation of business automation. What you used to build in Microsoft’s Power Platform or construct inside Biztalk is now an agent, built around large language models (LLMs) that can parse both your data and the APIs that you want to use your data with, orchestrating workflows with a level of autonomy that traditional tooling can’t match.

That shift has offered new opportunities, much like those that came with business platforms like Microsoft Dynamics and Salesforce. Here, tools built to solve one set of business problems could be turned into applications that could be sold to other companies. What worked for you to solve one of your problems could now be an added revenue stream, sold through platform marketplaces that helped customers manage installations and customizations.

Agents are business applications now

Modern agents are much like those business applications. Often developed to solve a specific need, but quicky adopted by organizations and refactored to apply enterprise standards (using tools like the Agent Governance Toolkit and frameworks like Microsoft’s Agent Framework), they’re rapidly maturing and are ready to be shared more widely. The process of sharing needs to be curated and controlled, and, if possible, tied to a revenue stream.

There’s certainly some urgency here. Until recently, subsidized tokens have kept costs artificially low. Now companies like GitHub and Anthropic are moving to a more sustainable (for them) pricing model, increasing the cost of inferencing and squeezing companies’ AI budgets. As a result, switching AI projects away from a cost to a revenue source is high on CIOs’ agendas. If those tuned and trained agents can be sold on a marketplace, then that token budget can be justified.

Microsoft has always been a company built on partner relationships, starting with individual developers and working all the way up to the largest software companies and consultancies. That reach is key to helping partners extract as much value as possible from their agents, as it allows Microsoft to integrate its partner sales tools into its own products and services, as well as into other platforms.

Extending the Microsoft Marketplace for AI developers

We’re already familiar with many of Microsoft’s marketplaces, built into individual tools like Teams, into platforms like Microsoft 365 or Visual Studio, or into the Windows Store. Now the company is doing the same for AI developers, extending Microsoft Marketplace to software agents. Announced at Build 2026, the updated Microsoft Marketplace provides ways to publish code—apps and agents—developed across all of Microsoft’s development platforms, including Copilot Studio, opening the marketplace up to traditional and non-traditional developers alike.

Perhaps the most important aspect of this new Marketplace is its own intelligence, using context to expose your code to the right audience. If you’ve developed an agent for use with Microsoft 365, it will be exposed inside the Microsoft 365 Copilot Agent Store; for Visual Studio, in the Visual Studio Marketplace; or for Teams, in the Microsoft Marketplace. All of these are different views on the same back end, using AI to ensure that the relevant agents are displayed.

Replacing search with Intelligent Discovery

This is extended by another new service, Intelligent Discovery, which adds natural language support to search, using AI to infer user intent and highlight the most relevant tools. Building on the familiar metaphor of the search bar, the initial smart search model offers a freeform way to explore the Marketplace. While there are suggested prompts, they’re not necessary. The search tooling allows you to generate comparisons between tools using your own criteria, with the Marketplace AI generating views based on your requirements.

Microsoft’s aim here is to shift discovery from keywords to use cases, so that buyers can quickly get the tools they need without having to evaluate different solutions, before completing a purchase. By handing that aspect of the buying process over to Marketplace’s AIs, customers can go straight to trials or even to buying agents and applications.

For a tool like this to be successful it needs to be trustworthy. By building it on top of the same development frameworks as your agents, Microsoft can take advantage of the AI guardrails built into Microsoft Foundry as well as low-level tooling like the Agent Governance Framework. Restricting the intelligent search to the Marketplace catalogue reduces the risk of hallucination, as output is grounded in Marketplace data and metadata.

A developer-friendly marketplace

Microsoft is providing tooling to help developers get their listings right. According to Cyril Belikoff, Microsoft’s vice president of Commercial Cloud and AI, “We actually have a separate AI tool that we give to software companies to optimize their listings, called a listing optimizer, funny enough, and that listing optimizer reviews their listing and then provides them with particular guidance on how to best improve it, so that it can be best discoverable in today’s search world.”

You can expect the listing optimizer to be tuned to work with the new Marketplace tooling, but for now it still focuses on traditional search. As Marketplace is a B2B platform, there’s a lower risk of spam applications, but even so, Microsoft remains aware of the possibility of a new system being gamed, and will be rolling out Intelligent Discovery carefully, monitoring its performance as more customers get access over time.

Having a new discovery method is one thing; getting quality AI applications in the Marketplace is another. Microsoft is validating all code submitted, though the criteria will differ between target platforms. An agent built for Teams will be treated differently than one built on Microsoft 365’s WorkIQ. It’s an approach that allows Microsoft to support new standards as they become available.

Alongside its agent development tooling, Microsoft is rolling out a new set of guidelines and processes to help developers get ready to sell their agents. Hosted on GitHub, these offer code templates as well as a link to the App Advisor guidance tools.

Still gaps to fill

This first release of Intelligent Discovery is promising, but some key features are missing. With agent token costs an increasing problem for businesses, it would be nice to see tools that help predict costs, integrating with finops tooling. We’re living in an age of shadow AI, and putting the AI we used to buy with credit cards in Microsoft Marketplace is one way to shine a light on those shadows — bringing the necessary control and governance to AI purchases, and maybe even providing support for site licensing.

Microsoft Marketplace is becoming a useful resource for AI application developers. It encompasses the entire development life cycle: offering tools that can help you build agents, the models that you need to power your agents, and finally a way to monetize your work. There’s a longer-term opportunity here, for both the Marketplace and Intelligent Discovery to offer Model Context Protocol (MCP) interfaces, ensuring that tooling and tool discovery become part of the developer workflow, and making developers aware of new tools that might help solve a problem or simplify a task.