OpenAI, hyperscalers and SaaS: where do IT services firms genuinely risk disintermediation?

The scenario is tempting: tomorrow, OpenAI would deploy its agents directly at large accounts, Microsoft or AWS would supply the whole platform, SAP, Salesforce or ServiceNow would automate processes from inside their own software, and the IT services firm would get squeezed. Recent moves give this risk some substance. But they don't prove integrators are about to disappear. They show something more precise: competition is shifting toward control of the workflow, the context, the data, and the operational relationship with the client.

The strategic question, then, isn't just: who owns the best model?

It becomes: who's best positioned to understand the work, access the data, make the systems act, measure the result, fix the errors, and stay indispensable once the project is done?

That's where disintermediation plays out.

In brief

• •The disintermediation risk has become tangible. In May 2026, OpenAI announced a Deployment Company meant to work directly inside organisations with Forward Deployed Engineers; in July, the company launched Presence, an offering for deploying agents into operational workflows.
• •But the model alone probably isn't the main defensible edge. Vendors that already own the data, the rights, the interface and the workflow — SAP, Salesforce, ServiceNow, Microsoft — hold a structurally strong position to bolt the agent directly onto where the work happens.
• •That doesn't mean outsourcing is collapsing. In France, Numeum and Xerfi still put the IT services market at €34.6 billion in 2026, growing 1%. In Deloitte's global survey, 80% of the executives surveyed planned to maintain or increase their outsourcing spend, even as insourcing was rising too.
• •The most vulnerable zone is integration with no asset and no accountability of its own: configuring a dominant piece of software, selling resources around its platform, or running a workflow where the vendor already controls the data, the orchestration and the user experience.
• •The best defence isn't building your own LLM. It's owning or mastering the layers the client can't delegate to a single vendor: business context, heterogeneous integration, evals, governance, reversibility, operations, and operational accountability.

The signal has changed: model vendors no longer stay at delivery's doorstep

For a long time, the split in roles seemed fairly legible.

The cloud provider supplied the infrastructure. The vendor supplied the software. The consulting firm advised. The IT services firm integrated, customised, operated and supported the client.

That separation is becoming far less clear-cut.

Technology players are pushing deeper into organisations, software platforms are capturing workflows, and the line between software, integration and consulting is getting porous — a shift reminiscent of Palantir's model with its engineers deployed at clients: technology is no longer simply delivered, it's co-built inside the client's day-to-day operations.

In 2026, OpenAI pushed this logic much further.

In May, the company announced the creation of the OpenAI Deployment Company, majority-controlled by OpenAI. Its stated goal: embed Forward Deployed Engineers inside organisations to identify priority workflows, redesign them around AI, then connect the models to the client's data, tools, controls and business processes. OpenAI also announced plans to acquire Tomoro, bringing around 150 engineers and deployment specialists into this new structure.

The official Forward Deployed Engineer job posting is just as explicit: discovery, technical scoping, system design, building, production deployment, adoption, and measuring the workflow's impact are all part of the role.

Anthropic follows a comparable path. Its Claude Agentic Solutions team hires leads able to own agent deployments on critical processes, all the way from the statement of work to production, defining baselines, KPIs, value, and reusable assets.

What this actually shows

The risk is no longer theoretical: part of the work that historically belonged to the integrator or the technology consulting firm can now be done directly by the model vendor.

It's no longer just selling an API. It can also pick the use case, understand the process, design the architecture, connect the systems, build the agent, put it into production, measure its value, and feed what it learns back into improving its own product.

This is a significant shift in the value chain.

What this doesn't let us claim

It doesn't mean OpenAI or Anthropic are going to replace IT services firms.

OpenAI even offers a particularly interesting counter-example: its Deployment Company explicitly partners with consulting and integration firms, including Bain & Company, Capgemini and McKinsey, and states it wants to work with its ecosystem partners. Presence, too, can be delivered by OpenAI or by certain integrators.

In other words, OpenAI isn't choosing between direct integration and partnerships.

It's doing both.

