A reversing forklift and a worker stepping backwards out of an aisle occupy the same square metre of floor for less than a second. That is the whole event. In that second, either something warns the driver and the worker in time to change what happens next, or nobody does, and the site has an incident to investigate instead of one it avoided.
Safety happens on that timescale. It is worth asking, then, where your safety AI actually thinks — because the answer decides whether it is a guardian or a historian.
The second that decides everything
Human reaction time to an unexpected audible alert is roughly three-quarters of a second before a muscle even moves. A forklift at 10 km/h covers nearly three metres in that time. The margin you have to work with is not generous, and every component in the chain between the camera seeing the hazard and the alarm sounding eats into it.
This is the uncomfortable arithmetic of real-time video analytics latency. A warning that arrives after the near-miss is not a warning. It is a note for the file.
So the design question is simple to state and unforgiving in practice: how much delay sits between the pixel and the alarm, and where does that delay come from?
Where the cloud quietly loses the race
The intuitive fix for heavy AI workloads is to send the video somewhere powerful. Stream the camera feeds up to a data centre, let banks of GPUs do the detection, send the verdict back. On paper it is elegant. In a safety context it fails at the only test that matters.
Consider the round trip. A camera on a mezzanine encodes its frames. Those frames are compressed, packetised and pushed over the site network to an internet uplink. They cross to a regional data centre. They are decoded, queued behind other tenants' traffic, inferred upon, and the result is sent all the way back to trigger a local alarm.
Each leg adds delay. Video encoding buffers add hundreds of milliseconds before a single frame leaves the building. Network transit and jitter add more, and they are not constant — they are worst precisely when the network is busiest. Then there is the failure mode nobody mentions in the sales deck: the moment the uplink drops, your safety system goes blind. A guardian that switches off when the broadband hiccups is not a guardian at all.
Add it up and cloud-based detection routinely operates seconds behind live. For dashboards and weekly trend reports, seconds are fine. For a reversing vehicle, seconds are the difference between a shout and a stretcher.
What "at the edge" actually means
Edge computing CCTV inverts the model. Instead of moving the video to the intelligence, you move the intelligence to the video. The AI runs on a compact device on site — beside the cameras, on the same local network — and the footage never has to leave the building to be understood.
The frame is captured, analysed and acted upon in the same place, in the same moment. There is no uplink to saturate, no queue behind other customers, no round trip across the country. Low-latency safety detection stops being an aspiration and becomes a property of the architecture. Detection-to-alert collapses from seconds to a fraction of one, which is the range in which a warning can still change the outcome.
The benefits compound. Because nothing depends on the internet, the system keeps working when the connection does not. Because the video is processed and discarded locally, raw footage of your people never crosses your perimeter — a point your workforce and your data-protection officer will both appreciate. And because you are not shipping thousands of hours of high-resolution video to the cloud every day, you are not paying for the bandwidth or the storage to do it.
Forged where latency is unforgiving
We did not arrive at this conviction from a whiteboard. Our detection was built on offshore drill floors — heavy equipment in constant motion, crews working within arm's reach of it, and no tolerance whatsoever for a warning that comes late. On a platform, the nearest data centre is a helicopter ride away and the satellite link is the last thing you would stake a life on. Edge processing was not a design preference there; it was the only honest option.
That same engine now runs in a national oil major's operations, in a major international port and at an international airport, at a sub-0.05% error rate, where sites have measured reductions of around 90% in unsafe behaviour. The environments differ. The physics of the second in which an accident happens does not.
The questions worth asking a vendor
If you are weighing up an AI safety platform, the marketing will talk about accuracy and the number of hazards detected. Both matter. Neither matters if the answer arrives too late to use. So press on the architecture:
Where does inference happen?
On a device on my site, or in your cloud? If it is the cloud, ask for the honest end-to-end latency from frame captured to alarm sounded — not the model's inference time in isolation, which conveniently omits the whole journey.
What happens when the internet drops?
Does detection continue, or does the site go unprotected until the link returns?
Does raw video leave the premises?
For privacy, for bandwidth, and for the peace of mind of everyone on camera, the best answer is that it never has to.
A safety system is judged in the moment a hazard appears, not in the monthly report that follows. That moment lasts about a second, and it does not wait for a round trip to the cloud. Build for the second, and everything else follows.
Latency in industrial safety: why every millisecond matters
The physics of response time
A forklift travelling at 10km/h covers approximately 2.8 metres per second. In the two seconds between a camera-based conflict detection and a PA speaker activating to warn the driver, the vehicle has moved 5.6 metres. In a loading bay with 3 metres of clear space before the pedestrian crossing, the entire available response time is consumed by the detection and alert latency of the system — before a human has had the opportunity to act. Reducing detection and alert latency from 2 seconds to 200 milliseconds recovers 5 metres of warning distance. In a confined yard, those 5 metres are the margin that separates an alert from an incident.
Cloud latency is not a constant
The latency of a cloud-based video analysis system is not fixed — it varies with network conditions, server load and the route your data takes to the inference endpoint. On a site with reliable, low-latency internet connectivity, a cloud system may operate with acceptable latency most of the time. Under the conditions where cloud latency is worst — high-traffic periods, outages, adverse weather affecting connectivity, high server demand — the latency increases precisely when the system is most relied upon. On-premise processing has a constant latency, bounded by the hardware specifications and the complexity of the detection, regardless of what is happening outside the building.
The alert chain latency budget
The latency between a detection event and an actionable response is not just the inference latency. It includes the time from frame capture to inference, inference to alert generation, alert delivery to the control room display, and control room acknowledgement to response. Each stage has its own latency contribution. On-premise inference eliminates the largest variable (the network round-trip) but the other stages must also be optimised. The Discovery phase includes a latency budget analysis that maps each stage and confirms that the total alert chain latency is within the operational requirement for each hazard category.
Technical implementation for low-latency detection
- Edge hardware specification for target latency: the inference latency depends on the GPU specification of the edge device relative to the number and complexity of detection models running — the Discovery phase hardware specification ensures the GPU capacity is matched to the detection load
- Network segment for camera streams: camera streams should be on a dedicated VLAN or at minimum a network segment with guaranteed bandwidth to the edge node — camera stream competition with site business traffic is the most common source of unexpected latency in on-premise deployments
- Alert delivery method selection: control room display alerts are fast but require someone to be watching; webhook and SMS alerts are appropriate for off-hours or dispersed monitoring; PA speaker integration provides the fastest response pathway for immediate physical warning; the alert routing for each detection category should be chosen with the response time requirement in mind
- Latency testing at commissioning: before go-live, measure the actual end-to-end latency for each detection category under representative load conditions — confirm the measured latency is within the operational requirement specified during Discovery
See what your cameras have been missing — book a demo.
