The Industrial AI Pilot Planning & Implementation Checklist
How to scope a pilot you can actually defend
A safety AI pilot fails for one of two reasons: it disrupts the live security operation while it is being installed, or it ends without anyone able to say whether it worked. This checklist is built to prevent both. It moves in two phases, site readiness before any hardware ships, and explicit success criteria agreed before the first alert fires, so the result of the pilot is a number you can defend in a budget meeting, not a vibe.
Phase 1: Site readiness
Most pilot delays happen here, and almost all of them are avoidable with an hour of verification before hardware leaves the dock.
1. RTSP stream audit
Confirm your VMS, whether Milestone, Genetec, or another ONVIF-capable platform, can expose stable high-bitrate RTSP substreams for the cameras in scope. DHI ingests these locally. A stream that drops or re-negotiates resolution under load is the single most common cause of a stalled install, so test it under a realistic load, not at 3 a.m. when the network is quiet.
2. Power and placement
Verify PoE+ or local power at each edge location, and plan to co-locate the analytics node with the cameras on a single switch. Keeping inference physically close to the lens is what holds detection latency inside 150 milliseconds. A node three hops away on a congested core switch will work, but it gives back the latency advantage you are deploying edge compute to get.
3. Network segmentation
Put the analytics compute on a dedicated safety VLAN. This isolates high-bitrate vision traffic from the primary office network and prevents a broadcast storm during a high-event period such as a shift change from touching either the recording servers or daily operations.
4. Camera angle review
Walk each camera before install and confirm the lens actually sees the incident zone you care about, at an angle a classifier can work with. A camera mounted for general coverage often clips the exact floor area where a forklift-pedestrian conflict happens. Fixing the angle now is free; discovering it in week two of the pilot is not.
Phase 2: Success criteria
Define what success looks like before the first day, in writing, with the people who will judge the pilot in the room.
1. False positive threshold
Pick a target nuisance-alarm rate and hold the pilot to it. In a high-noise environment such as an active rail yard or a busy dock, the goal is a rate low enough that operators act on every alert that surfaces rather than dismissing the queue. Aim for under one percent false alarms in those conditions, and measure it honestly.
2. Notification latency
Verify that a classified incident reaches the dispatcher's screen within a fraction of a second of detection. The end-to-end target is detection inside 150 milliseconds plus VMS routing, so alerts should feel instantaneous to the operator. If they do not, the cause is usually node placement or stream health, both covered in Phase 1.
3. Operator trust
Track a softer but decisive metric: do operators act on the alerts. A pilot that produces accurate alerts that operators still ignore has not succeeded. The whole point of suppressing nuisance alarms is to rebuild the reflex to respond, so watch whether that reflex comes back.
4. Integration cleanliness
Confirm events land in your VMS as proper alarms with the right camera, priority, and metadata, not as a parallel system operators have to watch on a second screen. The deployment should live inside the control room you already run.
Turning the pilot into a decision
At the end of the window you should be able to state, in one sentence each, the nuisance-alarm rate you measured, the notification latency you observed, and whether operators acted on the alerts. Those three numbers are the entire business case. If they are good, scaling is a procurement question. If they are not, this checklist tells you exactly which line to revisit before you try again.