The real power shift may be here: the IT services firm can keep taking part in delivery while no longer necessarily being its main orchestrator.

The model is just one layer: power mainly plays out in four places

The threat from Big Tech probably doesn't come only from their models, but from their ability to take control of workflows, platforms, and the operational relationship with the client. Recent developments reinforce this reading.

To reason about this properly, four layers need distinguishing.

Maximum disintermediation shows up when the same player climbs several of these layers at once. That's exactly what platforms are now trying to do.

SaaS could be more threatening than the LLM vendor

At first glance, OpenAI naturally draws attention.

Yet in many IT services engagements, the player best placed to absorb value could be the vendor of the system where the work already lives.

Why? Because a model knows language. An ERP potentially knows the orders, the vendors, the invoices, the authorisations, the accounting rules and the approval workflows. A CRM knows the customers, the opportunities, the campaigns, the sales exchanges and the user permissions. An ITSM tool holds the incidents, the CMDB, the assets, the services, the dependencies and the resolution history.

That's a different kind of advantage.

SAP: from software to executable business context

SAP now presents its Joule Agents as able to draw on SAP Business Data Cloud data, the Knowledge Graph, rules and process context to act across applications. The stated goal is end-to-end business-workflow execution, not just text generation.

Salesforce: CRM, data, integration and agents in the same stack

Salesforce positions Agentforce with Data 360 and Customer 360 for context, then MuleSoft to connect agents to external applications, APIs and workflows. The company also runs a partner and integrator ecosystem alongside this.

ServiceNow: agents, workflows and governance built on the CMDB

ServiceNow describes its AI Control Tower as a system able to inventory agents and models, control their access, oversee their performance, and connect them to business services through its CMDB. The stated promise is bringing AI, data, workflows, governance and security together on the same platform.

Microsoft: the agent enters directly into the work environment

Copilot Studio lets you build agents able to act on applications and workflows, and manage their lifecycle, access and consumption. Microsoft is also developing action execution directly from the conversational interface, with no need for the user to switch applications or rebuild their context.

These are descriptions the companies produce themselves. They document their strategy and the capabilities they sell; they aren't independent proof of their actual performance or of how much IT services work they'll succeed in replacing. But the strategic direction is hard to ignore.

Dryve's read

Tomorrow's key asset may be less the model than the point where the agent plugs into the work.

When a vendor already owns the data, the business rules, the user's identity, the permissions, the interface and the workflow, fewer and fewer pieces are missing for it to automate part of the integration around its own product.

This is probably where some historically lucrative IT services engagements become vulnerable.

Not every engagement, though, carries the same risk

Talking about "IT services disintermediation" as one uniform phenomenon would be misleading.

A standard integration engagement on a single platform doesn't have the same profile as an old banking IT system transformation spread across multiple technologies, or a 24/7 operations contract with contractual service-availability commitments.

Four zones can be distinguished.

Zone 1 — High risk: configuration around a dominant platform

The risk is high when the process is fairly standard, the vendor owns most of the data, the connectors already exist, the workflow stays inside its own environment, the agent is supplied by the platform, and customisation needs are shrinking.

In this case, the IT services firm mainly selling configuration days finds itself squeezed between the client and a vendor that's itself trying to simplify its own product's implementation. Its value can be compressed without the whole engagement disappearing.

Zone 2 — Rising risk: the AI project centred on a model vendor

OpenAI and Anthropic show a model vendor can now take on part of the scoping, the build, and the production rollout.

An IT services firm whose pitch is limited to "putting an LLM in the workflow" has little protection, then. Differentiation has to come from elsewhere: sector knowledge, architecture, security, data management, legacy integration, change management, evals, operational accountability.

Zone 3 — Intermediate risk: cloud and agent platforms

AWS Bedrock and AgentCore, Microsoft Copilot Studio and the other hyperscalers increasingly supply the building blocks integrators used to assemble themselves: models, RAG, orchestration, tools, authentication, guardrails, deployment, observability.

