Begin with an observable task
“Improve security” is too broad to evaluate. A useful mission might be checking whether loading-bay doors remain open after closing, documenting an accessible perimeter route or providing a live view when an operator receives an alarm. Specify the location, operating hours, evidence needed and authorized response for each task.
A patrol robot usually combines a mobile base, navigation sensors, cameras, onboard processing and a connection to a management system. Autonomy describes some movement and decision functions; it does not mean the machine understands every situation. Treat its output as observations requiring an appropriate level of human review, especially when someone could face an accusation or intervention.
Compare mobile coverage with fixed coverage
Fixed cameras continuously observe a particular view. A mobile camera revisits locations and may see around temporary obstructions, but leaves gaps between passes. Patrol schedules therefore need a revisit target tied to the task. A door checked periodically is not continuously monitored, regardless of how many cameras the robot carries.
Mobile platforms can be useful where installing fixed infrastructure is difficult or where a changing viewpoint helps an operator inspect an event. Their disadvantages include travel time, charging downtime, mechanical maintenance and possible obstruction. A blended deployment often makes more sense: fixed devices cover critical entrances while the robot gathers supplementary views.
Do not equate a larger sensor list with stronger detection. Camera placement, night illumination, vibration, lens contamination and compression affect usable evidence. Request representative clips showing the task under relevant conditions, and distinguish vendor-provided demonstrations from your own witnessed acceptance results.
Keep people in the response loop
Every alert category should have an owner and a documented decision path. A person near a fence may be an authorized contractor. A stationary object may be routine equipment. Operators need context, current site contacts and a way to record why an event was dismissed or escalated.
Write the loss-of-service procedure before deployment. Depending on the risk assessment, the platform might stop safely, return to a designated area or continue a limited local task. There is no universally correct response to losing connectivity. The behavior must be explicit, predictable and communicated to the security team.
Robots should not be presented as substitutes for emergency services or trained responders. Avoid automatic enforcement decisions based solely on an alert. When incidents involve people, proportionality, local law and an accountable human decision are central to responsible operation.
Evaluate complete shifts, not a demonstration lap
A meaningful pilot includes ordinary congestion, route changes, low light, charging and handover between operators. Log planned missions, completed missions, manual interventions, missed observations and unusable evidence. Record denominators: “three interventions” means little without the number of missions and operating hours.
Separate platform availability from useful task completion. A powered-on robot can still fail to deliver the right view. Agree acceptance criteria before the trial, including recovery time, staff workload and safe-stop behavior. Keep a baseline of the existing process so benefits and new burdens remain visible.
The best outcome may be a narrower deployment rather than full-site automation. A repeatable, low-risk route with clear human escalation can be more valuable than an ambitious patrol that requires constant rescue.