Enterprises are moving quickly on AI, but many are still running networking models designed for a slower, more centralized and static era. Today’s network has to connect clouds, data centers, campuses, branches, partner environments, and increasingly private AI infrastructure while enforcing consistent policy across all of it. That creates a new operational reality: every new workload, region, partner, or AI deployment adds connectivity, segmentation, security, and observability work. Gartner’s 2026 Reference Architecture for Next-Generation Enterprise Networks makes the shift clear: enterprise networks can no longer be designed as monolithic systems built around static sites, fixed traffic patterns, and device-by-device control. They need to operate as modular, domain-aware, API-driven infrastructure platforms that can adapt as workloads, clouds, regions, users, partners, and AI environments change. The old model is giving way to a more flexible architecture where connectivity, policy, telemetry, and automation work across domains, giving infrastructure teams the speed, consistency, and control required for the AI era.
AI Exposes the Weakness in the Current Network Model
Most AI strategies begin with compute, models, and data.
That is understandable. GPUs are expensive. Model selection matters. Data pipelines determine whether AI can deliver useful outcomes. But none of those pieces operate in isolation. AI depends on the network to move data, connect environments, enforce access, route traffic, provide visibility, and support change across distributed infrastructure. This is where many enterprises are exposed.
AI does not just create more traffic. It creates new traffic patterns, larger east-west data flows, tighter performance expectations, more cross-cloud dependencies, and more frequent infrastructure changes. When those demands hit a network still built around appliance chains, static hub-and-spoke patterns, manual provisioning, and cloud-by-cloud exceptions, delays show up quickly.
The better question for infrastructure leaders is not, “Do we have enough bandwidth?”
Enterprises should ask themselves:
- Can we connect a new AI environment without weeks of manual work?
- Can we enforce segmentation consistently across cloud, data center, and partner environments?
- Can we use AI to help us with observability and add contexts from our SIEM, ITSM, and automation platforms?
- Can approved changes be made through APIs or MCP servers instead of manual/complex automation script that does device-by-device configuration?
Those are the operating metrics that now matter.
The Network Is Becoming a Platform, Not a Collection of Devices
Gartner’s report points to a major shift in how enterprises should think about network architecture. Hardware is no longer the center of differentiation. The report notes that most enterprise networking hardware has become largely undifferentiated, with the exception of specialized hardware for AI network fabrics, HPC, and time-sensitive workloads. The innovation focus is moving toward software capabilities such as automation, northbound APIs, infrastructure as code, AI-powered analytics, built-in observability, and dynamic zero-trust policy enforcement.
That matters because AI-era networking is not just about faster pipes or bigger boxes.
It is about whether the network can be operated like a platform.
A platform can expose services through APIs. A platform can be automated. A platform can apply policy consistently. A platform can integrate with observability and IT operations systems. A platform can support repeatable deployment patterns instead of one-off builds.
A device-centric network cannot do that easily.
This is the core architectural shift: from managing infrastructure one device at a time to operating the network through policy, automation, telemetry, and software-driven control.
Modularity Is Now an Operating Requirement
The enterprise network is no longer one thing.
Gartner’s architecture breaks the modern enterprise network into eight major domains, spanning data center, cloud networking, backbone services and cloud private access, SASE, SSE, WAN underlay, campus and branch, and NetOps platforms and tools. The point is not the count itself. The point is what it proves: the enterprise network has become a multidomain operating environment.
That creates a hard architectural reality.
No single domain can be treated in isolation. Cloud teams need connectivity into data centers. Security teams need consistent enforcement across users, workloads, and partners. Network teams need visibility across underlay, overlay, cloud, and application paths. AI teams need infrastructure that can scale without waiting on manual network projects.
This is why modularity matters.
A modular and flexible network fabric allows each domain to evolve based on its own requirements while still operating within a common model for policy, visibility, and control. That is different from both extremes: it is not one monolithic vendor stack, and it is not a fragmented collection of disconnected tools.
The goal is domain-level flexibility with enterprise-level consistency.
Multivendor Is Inevitable. Fragmented Operations Are Not.
Gartner recommends procuring network infrastructure on a per-domain basis because no vendor offers the best performance or price across every network domain. That is the right architectural direction, but it creates an operational challenge.
Most large enterprises are already multivendor. They use different platforms across cloud, WAN, data center, campus, security, and observability. That is not going away.
The problem is not multivendor infrastructure.
The problem is multivendor operations.
Every additional platform can introduce another management plane, another API model, another policy framework, another troubleshooting workflow, and another team dependency. Over time, the enterprise does not just inherit vendor complexity. It inherits operating-model complexity.
That is the trap infrastructure leaders need to avoid.
Avoiding vendor lock-in should not mean accepting operational lock-in. The enterprise still needs a way to abstract complexity, apply policy consistently, integrate across tools, and make changes through software-driven workflows.
This is where Network Infrastructure-as-a-Service becomes strategically relevant. Not as a replacement for every domain, but as a way to create a consistent operating model across the cloud, backbone, private access, and hybrid connectivity seams where enterprise complexity often breaks first.
AI-Ready Networking Requires More Than Connectivity
AI-ready networking is often discussed as a performance problem. That is only part of the story.
Yes, AI workloads can require high-performance fabrics, predictable connectivity, and low-latency paths. But at the enterprise architecture level, the bigger challenge is operational readiness.
Gartner identifies five cross-domain workflows that matter in modern network architecture: control plane, data plane, API calls, telemetry/events, and assurance/verification. Again, the importance is not the taxonomy. The importance is the operating model behind it. A modern network cannot just move traffic. It must expose APIs, emit telemetry, support validation, and integrate with the systems that operate the enterprise.
That is what AI-enabled operations will depend on.
Agentic workflows cannot safely act on a network that is opaque, manually configured, or fragmented across disconnected tools. AI-assisted operations need telemetry to understand what is happening, APIs to make approved changes, policy guardrails to prevent unsafe action, and assurance mechanisms to verify desired-state behavior.
A network that cannot be observed cannot be automated.
A network that cannot be automated cannot keep up with AI.
Security Has to Follow the Architecture
AI raises the stakes for segmentation, access control, and policy enforcement.
Gartner’s report describes segmentation across multiple layers, including macrosegmentation, microsegmentation, and endpoint or client isolation. That matters because distributed enterprises cannot rely on one enforcement point, one firewall layer, or one security pattern. Policy requirements vary by domain, workload, user, device, and risk level.
This is especially important for AI.
AI environments may touch sensitive data, private compute, model pipelines, SaaS services, partner systems, and regulated infrastructure. If access and segmentation are handled differently in every domain, the enterprise creates policy drift, blind spots, and lateral movement risk.
The answer is not more manual firewall work after the fact. Security has to be built into the network architecture from the start. That means segmentation, inspection, access control, and policy enforcement need to be part of the operating model itself, not added later as exceptions around each new environment.
Security policy, segmentation, service insertion, and visibility need to be built into the network fabric so controls can be applied consistently across distributed environments. The broader point is simple: security cannot sit outside the architecture as a later overlay. It has to move with the network, wherever workloads, users, partners, and AI environments go.
Cloud Private Access Is Becoming a Strategic Control Point
One of the clearest enterprise pain points is the seam between cloud, data center, WAN, partner environments, and private access.
Native cloud networking works well inside a single cloud. But large enterprises rarely operate inside one cloud. They operate across AWS, Azure, Google Cloud, private data centers, colocation facilities, branch locations, partner ecosystems, and regulated regions.
The challenge is not connecting to one environment. The challenge is creating one operating model across many.
Enterprises do not need another isolated networking tool. They need a way to simplify connectivity, segmentation, routing, security insertion, and visibility across distributed environments without forcing every use case into a custom project or every domain into one vendor stack.
That is where a cloud-delivered Network Infrastructure-as-a-Service model fits: consistent control across distributed infrastructure, without customer-managed hardware or software.
The CIO Principle: Stop Managing Devices, Start Managing Outcomes
One of the most important shifts in Gartner’s report is the move toward policy-based configuration.
The guidance is clear: avoid focusing on individual device configuration and define policies based on the role or scope of the infrastructure. That is a major operating-model change. It moves networking away from manual device management and toward repeatable, outcome-based control.
For CIOs and infrastructure leaders, this is the heart of the modernization decision.
A device-centric network asks: what configuration needs to change?
A platform-centric network asks: what outcome should the network deliver?
That difference matters. AI, cloud, M&A, partner onboarding, regional expansion, and regulatory change all require the network to adapt quickly. If every change still requires manual coordination across devices, teams, vendors, and tickets, the architecture will slow the business down.
Modern networking needs to let teams define policy once, apply it consistently, validate behavior, and automate repeatable change.
That is how the network becomes part of the enterprise operating model instead of a constraint on it.
Summary
Gartner’s architecture brief is useful not just as a validation of where the industry is heading, but as a planning tool. The building-block model it describes gives infrastructure architects a clear framework for sequencing investment: start with the domain that is most constrained, modernize it in isolation, and integrate it with the broader fabric as you go.
A few principles that should govern that sequencing:
The cloud networking and backbone layers are the highest-leverage starting points for most enterprises. These are the domains where multicloud complexity concentrates, where AI workload traffic flows, and where the gap between what the current architecture can support and what the business requires is widest.
Security policy should be defined at the architecture level before vendor selection, not derived from whatever the selected vendor supports. Gartner’s recommendation to establish zero-trust principles and segmentation requirements per domain is the right sequence. Architecture first, procurement second.
Avoid the temptation to solve multivendor complexity by adding another vendor. The NetOps platforms and tools Gartner describes are valuable when they aggregate and normalize across a genuinely heterogeneous environment. They become shelfware when they are deployed on top of an architecture that has not been simplified at the infrastructure layer.
The network is no longer a utility that runs underneath the business. It is the infrastructure that determines whether the business can execute on AI, operate securely across a distributed footprint, and move at the speed its competitors are moving. Gartner’s reference architecture makes that case with precision. The question for every infrastructure leader reading it is not whether the direction is right. It is how far behind the current architecture already is.
FAQs
Calvin Nguyen
