AI adoption in the enterprise is moving faster than many organizations can govern it.
The evidence is not necessarily found in an approved corporate AI deployment or a carefully managed technology roadmap. It is sitting in the browser tabs of everyday knowledge workers.
Employees are already experimenting with AI tools to summarize documents, draft content, analyze information, write code and accelerate routine work. Some of those tools are sanctioned by IT. Others are not. For security teams, that creates a difficult balancing act between three competing pressures: the organization’s requirements for security and governance, employees’ growing expectations around AI, and executive demands to become an “AI-first” business without disrupting the operations that keep the company running.
The conventional response has been straightforward: connect employees and applications to a frontier model through an API, establish acceptable-use policies, and build controls around the resulting data flows.
But that approach introduces a fundamental question: where does the organization’s data go when the AI does its work?
If prompts, documents and other sensitive information are sent to an external service, the organization has created another data path to govern. At the same time, AI usage can become yet another disconnected technology generating telemetry that security teams must reconcile with everything else happening across the digital workspace.
The challenge, then, is no longer simply how to give employees access to AI.
It is how to give them access without sending the work somewhere else.
A Quiet Shift in the Model Landscape
For years, the assumption was that meaningful enterprise AI required access to the largest and most capable proprietary models available.
That assumption is becoming less universal.
Open-weight models have improved significantly, narrowing the gap with frontier models for many of the workloads enterprises actually perform every day. Summarization, extraction, classification, drafting and code assistance do not always require the most sophisticated model available.
For these use cases, a model does not necessarily have to be the most powerful. It needs to be sufficiently capable, practical to operate and appropriate for the organization’s security and governance requirements.
The emergence of strong U.S. open-weight options from organizations including Thinking Machines, NVIDIA and Google adds to that shift.
The significance extends beyond model selection.
If a model is capable enough to handle the task and its licensing permits the organization to run it where it chooses, a different question becomes possible:
Does the model need to leave the organization’s environment at all?
When the CPU Becomes Part of the AI Strategy
Another long-standing assumption is that AI inference requires specialized GPU infrastructure.
That is increasingly dependent on the workload and model size.
CPU technologies such as Intel Advanced Matrix Extensions (AMX) provide matrix acceleration directly within the processor. Arm64 platforms, including high-core-count server processors from Ampere, can also provide the throughput needed for quantized open-weight models to support real interactive workloads.
That creates a different deployment possibility.
Instead of sending a prompt and its associated data to an external model, the model can run within the same containerized environment as the user’s work.
The implications are significant.
There may be no need to begin a separate GPU procurement cycle for every enterprise AI workload. Data does not have to leave the environment simply to reach an inference endpoint. And a third-party AI API does not necessarily need to sit in the middle of every transaction.
AI becomes part of the workspace rather than another destination outside it.
Bringing the Model Into the Workspace
This is where the architecture becomes particularly important.
A containerized workspace platform already provides an isolated execution environment for each user. The workspace can be created for the duration of a session, governed according to organizational policies and destroyed when the session ends.
Putting an AI model inside that same boundary changes the relationship between the user, the model and the data.
The prompt stays inside the container. The response stays inside the container. The data being analyzed does not need to travel to an external AI service simply to be processed.
Just as importantly, AI activity can become part of the same operational picture as the rest of the digital workspace.
Prompts, tool calls and outputs can generate session telemetry that feeds into the same monitoring and security processes used elsewhere.
This matters because AI does not exist in isolation.
As organizations introduce more AI tools, agents and applications, security teams face another form of fragmentation: multiple systems producing separate logs, separate controls and separate sources of activity. The more disconnected those systems become, the more effort is required to understand what is actually happening.
A consolidated workspace can provide a common boundary around the user, the application and the AI.
That can reduce the amount of manual correlation required across teams, shorten investigation cycles and give security teams a clearer picture of activity within the environment.
The benefit is not simply another layer of AI security.
It is a reduction in the number of disconnected places where security and operations teams have to look.
The Next Access Plateau
But keeping the model inside the workspace may only be the beginning.
The more consequential change could come from how AI agents interact with the applications around them.
For years, the prevailing vision of enterprise AI agents has centered on APIs. To allow an agent to interact with an application, organizations have often assumed that the application needs an API, an integration layer or some form of agent-specific interface.
That creates an enormous modernization challenge.
Enterprise environments contain decades of software that was never designed for AI agents. There are Windows applications with no modern API, mainframe terminal emulators, proprietary vendor tools and other systems that may have little or no integration path.
Rebuilding or replacing all of them is neither quick nor inexpensive.
Computer-use technology introduces another possibility.
Rather than requiring an application to expose a new interface, an AI agent can interact with a graphical user interface much as a person does: viewing the screen, moving a cursor, selecting an option and entering information.
And a containerized workspace is already designed to render that screen.
The result is a subtle but potentially important shift.
The application itself may not need to change.
The environment around it can change instead.
Modernizing the Delivery Layer
Consider a legacy Windows application that has been running for decades.
It may have no API. Its vendor may no longer be investing heavily in integrations. Replacing it may require a multi-year modernization project, while modifying it may introduce unacceptable operational risk.
Traditionally, automation has meant finding a way to make that application accessible to modern systems.
With computer-use agents operating inside an isolated workspace, the direction can be reversed.
The agent interacts with the application through its existing interface. The workspace defines what the agent can access. The session can be governed and recorded. The underlying application remains unchanged.
In that model, modernization does not necessarily begin with rewriting the application.
It begins with modernizing how the application is delivered and accessed.
That distinction could become increasingly important as organizations attempt to introduce AI into environments dominated by legacy technology.
The enterprise does not suddenly need to transform every application into an AI-native application. Instead, it can create a controlled layer between the AI and the applications that already exist.
This does not eliminate the need for application modernization. APIs, integrations and redesigned applications will continue to have an important role.
But it introduces another path for the enormous installed base of software that cannot realistically be rewritten overnight.
Keeping the Work Where It Happens
The enterprise AI conversation has largely focused on the model: which model is most capable, which provider should be trusted and how quickly organizations can integrate AI into their workflows.
The next stage may be less about choosing the model and more about choosing where the model operates.
If capable open-weight models can run on infrastructure organizations already control, and if containerized workspaces can provide an isolated environment for both users and AI, then the architecture begins to look different.
The model does not necessarily have to sit in a distant service.
The application does not necessarily have to be rewritten.
The user’s data does not necessarily have to leave the environment.
And the security team does not necessarily need another disconnected system to monitor.
Instead, the user, the application, the AI and the controls around them can exist within the same workspace boundary.
For organizations trying to reconcile AI adoption with security, governance and decades of existing infrastructure, that could prove to be the more important shift.
The future of enterprise AI may not require the work to move somewhere new.
It may simply require the environment around the work to become capable of supporting it.
The model doesn’t need to leave the desk. Neither does the work.
Explore the Workspace Approach
Organizations looking to bring AI closer to their users and data can explore how Kasm Workspaces provides a secure, containerized foundation for delivering applications and AI workloads through the browser.
Learn more about Kasm Workspaces and the future of secure workspace delivery.
Want to see the approach in practice? Try Kasm Community Edition for free.
