As a Chief Product Officer, I spend a lot of time looking at where enterprise technology is headed and what that will mean for the customers who eventually have to deploy and manage it. Lately, many of those conversations involve AI. Models are becoming more capable, compute requirements continue to grow, and companies are deciding where AI workloads should live. I’m equally interested in what happens outside the data center, particularly as AI becomes connected to RFID, IoT and edge environments.
Most conversations about AI infrastructure begin with GPUs, models, cloud platforms and data. The network usually comes up farther down the list. Anyone who has spent time around enterprise technology knows why. Connectivity receives very little attention when everything is working. The minute a location goes offline, latency spikes or an application slows down, it becomes considerably more interesting.
As companies connect AI with RFID readers, IoT sensors, cameras and industrial equipment, enormous amounts of useful data are being created outside traditional data centers. Processing that information is only part of the challenge. It also has to travel from wherever it was created to wherever it will be analyzed or acted upon, often quickly and continuously.
Following an RFID Read Through the Network
An RFID tag moving through a warehouse is a useful example because the event itself seems simple. A reader captures the tag. That information may pass through a gateway or middleware before crossing the local network and WAN. It might then travel to an edge platform, cloud application or centralized data environment where machine-learning models combine it with other information.
A simplified path might look like this:
RFID Tag → Reader → Gateway/Edge → Network → AI/ML Platform → Application
There is quite a bit happening between the original tag read and whatever business decision eventually comes from it. A network interruption may leave events queued locally. Congestion can slow information. Latency and packet loss become more significant when an application is expected to respond quickly.
The impact depends on the application. A brief delay in routine inventory reporting may go unnoticed. When RFID or sensor data is influencing an automated process based on current location, equipment status or operating conditions, timing becomes much more important.
The Network Has a Lot More Users Now
Enterprise networks were once designed primarily around people. Employees accessed applications, made calls and joined video meetings. Today, RFID readers, sensors, cameras, gateways and industrial systems communicate around the clock. And unlike people, sensors don’t take lunch breaks.
AI adds dependencies because information from several sources may need to come together before it becomes useful. An application might combine an RFID event with inventory records, location information or equipment telemetry.
Bandwidth still matters, but it doesn’t tell us enough on its own. Latency, jitter, packet loss and path availability all influence application performance. A nightly inventory update and an application making decisions while a production line is running place very different demands on the network.
Edge AI Changes Where the Work Happens
Sending every piece of information back to a centralized cloud environment isn’t practical in every situation. A manufacturer may process equipment telemetry locally so an abnormal condition can be identified quickly. A distribution center might analyze RFID events on-site to identify an inventory exception while sending selected information to the cloud for broader analysis.
Processing information closer to its source can reduce latency and unnecessary WAN traffic, but it also creates a more distributed architecture. An RFID reader may communicate with a local gateway. That gateway may connect to edge infrastructure, which exchanges information with cloud platforms, SaaS applications and centralized business systems. Data can move in several directions during a single business process. Application performance increasingly depends on that entire path.
When Connectivity Becomes a Data Problem
Failure scenarios tell us a great deal about whether an architecture is appropriate. Consider an organization tracking assets with RFID across hundreds of facilities. One location loses connectivity. The centralized AI platform may continue operating normally while information from that facility stops arriving. Until communication is restored, the system has an incomplete view of what is happening there.
That changes how I think about network resilience in an AI environment. Traditional availability metrics tell us whether a connection is up or down. The more important operational question may be what happens to the data during the interruption.
Enterprises can combine fiber, dedicated internet access, broadband, fixed wireless and 4G/5G to create diverse connectivity paths. SD-WAN can monitor those paths and direct application traffic according to network conditions and business policies. The appropriate design depends on what is happening at the location and how much disruption the business process can tolerate.
More Devices Bring More Security Decisions
Every RFID reader, sensor, gateway and edge device introduces another connection that has to be accounted for. The environment becomes more complicated as operational technology, traditional IT systems and cloud applications exchange information.
One question I find useful is simple: What does this device actually need to communicate with? If an RFID reader only needs access to a particular gateway or application, there is little reason to give it broader network access.
Segmentation can establish those boundaries. Zero Trust policies can further restrict access based on device, identity and context, while SASE architectures can help apply consistent networking and security policies across distributed environments.
Scale matters too. A design can work beautifully in a pilot and become difficult to operate once it reaches 100 locations. Customers still have to deploy, manage, troubleshoot and expand it without adding unnecessary complexity.
Start With What the Customer Is Trying to Do
In product development, I usually start with what the customer is trying to accomplish. The individual technologies make more sense once that is clear.
A retailer needs its stores operating reliably. A manufacturer needs production running. A distribution center needs accurate inventory information. IT teams need visibility and a practical way to manage their environments. For product teams, that means understanding where data originates, where it will be processed, how quickly it needs to arrive and what happens when connectivity is interrupted.
RFID and IoT are giving businesses an increasingly detailed view of what is happening across warehouses, factories, stores and other physical environments. AI gives organizations more sophisticated ways to analyze that information. Making the connection between the two work reliably requires a network architecture that reflects how the data is actually being used.
I’ve been around enterprise technology long enough to know that connectivity gets the least attention when everything is running well. As AI becomes more dependent on information coming from the physical world, keeping it that way will require considerably more thought behind the scenes.
