Every CCTV vendor in the UAE is selling AI analytics right now. Very few are honest about the fact that a good portion of what they are demonstrating will not run usefully on the cameras you already own.
The pitch is appealing: keep your existing estate, add an analytics layer, get intrusion detection and people counting and licence plate recognition without a rip-and-replace. Sometimes that works well. Sometimes it produces a system that generates 400 false alerts a day until someone quietly turns the notifications off.
The difference comes down to a few specific technical constraints. This guide covers which ones matter.
The two places analytics can run
Before assessing anything, it helps to know where the processing happens, because it determines what your existing hardware needs to be capable of.
Edge analytics run on the camera itself. The camera has a processor dedicated to analysis and sends alerts rather than requiring constant analysis downstream. Low bandwidth, low latency, and generally the more accurate approach — but it requires cameras built for it. Your existing cameras almost certainly cannot be upgraded to do this. This is a hardware replacement path
Server-side analytics run on a separate appliance or server processing streams from your existing cameras. This is the actual retrofit path. Your cameras stay, and a new box does the thinking. What determines success here is entirely whether the video your existing cameras produce is good enough to analyse.
There is a third option worth knowing about: cloud-based analytics, where streams are processed off-site. In the UAE this warrants a data protection conversation before a technical one, particularly around where footage is stored and whether it leaves the country. Worth raising early rather than late.
What determines whether your existing cameras can support analytics
Resolution and pixel density on target
This is the single biggest factor, and it is not about camera megapixels — it is about how many pixels land on the thing you want to analyse.
A 4MP camera covering a wide car park delivers very few pixels per vehicle at the far end of its field of view. The same camera covering a single doorway delivers plenty. The camera did not change; the pixel density did.
Different analytics need different densities. Detecting that a person is present needs relatively few pixels. Reading a licence plate needs a great many, and needs them consistently. This is why licence plate recognition retrofits fail most often — the camera was positioned for general coverage, not for plate capture, and no amount of software fixes an image that never contained the information.
Frame rate
Analytics tracking movement need enough frames to follow an object between positions. Cameras configured at low frame rates to save storage — a very common cost-saving choice — will produce jumpy tracking and unreliable counting.
Raising frame rate raises storage consumption, which interacts directly with your retention compliance requirement. This is a real trade-off, not a free setting change.
Lighting and dynamic range
Analytics degrade sharply in poor light and in high-contrast scenes. A camera facing a glass entrance in Dubai daylight produces a blown-out background and a silhouetted subject. Human operators compensate mentally. Analytics do not.
Cameras without good Wide Dynamic Range handling in high-contrast positions are poor analytics candidates regardless of resolution.
Camera angle
Many analytics assume a particular viewing geometry. People counting works well from an overhead or near-overhead angle and badly from a shallow angle where people occlude each other. Cameras mounted high on a wall for broad coverage — the standard security position — are frequently the wrong angle for counting accuracy.
Codec and stream access
Your analytics server needs to pull streams in a format it can decode, typically via RTSP or ONVIF. Older or proprietary recorders sometimes make this awkward. Worth confirming before purchase rather than during commissioning.
What retrofits well
Based on how these deployments generally go, these are the more forgiving applications:
Intrusion and line-crossing detection. Needs relatively low pixel density and tolerates imperfect angles. Genuinely useful for after-hours perimeter monitoring, and a meaningful improvement over basic motion detection that triggers on every cat and shadow. One of the strongest retrofit cases.
Loitering and object-left-behind detection. Similar tolerance. Useful in lobbies, corridors, and back-of-house areas
Occupancy estimation. Approximate people counts in a space, as distinct from precise counting. Tolerant of angle issues because it does not need to track individuals.
Search and forensic retrieval. Rather than real-time alerting, this indexes recorded footage so you can search for “person in a red shirt between 2pm and 4pm” instead of scrubbing through hours of video. This is arguably the most undersold analytics application and among the least demanding on camera quality, because you retain human judgement in the loop. For any organisation that regularly pulls footage for incident investigation, the time saving is substantial.
Camera health and tamper monitoring. Detecting when a camera has been moved, obscured, defocused, or has failed. Unglamorous, and directly relevant to staying compliant between inspections.
What generally needs new hardware
Licence plate recognition. Needs purpose-positioned cameras with appropriate shutter speed, angle, and often dedicated infrared illumination. Retrofitting general-coverage cameras to do ANPR reliably rarely works. Budget for dedicated cameras at the specific capture points.
Facial recognition. Demanding on pixel density and angle, and carries significant data protection considerations in the UAE that should be resolved before any technical evaluation. Treat as a new deployment with legal review, not a software upgrade.
Precise people counting for footfall analytics. If the number needs to be accurate enough to base commercial decisions on, dedicated overhead counting sensors will outperform retrofitted security cameras.
Behavioural and anomaly detection. Sensitive to image quality and prone to false positives on marginal inputs. The false alert rate is what kills these deployments in practice.
The false alert problem
This deserves its own consideration, because it is the most common reason analytics deployments fail after a successful pilot.
Analytics running on marginal input generate false positives. False positives generate alert fatigue. Alert fatigue means staff stop responding to alerts, and eventually someone disables them. You then own an expensive system delivering nothing, and — worse — a security team conditioned to ignore alerts.
A system with modest capability that people trust is more valuable than a capable system that nobody believes.
Before committing: run a pilot on a small number of cameras representing your worst conditions, not your best. Measure the false alert rate over a full fortnight including weekends. If it is not acceptable during the pilot, it will not improve at scale.
Data protection considerations
Video analytics change the nature of what you are processing. Basic CCTV records images. Analytics extract characteristics, behaviours, and in some configurations identity — which is a materially different processing activity under the UAE’s data protection framework.
Points worth raising with whoever handles compliance in your organisation before deployment:
- What is your lawful basis for the analytics processing specifically, as distinct from the underlying surveillance?
- Does your existing signage and privacy notice actually cover analytics, or does it only cover recording?
- If employees are within scope, there are additional considerations around workplace monitoring — proportionality and transparency expectations are meaningfully higher.
- Where is analytics processing happening, and does any data leave the UAE?
- How long are the analytics outputs retained, separately from the video itself?
This is not a reason to avoid analytics. It is a reason to involve the right people early, when the design is still flexible.
A sensible evaluation sequence
- Define the problem before evaluating the technology. “We want AI analytics” is not a requirement. “We want to know when someone enters the yard after 8pm” is. The second question has a clear answer; the first invites a vendor to sell you everything.
- Assess your existing cameras against the specific application. Pixel density on target, frame rate, lighting, and angle — for the cameras that matter to that use case, not the estate as a whole.
- Separate what retrofits from what needs hardware. You will usually find a mix. Retrofitting the tolerant applications while replacing cameras only at the few points that need it is far more economical than either extreme.
- Pilot on worst-case conditions and measure false alerts over at least two weeks
- Confirm the compliance position before scaling.
- Check the interaction with SIRA requirements. Analytics deployments sometimes involve changing camera positions, frame rates, or retention configuration. Any of those can affect your compliance status. Coordinate the two rather than treating them as separate projects.
The honest summary
Analytics retrofits work well when the application is tolerant, the cameras are adequate for that specific task, and expectations are set realistically. They work badly when a vendor demonstration on ideal cameras in ideal lighting is used to set expectations for an estate installed six years ago for general coverage.
The estates that get good value do a mixed deployment: server-side analytics on the existing cameras where the application is forgiving, and targeted new cameras at the handful of points where the requirement is genuinely demanding.
FAQ
Often yes, using server-side analytics that process streams from existing cameras. Whether it works depends on whether those
cameras deliver sufficient pixel density on the target, adequate frame rate, acceptable lighting, and a suitable viewing angle for the specific application.
? Intrusion and line-crossing detection, loitering detection, approximate occupancy estimation, forensic video search, and camera
tamper monitoring are the most tolerant of imperfect camera conditions
ANPR requires high pixel density on the plate, appropriate shutter speed, a suitable capture angle, and often dedicated
illumination. General-coverage security cameras are rarely positioned or configured to deliver this, and software cannot recover information the image never captured.
Yes. Analytics extract characteristics and behaviours rather than simply recording images, which is a
different processing activity. Lawful basis, privacy notices, signage, retention of analytics outputs, and processing location should all be reviewed before deployment.
It can. Analytics deployments sometimes involve changing camera positions, frame rates, or storage configuration, any of which may affect resolution, coverage, or retention compliance. Coordinate analytics and compliance as one project rather than two.
