Bandwidth planning for a remote site has traditionally been a headcount exercise. Forty people on an offshore platform, a voice allowance, crew welfare traffic in the evening, a supervisory control channel small enough that nobody argued about it. Many operators reused the same sizing template across an entire fleet for years, and it held up reasonably well.
The template starts to fail the moment a site begins running inference on its own data. The reason has less to do with AI workloads being bandwidth-hungry and more to do with the sizing question changing character. The link no longer serves a fixed population of users doing predictable things. It serves an architecture, and the architecture has a variable in it that most procurement conversations never surface: where the processing happens.
Answer that question badly and you will either pay for capacity you do not use or throttle a system your operations team has already come to depend on.
Three places compute can live
There are really only three answers, and most sites end up using all of them in some proportion.
On the device. A camera with an embedded accelerator, a vibration sensor with a classifier on board, a controller doing anomaly detection in firmware. Inference happens where the data is generated, and only events cross the network. Power draw is small, model complexity is limited, and updating anything means touching a lot of endpoints.
On the site. A local server or ruggedised edge cluster aggregating feeds, running larger models, holding a rolling buffer of raw data. This is where most industrial AI deployments actually land. It handles workloads a sensor cannot, tolerates connectivity loss, and gives the site a single place to manage models. It also introduces power, cooling, physical security, and a maintenance burden at a location where a site visit is expensive.
Off site. Training, fleet-wide analytics, long-horizon storage, anything that needs to see data across locations. Cloud regions, a corporate data centre, or a partner platform. Capability is effectively unbounded here. The constraint is the link.
The interesting engineering happens in how you divide work between the second and third options, because that split determines almost everything about the traffic profile.
What actually drives the split
Five factors decide it in practice, and only one of them is technical performance.
Latency tolerance. If a decision closes a control loop, it stays local. A collision-avoidance function on heavy equipment cannot wait for a round trip, regardless of how good the link is. If a decision informs a person who will act within hours, remote processing is fine. Much of what gets labelled “real-time” in an operations context has a tolerance measured in minutes.
Data gravity. Video and high-rate vibration data are expensive to move and cheap to reduce. A model that turns forty camera feeds into a few hundred event records per day has changed the transport problem by orders of magnitude. The question is whether you trust the reduction. Teams that want raw footage retained for incident review end up moving far more than teams that accept event metadata plus short clips on trigger.
Model lifecycle. Inference is comparatively light in compute terms. Training is not, and retraining on site is rare outside specialised cases, so most architectures push training centrally and pull updated models down. That creates a periodic download that has nothing to do with the steady-state profile, and it is routinely left out of link budgets.
Power and thermal envelope. At an off-grid site this often decides the architecture before anyone gets to discuss latency. Edge accelerators in the common industrial modules draw somewhere between fifteen and sixty watts under configurable power modes, which sounds trivial until you multiply by node count and add cooling in an enclosure sitting in direct sun. Sites running on solar and battery have a hard ceiling that no software choice can raise.
Data residency and contractual constraints. Some data cannot leave a jurisdiction, a vessel, or a customer’s own infrastructure. This is increasingly common in energy and defence-adjacent work, and it removes the cloud option regardless of technical merit.
The traffic changes shape as well as volume
This is the part that catches network teams out. A site running local inference consumes bandwidth differently, in ways that make average throughput a misleading number to design around.
The direction inverts. Traditional remote site traffic is download-dominant: people pulling content down. An instrumented site pushes event data, telemetry, clips, and model performance metrics upward. Links provisioned with asymmetric capacity favouring the downstream direction start to strain in the direction nobody sized for.
The pattern becomes bursty and scheduled. Model updates, batch uploads of retained footage, and synchronisation jobs cluster into windows. A link that looks comfortable at a daily average can saturate for ninety minutes every night, and if that window overlaps with a shift change or a video call to shore, the operations team experiences it as an unreliable network rather than a scheduling problem.
Tolerance for interruption drops in an uneven way. Losing the link for twenty minutes is survivable for a system that buffers events locally. It is not survivable for a workflow where a remote specialist is looking at a live feed while advising a technician on a repair. The same site can hold both requirements, which means a single service tier rarely fits.
A worked example
Consider a site with forty fixed cameras used for safety monitoring and process observation.
Streaming everything raw is straightforward to reason about. At roughly two to four megabits per second per stream under H.265 encoding at 1080p, forty cameras land in the range of eighty to one hundred and sixty megabits per second sustained, continuously, in the uplink direction. For a site on a terrestrial fibre connection this is unremarkable. For a remote site it is not a sensible plan.
Processing locally and transmitting events changes the profile completely. The site runs detection on all forty feeds, transmits structured event records, and uploads a fifteen-second clip on each trigger. If the site generates a few hundred events per day, the sustained requirement collapses to a couple of megabits per second, with the retained-footage question handled separately by a nightly batch or by shipping physical media during crew rotation.
The gap between those two designs is not marginal, and it is decided by an architecture choice made by a team that often does not talk to the team negotiating the connectivity contract.
What to specify
If you are writing requirements for a site that will run this kind of workload, the useful parameters are more specific than a headline speed.
- Committed information rate in the uplink direction, stated separately from the downlink, rather than a single aggregate figure
- Burst capacity and how long it can be sustained, since scheduled synchronisation jobs depend on it
- Jitter and packet loss behaviour under load, which matters more than peak throughput for interactive remote support sessions
- Traffic prioritisation you can actually configure, so that a batch upload does not compete with a live assistance session
- Behaviour during degraded conditions, including what happens to queued data when the link is impaired and how it drains afterwards
- Scheduled maintenance windows on the provider side, mapped against your own synchronisation schedule
Questions worth asking before the architecture is fixed
Ask what the site does when the link is unavailable for six hours, and whether the answer is acceptable to operations rather than to IT. Ask how large a model update is and how often it ships. Ask who retains raw data, for how long, and under what obligation, because that single answer can multiply the transport requirement by a factor of fifty. Ask what the power budget allows before deciding what the software will do.
Most sites that end up with the wrong connectivity contract did not misjudge their bandwidth. They sized a link for one architecture and then deployed another.
