Why AI investment needs deployment talent to deliver ROI

In May 2026, some of the largest companies in AI made the same move within days of each other. Anthropic announced an enterprise venture with Blackstone, Hellman & Friedman, and Goldman Sachs, reported by the Wall Street Journal at around $1.5 billion. It was built to embed its engineers and models inside the operations of mid-sized businesses. Days later, OpenAI launched a standalone deployment company backed by roughly $4 billion. Both moves pointed to the same problem of getting AI to work inside a real business. Every company now faces that problem. Most cannot solve it the way the labs can.

A mid-sized company outside those portfolios cannot buy embedded engineering at lab economics. Its realistic routes are open-market consulting at consulting rates, or building the capability through a permanent hire. The labs and their partners are investing heavily in this layer for their own portfolios. For everyone outside those portfolios, the same logic holds with none of the access. That is the case for building it in-house. The return gap is rarely the model. It is the lack of anyone owning deployment.

BCG found that 60% of organisations generate no material value from AI despite continued investment. Use is widespread. The rewiring of workflows that turns use into enterprise-level benefit is not. The spending is real. The return is not following it.

For hiring teams, that points past the tool. A pilot can work in a controlled setting and still fail in a live business. The commercial question is whether the business has the technical ownership to move the work into production and measure it once it is there.

 

Why AI pilots fail between proof of concept and production

Deployment talent means owning whether an AI project lands, end to end. It takes someone with the technical range to work across data, engineering, infrastructure and adoption at once. Most businesses struggling to prove ROI have that range somewhere in the building. They have not made anyone accountable for the whole of it.

A proof of concept can look convincing while sitting a long way from daily use. In a pilot the data is selected, the workflow is narrow, the user group is small and support is close. Those conditions break once the work goes live. Data gets messier. Systems are harder to connect. Security and compliance requirements that the pilot skipped become hard gates. Users need enough trust in the output to change how they work.

S&P Global Market Intelligence surveyed more than 1,000 IT and business leaders across North America and Europe. The share of companies abandoning most of their AI initiatives before production rose from 17% to 42% year on year, and the average organisation scrapped 46% of its proof-of-concept projects before they reached production. Cost, data privacy and security risk were named most often.

The work does not fall cleanly to one team. Data teams own the pipelines, engineering owns the product, IT owns the infrastructure, security owns the risk controls, and the business owns adoption. When responsibility is spread that wide, problems wait between teams while no one owns the resolution.

A pilot proves the use case can work. It says nothing about whether the business can own it once support moves on.

 

What deployment-led engineering looks like

The Forward Deployed Engineer is the clearest role built around that ownership. It matters most in AI companies, where value depends on getting software to work inside complex environments. What an FDE does day to day is covered in our guide on ‘What is a Forward Deployed Engineer’.

For some companies, the exact title will be Forward Deployed Engineer. For others, the same capability may sit under a different label, such as deployment-focused software engineer, technical consultant, solutions architect, machine learning engineer, data engineer or implementation engineer. What matters is the work being owned, not the label on it.

The obvious teams are not resourced to carry it. Product engineers understand the platform but are not staffed for every customer-specific blocker. Solutions engineers sit close to the requirement without always being hands-on enough to fix what lies underneath it. Implementation teams understand rollout while the real problem waits upstream in the data or the architecture.

Google Cloud opened dozens of these roles in May 2026 and signalled hundreds more. The money is going into getting models to work inside real organisations, not only into model access. The largest companies in the sector are now spending to compete on the deployment layer itself.

An FDE works close enough to the product to understand it and close enough to the business to know where it is failing. On an AI project that can mean data access, integration, evaluation, workflow design, infrastructure limits and the practical reasons a tool goes unused. Those problems do not arrive in one place or one order. A project stalls on data access, slows again at a security requirement, then loses momentum because users do not trust the output. One person across all of it removes the handoffs that usually slow the fix.

The hire is defined less by depth in any single layer than by a refusal to hand the problem on at the boundaries between them.

 

When to hire a Forward Deployed Engineer

Four patterns occur between proof of concept and production. Each shows the deployment gap from a different angle.

1. Your product or platform engineers keep getting pulled into customer-specific deployment work.

Some engineering support is expected with complex AI products. The problem starts when product teams become the default route for data access, integration blockers and workflow changes, and roadmap delivery slips as a result.

2. The teams closest to the user keep hitting blockers they cannot resolve.

Solutions engineers, customer success and implementation teams understand what the user is trying to achieve. The difficulty comes when the blocker sits deeper, in the data, the API layer, the cloud setup, the architecture, model performance or security. They understand the issue without the technical scope to fix it, and no one owns the decision about what happens next.

3. A pilot succeeded and nothing changed.

