Why governance, privacy and control are changing the conversation about where enterprise AI should run.

The question enterprises aren’t asking loudly enough

For the last few years, much of the enterprise AI conversation has centered on what models can do. Now that AI is moving from experimentation into actual workflows, I think a different question deserves more attention:

Where should all of this AI actually run?

For many organizations, the cloud was the natural starting point. It gave teams access to powerful models without requiring them to build and manage the underlying infrastructure. For pilots, experimentation and many production workloads, it still makes sense.

But AI itself is changing.

We are moving from copilots that respond to prompts toward agents that can reason across multiple steps, access enterprise systems and data, and potentially take action on a user’s behalf. That changes the risk profile considerably.

An AI assistant summarizing a public document is one thing. An agent accessing contracts, financial information, customer records, proprietary code or internal business systems is something else entirely.

At that point, where the AI runs isn’t simply an infrastructure decision. It becomes a question of governance, security, economics and, increasingly, data sovereignty.

Cloud Isn’t Going Away. But Cloud-Only May Not Be the Answer.

I don’t see this as a debate between cloud AI and local AI. Enterprises will need both.

Cloud infrastructure provides access to enormous amounts of compute and some of the world’s most capable models. There are workloads where that scale is essential and where running locally simply wouldn’t make sense.

But sending every AI workload to the cloud creates its own set of considerations.

Every time an employee sends information to a cloud-hosted model, data crosses a boundary. As AI becomes more agentic, those interactions can become much more complex. An agent may need to retrieve information, reason over it, call another tool, validate an answer and then take an action. One employee request can trigger a series of interactions behind the scenes.

For enterprises operating across countries, industries and regulatory environments, understanding where that information travels and where it is processed becomes increasingly important.

Intellectual property adds another layer. Companies are understandably cautious about how proprietary research, source code, product plans and other sensitive information interact with external AI services. Providers can put contractual and technical protections in place, but enterprises will still need to decide which information should leave their environment in the first place.

Agentic AI can require significantly more inference than a traditional chatbot interaction because agents may reason, retrieve, validate and iterate before completing a task. At enterprise scale, that makes the economics of inference an architectural consideration too.

None of this makes cloud AI inherently problematic. It simply means enterprises need more than one place to run AI.

Local agentic AI as a design pattern

This is where the concept of deskside agentic AI enters—not as a replacement for cloud AI, but as a complementary layer in a distributed architecture.

The premise is straightforward: certain AI agents and models can run locally on the device where the user works. The prompts stay local. Selected workloads can remain local when the application, model and governance policies are configured accordingly. The results appear in real time, with no round trip to an external service.

Modern AI PCs and workstations combine CPUs, GPUs and, increasingly, NPUs. The CPU manages applications and agent orchestration, the GPU accelerates larger models and compute-intensive workflows, and the NPU can support compatible, sustained low-power AI tasks.

This heterogeneous architecture allows software to place each workload on the most appropriate engine. Lightweight tasks such as classification, transcription or summarization may run efficiently on the NPU, while larger models, document analysis and complex multi-step agents can leverage the GPU. Actual placement depends on the model, application and software framework.

The result is meaningful local agentic capability that can improve responsiveness, reduce cloud dependency and give enterprises greater control over sensitive data and inference costs.

The hybrid architecture: orchestration, not orthodoxy

The most resilient AI architectures won’t be ideological. They won’t be cloud-only or device-only. They’ll be orchestrated.

In a well-designed hybrid model, policy-based routing is the target architecture, relying on orchestration support direct workloads to the appropriate environment:

  • Sensitive, personal, or compliance-bound tasks often belong closer to the data. They may be strong candidates for local execution, particularly when handling contract reviews, HR document analysis, proprietary code generation, or patient data, subject to organizational security, governance, and compliance requirements.
  • Local does not automatically mean secure. Even when AI agents run locally, organizations must still implement identity and access controls, sandboxing, patch management, monitoring, and auditability to ensure secure and governed operation.
  • Large-scale, collaborative, or training-intensive tasks run in the cloud or at the edge, where elastic compute and large model access provide advantages the device can’t match.
  • Latency-sensitive tasks default to local execution. When an agent needs to respond in the flow of work—during a live meeting, inside a design application, within a coding environment—waiting for a cloud round trip degrades the experience.

The intelligence of the architecture lies in the orchestration layer: the logic that determines which agent tasks run where, based on data sensitivity, latency requirements, model size, cost constraints, and user preferences.

This isn’t hypothetical. The building blocks exist today. What’s required is for enterprises to design their AI strategies with this distributed model in mind from the beginning, rather than retrofitting sovereignty controls after cloud-first deployments are already in production.

Why this matters now, not later

Three forces are converging to accelerate this shift.

Regulatory momentum is increasing, not decreasing. Every major economy is tightening rules around AI governance and data residency. Enterprises that build cloud-locked AI architectures today may find themselves re-architecting under compliance pressure tomorrow.

Agentic AI adoption is accelerating. Industry analysts project that agentic AI will move from pilot to production across most large enterprises within the next two to three years. The volume of sensitive data flowing through AI systems will increase by orders of magnitude. Architecture decisions made now will determine how manageable—or how expensive—that future is.

The hardware is ready. AI PCs and workstations with meaningful on-device AI capability are shipping at scale. This isn’t a roadmap conversation. The silicon, the software frameworks, and the enterprise management tools exist today.

A practical starting point

For enterprise leaders evaluating distributed AI architectures, the path forward doesn’t require a wholesale transformation. It starts with practical decisions:

Identify your most sensitive AI use cases. Where are agents accessing regulated data, intellectual property, or competitive intelligence? Those are your first candidates for local execution.

Model your token economics. Understand the full economic impact of agentic AI, including cloud inference costs, hardware investments, power consumption, support requirements, and infrastructure utilization. Then evaluate which workloads are best suited for local or cloud inference to optimize cost, performance, and operational efficiency across your AI environment.

Evaluate your device fleet. Understand which systems in your organization are truly AI-ready by assessing not only NPU availability, but also GPU capability, memory capacity, model compatibility, software support, security, and manageability. Use these insights to inform refresh planning and identify which devices are best suited to run AI workloads locally.

Build governance frameworks that span both environments. Data classification, access controls, and audit trails should work consistently whether an agent runs in the cloud or on the device.

Design for orchestration from the start. Don’t build agents that are hardwired to a single execution environment. Build the routing logic that lets workloads move as requirements evolve.

The desk as sovereign infrastructure

I spend a lot of time thinking about where enterprise AI is heading, and one thing has become increasingly clear to me: The AI architecture of the enterprise is going to be more distributed than many of us originally expected.

The cloud will remain essential. Data centers will remain essential. Edge infrastructure will remain essential.

But the desk is becoming part of that architecture too.

That’s what makes areas such as Dell Deskside Agentic AI interesting to me. It’s not simply about putting another AI feature on a PC. It’s about asking whether the device employees already use every day can become a secure, manageable place to run certain enterprise agents and AI workloads.

As agents gain access to more valuable data and become capable of taking more meaningful actions, enterprises will need greater control over where that intelligence operates.

The next phase of enterprise AI may therefore be defined by something much less flashy than another model breakthrough: architecture.

And some of the most important AI infrastructure in the enterprise may end up sitting much closer to the user than we expected.