❌

Normal view

Microsoft CEO Satya Nadella says you’re paying for AI twice — the second price is worse

Abstract digital illustration of intense neon red and purple glowing bars under compression against a dark black background.

Microsoft Chairman and CEO Satya Nadella took to the internet to share his thoughts about the hidden cost of enterprise AI.

In a lengthy post on X (formerly Twitter) on Sunday, Nadella describes the problem as a “reverse information paradox,” arguing that AI flips Nobel Prize-winning economist Kenneth Arrow’s classic information paradox on its head.

Arrow’s paradox focused on the seller’s dilemma of how to demonstrate the value of information without disclosing it. Nadella argues enterprise AI shifts that burden to the buyer, who must share proprietary processes and institutional expertise to get the strongest results from a model.

“You essentially pay for intelligence twice, once with money, and again with something even more valuable: the proprietary knowledge you must reveal to make that intelligence useful,” he writes. “The better you want the model to perform, the more of that knowledge you have to feed it.”

“You essentially pay for intelligence twice, once with money, and again with something even more valuable: the proprietary knowledge you must reveal to make that intelligence useful.”

When “exhaust” becomes a competitive advantage 

According to Nadella, every engagement with an enterprise AI system generates what he describes as “exhaust” that gradually captures how an organization operates.

“Every correction is distilled into institutional know-how,” Nadella writes. “It’s the kind of knowledge a competitor could never buy, and the kind that leaks almost imperceptibly: trace by trace, correction by correction, eval by eval.”

“Every correction is distilled into institutional know-how. It’s the kind of knowledge a competitor could never buy, and the kind that leaks almost imperceptibly: trace by trace, correction by correction, eval by eval.”

Over time, those thousands of interactions create an internal corpus of organizational knowledge that may be more valuable than the original documents that seeded the system. The more employees use AI, the more an organization’s expertise becomes embedded in how those systems operate.

Redefining the trust boundary 

In practice, those troves of knowledge could push enterprises toward model-agnostic AI stacks in which prompts and memory stores remain under their control — even as the underlying foundation model changes.

In his post, Nadella also took aim at current AI business practices, arguing that model providers claim broad rights to learn from public data while limiting how customers can reuse or build on the knowledge created inside their own organizations.

https://t.co/xv6csf1SbV

— Satya Nadella (@satyanadella) July 12, 2026

Some observers may see an irony in the argument coming from Microsoft’s CEO. Nadella warns that enterprises risk losing valuable organizational knowledge to AI systems, yet Microsoft sells Copilot, a product whose value depends in part on wide access to enterprise data. Copilot works by traversing Microsoft Graph, allowing it to reason over documents, emails, chats, and other information that a user is already authorized to access.

Security researchers have raised concerns about the amount of sensitive information such systems can expose if organizations have overly permissive access controls. Research from Concentric AI showed that Copilot accessed nearly three million confidential records per organization during the first half of 2025, while EPC Group audits found that roughly 80% of enterprise Microsoft 365 tenants had significant oversharing risks, including salary information, merger documents, and customer data that could be surfaced through Copilot. The U.S. House of Representatives also banned staff — but later reversed that ban — from using Copilot over data security concerns.

The Microsoft distinction

Microsoft, however, draws a distinction between accessing enterprise data to answer user requests and using that data to train foundation models. The company says information retrieved through Microsoft Graph is not used to train its AI models, and that Copilot respects existing permissions, identity controls, and sensitivity labels.

Still, the commercial strategy here is hiding in plain sight: Nadella’s Sunday “reverse information paradox” post is effectively a roadmap to Azure. Everything Nadella recommends building runs on cloud infrastructure. Essentially, enterprises can swap out the foundation model, but they’re not going to swap out the cloud.

Owning your AI learning loop 

To counter the perceived shift toward giving over information to frontier labs, Nadella outlined several priorities for enterprise AI architecture. Among his recommendations:

  • Keeping organizational memory inside the enterprise tenant.
  • Building private evaluation and learning systems.
  • Decoupling orchestration layers from any single foundation model.
  • Preserving the ability to switch models without losing accumulated organizational knowledge.

Taken together, Nadella’s argument comes back to the idea that enterprises should own their learning loop rather than handing pieces of it to the companies that provide their AI models.

Nadella reinforced that idea by quoting Palantir CEO Alex Karp, who has similarly argued that enterprises want complete ownership over their AI infrastructure.

Model-agnostic orchestration emerges 

In the end, by maintaining control over their means of production, enterprises can finally ensure that when they invest in AI, the compounding value stays inside the business where it belongs. Tools like LangChain and Haystack are gaining traction specifically because they let engineering teams treat foundation models as plug-and-play commodities, rather than hardcoded dependencies.

“What the technical customers want is control over their compute, their models, their data stack, and their alpha,” Nadella quoted Karp. “They want to know they own the means of production, and it’s not being transferred to someone else.”

“They want to know they own the means of production, and it’s not being transferred to someone else.”

The post Microsoft CEO Satya Nadella says you’re paying for AI twice — the second price is worse appeared first on The New Stack.

The desktop infrastructure problem that Kubernetes finally solves

13 July 2026 at 07:00

Presented by Kasm Technologies


