AI CCTV analytics are now a standard line item in security tenders in the UAE, often specified without a stated use case. Analytics are useful where they answer a defined question and unreliable where they are deployed to make a system appear advanced. This article separates analytics that work from claims that do not survive a site visit.
What analytics actually do
Analytics are classifiers running on video frames. They attempt to label what is in the picture: a person, a vehicle, a face, a moving object inside a defined region. The output is a label and a confidence value, not a fact. Everything useful in a surveillance system follows from that distinction, because a label can be wrong and the operator still has to make the decision. Systems that present analytics output as certainty create more work than they remove.
The categories that work reliably in most buildings are modest: motion in a defined region, person and vehicle detection, line crossing, loitering in a zone, crowd density estimates and object removal. These are useful for filtering hours of video, verifying alarms and enforcing operating rules. Face-based identification and behavioural prediction sit at the harder end and need far more scrutiny before they are specified in a UAE property.
Where accuracy breaks down
Accuracy claims are usually quoted for favourable conditions. Real sites present low light, headlights, rain, dust, glare, occlusion and camera angles that were chosen for field of view rather than for analysis. A model trained on clear frontal views will not perform the same way at a loading bay at night. Ask for performance under the conditions the camera will actually see, and test a sample before committing to full deployment.
- Low-light and infrared scenes, where colour detail and contrast are lost
- Camera height and angle: analytics are sensitive to viewpoint and object size in frame
- Busy or crowded scenes, where people overlap and detections merge
- Camera motion, dirty domes and defocus, which degrade every downstream result
- Model drift: firmware and model updates can change behaviour without notice
- Scene change: new signage, stock, glazing or lighting invalidates tuning
False positives, false negatives and operator load
A false positive costs an operator a video review. A false negative costs an incident. Systems tuned to eliminate false positives usually achieve it by suppressing detections, which raises the miss rate, so tuning is a trade rather than a setting. The practical test is operator load: count how many events per shift a proposed configuration produces, then ask whether the control room can review them all. Two hundred alerts a day trains staff to ignore the system.
Design helps more than tuning. Placing a camera to give a consistent approach angle, defining regions that exclude trees and footpaths, and separating detection from identification purposes across different cameras all reduce noise. Where analytics are used for response rather than review, they should trigger a defined escalation that someone owns. An alert nobody acts on is not a security control.
Treat vendor accuracy figures as claims requiring verification. Request a trial on the actual site, with the actual cameras and lighting, and compare detection counts against a manual review of the same footage.
Governance, privacy and retention
Analytics increase what a system infers, not only what it records, and that changes the governance question. Biometric or face-based processing is materially different from counting people, and should be justified against a specific operational need rather than included because the hardware supports it. Recording purpose, access rights, retention periods and who may export footage should be documented before deployment, and operators should understand what the system is permitted to be used for.
In the UAE, projects should align analytics use with the authority that governs the property and with the owner's own data-protection position. SIRA's requirements for Dubai installations, and equivalent expectations in the other emirates, shape what may be deployed and how recordings are handled. Where a specification proposes facial recognition, biometric search or analytics spanning third-party premises, obtain a written decision from the authority and the client before design freeze.
Questions to ask before procurement
Most analytics disappointments trace back to a procurement process that bought features instead of outcomes. The specification should state what the operator must be able to do: search recorded footage for a person in a defined area within a stated time, be alerted when someone enters a restricted zone out of hours, or count vehicle entries per day. Framed that way, the functions become testable at handover.
- What specific decision or task does this alert support?
- Where does the analytics run: on the camera, the recorder or a separate server?
- What happens to detection when the recorder loses network connectivity?
- How is the system tuned and re-validated after a site change?
- Which licences are recurring, and what happens if they lapse?
- What audit trail exists for configuration changes and model updates?