This potentially reduces the value of purely technical integration. But it doesn't remove migration, architecture choices, security, FinOps, reversibility, process transformation, connecting heterogeneous systems, or operating the service.

Zone 4 — Lower risk: cross-cutting accountability on a heterogeneous system

The more the context mixes several vendors, legacy systems, several clouds, specific business rules, regulation, production constraints, contractual accountability, and human trade-offs, the harder substitution by a single vendor becomes.

This is historically one of the IT services firm's advantages: making systems work together that nobody else fully owns.

This position isn't unassailable. But it's far more defensible than mere configuration capability.

The available data doesn't show IT services firms disappearing

There's a classic analytical risk: watching tech companies' spectacular initiatives and inferring the state of the market too quickly.

The available figures tell a more nuanced story.

The Numeum-Xerfi Observatory published in July 2026 puts the French IT services market at €34.6 billion, growing 1% over the year. The study also notes strong economic tension: 49% of the firms surveyed cite pricing pressure among their top headwinds, and 58% say they're repositioning, notably through automation and AI. Numeum also estimates AI-linked gains remain hard to convert into margin.

This isn't the picture of a sector disappearing.

It's the picture of a sector where sharing the value is getting harder.

The same pattern shows up in outsourcing. In Deloitte's 2024 global survey of more than 500 executives, 83% already say they use AI in outsourced services. Yet only 25% report a reduction in vendor costs or an improvement in service quality. At the same time, 70% have selectively brought certain scopes back in-house over the previous five years, but 80% still plan to maintain or increase their outsourcing spend.

This coexistence matters a great deal.

Insourcing, automation and outsourcing are all advancing at the same time.

The right question, then, probably isn't: will the client insource or outsource?

It becomes: which capabilities does it need to own, which can it buy, and who should orchestrate the whole thing?

OpenAI itself offers the best counter-example to the total-disintermediation thesis

The OpenAI case deserves to be looked at all the way through.

On one hand, the company is clearly moving up onto integration's traditional turf. It now owns the models, agent products, Forward Deployed Engineers, a deployment structure, and a loop feeding field learnings back into product and research.

This is new competition.

But on the other hand, the same Deployment Company explicitly partners with large consulting and integration firms.

This choice can be read several ways. OpenAI may consider enterprise transformations too vast and too specific to be fully absorbed by one centralised organisation. Partners can bring long-standing relationships, sector expertise, local capacity, change management, existing-system integration, and a far larger delivery force.

The most solid takeaway, then, differs from the replacement thesis: the dominant model may be a reshuffling of the ecosystem around new centres of power.

The IT services firm stays present. But it needs to ask whether it orchestrates the ecosystem, owns a distinctive asset within it, or is simply supplying hands around someone else's platform.

These three positions can produce very different economics.

The real threat: becoming interchangeable before becoming useless

Disintermediation doesn't necessarily take the dramatic form of a client announcing: "we no longer need an IT services firm".

It can be far more gradual.

A vendor supplies more standard components. The number of days needed falls. The client asks for a discount. The IP stays with the platform vendor. The rare skills concentrate there. The IT services firm becomes one of several certified partners able to implement the solution. Then competition mostly comes down to price and capacity.

The intermediary hasn't disappeared. Its rent has.

This is probably the most credible economic risk in the short term.

This shift is already documented in consulting: value is moving from mere access to information and production toward assets, outcomes, run operations, orchestration, and the ability to leave the client with a durable, operating system.

Transposing this to IT services firms leads to the same conclusion: code or configuration alone no longer suffice as defensible assets once a platform can produce a growing share of them.

What Dryve concludes from this: the IT services firm needs to own a scarce layer

An IT services firm becomes vulnerable when it no longer controls any scarce layer between the technology and the client's outcome.

Not the model. Not the data. Not the workflow. Not an asset of its own. Not cross-cutting integration. Not governance. Not the operating relationship. Not accountability for the outcome.

In that situation, margin pressure becomes hard to avoid.

Conversely, several positions remain defensible.

Owning the business context