Enterprise infrastructure teams have spent the better part of a decade pushing workloads into Kubernetes. Applications, APIs, batch jobs, data pipelines — if it runs in a container, it belongs in the cluster. The operational benefits are well-established: declarative configuration, horizontal scaling, self-healing, native integration with CI/CD pipelines and observability tooling. Kubernetes has become the default operating model for production workloads.

Except for desktops.

Secure desktop and application delivery — the kind that enterprises depend on for remote work, privileged access, and regulated-industry workflows — has remained stubbornly outside the Kubernetes model. Legacy virtual desktop infrastructure was built in a different era, for a different set of assumptions: pre-allocated VM pools, bespoke management planes, proprietary appliances, and operational tooling that has nothing to do with how modern platform teams work. The result is a split infrastructure reality: a modern, cloud-native application layer on one side, and a manually managed, operationally isolated desktop layer on the other.

That split is expensive. It means different tooling, different scaling behaviors, different observability approaches, and different operational runbooks. Platform engineers who are proficient in Kubernetes still have to context-switch into an entirely different mental model the moment a desktop infrastructure problem arises.

The more fundamental issue is that this split is unnecessary. Secure, containerized workspace delivery is a workload that Kubernetes is architecturally well-suited to run. Sessions are containers. Scaling is demand-driven. Configuration should be declarative. The only thing missing was a platform built to take advantage of that alignment.

Why the timing is right

The appetite for Kubernetes-native workspace delivery has grown significantly as organizations mature their container platform investments. Platform teams that have spent years standardizing on Helm, GitOps workflows, and Kubernetes-native observability are increasingly unwilling to make an exception for desktop infrastructure. The question has shifted from "can we run this on Kubernetes?" to "why isn't this running on Kubernetes already?"

At the same time, the security case for containerized workspace delivery has become more urgent. Browser-delivered, containerized workspaces provide session isolation that VM-based desktops cannot match — each session is ephemeral, isolated at the container boundary, and terminates cleanly without persistent state. For organizations managing sensitive data, insider risk, or third-party access scenarios, this isolation model is a meaningful security control, not just a deployment convenience.

The convergence of these two trends — Kubernetes-native infrastructure expectations and containerized session security — creates a clear opportunity for platforms that can address both simultaneously.

What Kubernetes-native deployment looks like

A Kubernetes-native deployment uses Kubernetes as the control plane for workspace infrastructure — handling orchestration, scaling, and lifecycle management through the same declarative model used across the rest of the platform. Instead of relying on dedicated management appliances or pre-provisioned desktop pools, infrastructure is managed through the same CI/CD, GitOps, observability, and security workflows the platform team already operates. This gives platform teams a consistent operational model rather than maintaining a separate toolset for desktop infrastructure.

Kasm Workspaces, the browser-delivered workspace platform, is purpose-built to use Kubernetes as the control plane for workspace orchestration and delivery. Its deployment model is designed for real enterprise environments — not simplified demos — with production-grade Helm charts that follow Kubernetes conventions, tested upgrade paths between versions, and a standardized backend architecture validated across production deployments. An RDP Gateway component purpose-built for the Kubernetes topology enables Windows and Linux virtual machine access through the same platform.

Key capabilities include:

  • Horizontal session scaling driven by actual demand, orchestrated by Kubernetes — no pre-warmed VM pools required.

  • Declarative configuration through Helm values, enabling GitOps and CI/CD integration for workspace infrastructure.

  • Namespace-level isolation and compatibility with existing RBAC policies, ingress controllers, and secrets management integrations.

  • Metrics export for integration with Prometheus and existing observability stacks.

  • Rolling builds by default, reducing maintenance windows and enabling more predictable version management.

Real-world applications

Regulated-industry remote access. A financial services organization running a Kubernetes-based application platform can deploy Kasm into the same cluster, using the same operational tooling, to deliver isolated browser and application sessions to analysts and advisors. Sessions are ephemeral, network egress is controlled, and the entire deployment is managed through the same GitOps pipeline as their application workloads.

Contractor and third-party access. Organizations that regularly onboard contractors or external vendors — with the associated privileged access risk — can provision Kasm sessions on Kubernetes that scale up during engagement periods and scale back during low-demand windows. No persistent access. No VPN extension to external parties. Containerized isolation at every session boundary.

AI/ML development environments. Teams building and running AI models need GPU-enabled development environments with security controls that general-purpose cloud desktops rarely provide. Deploying Kasm on Kubernetes with NVIDIA MiG Multi-Instance GPU support lets platform teams deliver fractional GPU resources into isolated workspace sessions — giving data scientists the compute they need without shared-infrastructure security exposure.

The operational shift

The practical implication of a Kubernetes-native workspace platform is that platform teams can stop treating workspace infrastructure as a special case. The same engineers who deploy applications can deploy the workspace platform. The same pipelines that manage application configuration can manage workspace configuration. The same dashboards that monitor application health can monitor workspace health.

That operational consolidation reduces overhead, improves consistency, and eliminates the context-switching cost that has made desktop infrastructure a persistent pain point for cloud-native organizations.

For organizations still running legacy VDI alongside modern cloud infrastructure, the question is no longer whether a Kubernetes-native alternative exists. It does. The question is when to make the transition.

Organizations interested in evaluating Kubernetes-native workspace delivery can explore the platform at kasm.com and try out community edition for yourself.

Daniel Ben-Chitrit is the Chief Product Officer at Kasm Technologies.


Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

❌