Users may not trust the output, know when to rely on it, or see how it fits the way they already work. That is not always a training issue. Often the deployment was never shaped around the workflow, the data quality and the feedback loops that adoption needs.

4. Customization is becoming too expensive to scale.

If every implementation needs heavy engineering, repeated rework or senior escalation, the cost of delivery weakens the business case. This is where you separate customer-specific problems from product issues and repeatable patterns.

When a blocker reappears between pilot and production and no existing team owns it, the gap is deployment ownership. That is the point to hire.

 

What to screen for in a deployment hire

The strongest candidates have already watched technical work leave the environment it was built in. They have dealt with systems that did not connect, data that was harder to reach than expected, users who needed convincing, and deployments that slowed because ownership was split too widely.

They speak in specifics. They can tell you what they deployed, what had to connect, where the risk sat and how the work changed as it moved towards production. For a company trying to prove ROI, that detail is a stronger signal than broad exposure to AI tools.

Alissa Kapp, Principal Consultant at Glocomms specialising in Forward Deployed Engineering searches, is direct on this. The companies she works with are not looking for polished portfolios. They want to know how a candidate handled something that did not go to plan. Most are fast-moving organisations that need someone who can think under pressure, not someone who has only worked in controlled conditions. The weaker briefs focus too heavily on AI tool exposure. The stronger briefs ask for evidence of judgement, including what broke, who needed to be brought in, what trade-offs were made, and how the candidate moved the work forward.

The interview that works tests for this directly. Public job specs from the major labs weight ambiguity and communication as heavily as code. A candidate who can only describe work that went to plan has not yet done the part of the job that matters most.

Because the role is new, very few candidates carry the exact title, so the strongest hires usually come from adjacent backgrounds. Software engineering, solutions engineering, cloud, DevOps, data, machine learning and technical consulting can all translate. Our guide on 'How to become a Forward Deployed Engineer' sets out how each route maps across.

 

How to build the right hiring brief

Once you know deployment is where projects slow, the brief has to be specific. A general request for AI experience will not tell you whether someone can fix the actual problem.

Start with the title, because it is the one most people get wrong. Forward Deployed Engineer overlaps with solutions engineer, machine learning engineer and technical consultant, and adverts use the labels interchangeably. The distinction that matters is FDE against solutions engineer, which we cover in our guide to the role. A solutions engineer helps sell the product. An FDE makes it work in the client's environment after the deal is signed. Copy a competitor's brief and you often describe a different job.

Then name the work no current team owns. For one company that is enterprise integration. For another it is customer-specific implementation, weak data access, or slow internal adoption. Each needs a different hire.

Be specific on the environment. Name which systems the person will touch, how technical the role is, how close they sit to customers, and whether they will write code, support go-live, or feed issues back to product.

Pay has to match that level. Glocomms salary data puts mid-level base pay at £80,000 to £130,000 in the UK and Europe and $170,000 to $200,000 in the US, rising at senior level and higher again at frontier AI labs. Budget below that and you are usually describing a solutions or implementation role.

Most teams know a project stalled somewhere between pilot and production. The search is the easier half.  Far fewer can say where the problem sits, whether that is data access, a broken integration, a security sign-off that never came, or users who went back to their old process. Each points to a different engineer, which is why a copied brief attracts the wrong shortlist.

This is where the brief needs pressure-testing before the role goes to market. Here at Glocomms we run these searches across AI, software, cloud, data and technical delivery, so we see which deployment problems map to which backgrounds. Tell us the workflow that is not landing and we will benchmark the brief against the right talent pool and shape the search around your problem.

Request a call back to speak with our team today. 

Request a call back

 

Sources

• Anthropic, "Building a new enterprise AI services company with Blackstone, Hellman & Friedman, and Goldman Sachs", May 2026. https://www.anthropic.com/news/enterprise-ai-services-company
• TechCrunch, "Anthropic and OpenAI are both launching joint ventures for enterprise AI services", May 2026. https://techcrunch.com/2026/05/04/anthropic-and-openai-are-both-launching-joint-ventures-for-enterprise-ai-services/
• Boston Consulting Group, "AI Adoption Puzzle: Why Usage Is Up but Impact Is Not", 2025. https://www.bcg.com/publications/2025/ai-adoption-puzzle-why-usage-up-impact-not
• S&P Global Market Intelligence, "Generative AI shows rapid growth but yields mixed results", October 2025. https://www.spglobal.com/market-intelligence/en/news-insights/research/2025/10/generative-ai-shows-rapid-growth-but-yields-mixed-results
• Fast Company, "Google, Box CEOs say this is the 'most in-demand' job in tech", May 2026. https://www.fastcompany.com/91541878/google-box-ceos-say-this-is-the-most-in-demand-job-in-tech
• Glocomms Forward Deployed Engineering salary data (internal).