A generic agent doesn't spontaneously know the informal rules of a bank, a manufacturer, or a public operator. Turning that knowledge into process models, ontologies, evals and reusable assets is a form of intellectual property.

Owning the cross-cutting integration capability

Clients almost never run a single system. Whoever can orchestrate SAP, Salesforce, ServiceNow, Microsoft, AWS, a mainframe, and several in-house applications still holds a clear economic function.

Owning the control layer

The point isn't necessarily building a competing model. It can be mastering which data an agent can access, which tools it can call, who approves what, how its performance is evaluated, how its actions are logged, how to switch models, how to stop or restore the system.

Owning operational accountability

A successful demo isn't worth a service that's up twenty-four hours a day. Operations, incidents, exceptions, cybersecurity, version changes and contractual commitments still make up significant ground for IT services firms and managed services providers.

Owning a trusted relationship independent of vendors

In a multi-model, multi-platform world, the client may also look for a player with no economic incentive to systematically favour its own software. Technological neutrality only has value if it's real: the ability to compare, substitute and orchestrate several vendors.

Five strategic decisions to examine now

Map the revenue exposed to a platform's control

For every major offering, ask: if the vendor automates 50% of standard integration tomorrow, what does the client still need to buy from us?

An answer limited to "change management" or "customisation" probably needs more work.

Move beyond mere certification

Vendor certifications remain useful. But they aren't intellectual property. An IT services firm needs to be able to show what it adds on top of the ecosystem: benchmarks, architecture, assets, evals, security, migration, sector context, a run methodology.

Make assets portable

An agent, an accelerator, or an eval system that only works with one vendor can be commercially useful but strategically fragile. Reversibility needs to become a skill as much as a contract clause.

Bring delivery closer to run

The more the IT services firm stays present in actual operations, the more it accumulates context, incident data, knowledge of the exceptions, and an improvement loop. The operational relationship itself becomes an asset.

Rethink alliances

The goal isn't to fight OpenAI, Microsoft, AWS, SAP or Salesforce alone. It's knowing what you're willing to hand over to them. A healthy alliance should give access to their technology without fully giving up client context, architecture design, value measurement, ownership of specific assets, the executive relationship, and reversibility.

Self-diagnostic: is your IT services firm exposed to disintermediation?

• •Across our five main offerings, do we know precisely how much could be absorbed by the vendor's native features within the next two years?
• •Do we have at least one proprietary asset or expertise the client can't get directly from the platform?
• •Does our commercial relationship exist independently of the vendor's?
• •Can we orchestrate several clouds, models and SaaS products, rather than being locked into a single ecosystem?
• •Are our agents, evals and accelerators portable enough to switch models or vendors?
• •Do we hold business-context knowledge that's genuinely captured and reusable?
• •Does our value continue after go-live, through run operations, observability and continuous improvement?
• •Are we contractually accountable for a result, or are we mainly selling effort?
• •When a vendor launches a native feature that automates part of our delivery, do we have a strategy other than cutting the price?
• •If our main technology partner decided tomorrow to deploy its own engineers directly at our client, could we explain in one sentence why the client would still need us?

The more the "no" answers cluster on the first questions, the more the issue is probably not AI adoption but the IT services firm's strategic positioning.

The conviction

IT services disintermediation isn't mainly a story about smarter models. It's a story about controlling the work chain.

OpenAI can now enter delivery directly. Hyperscalers supply the agent infrastructure, the permissions, and the orchestration. SaaS vendors already own much of the data, the rules, and the interfaces where day-to-day operations happen.

These moves put pressure on engagements that mainly live off the gap between complex software and a client who can't implement it alone.

But they don't remove the need for integration, operations, expertise, transformation, or accountability.

They change the question of differentiation.

Tomorrow's IT services firm will need a clear answer to: which layer of value would the client genuinely lose if it took us out of the equation?

If the answer is "a few certified resources", the risk is high.

If it's "the business context, cross-cutting orchestration, the assets, the governance, and operational accountability", the position is far more solid.