Crowd Video Analytics: Accuracy, Bias and Acceptable Use

Treat vendor accuracy figures as conditional estimates

Crowd video analytics usually returns estimates rather than hard facts about individuals: how many people are in a zone, how dense the scene is, which way flows move, whether an object was left behind or behavior looks anomalous. Counting people in a dense crowd is estimation, and error grows quickly as density, occlusion and clutter rise. Simple line-crossing counters may reach high accuracy in controlled conditions, whereas dense-scene counting and left-object detection remain harder and demand measured proof rather than a promised percentage.

Do not accept a single headline accuracy figure from a sales deck as a description of your site. Ask for error metrics computed on scenes similar to yours: mean absolute error for counting, precision and recall, and separate false-positive and false-negative rates per event class. Before rollout, run the system on your own footage with your cameras, viewing angles, times of day and weather. Only then do the numbers become testable claims instead of marketing.

• Metrics to request: MAE, precision/recall, false-positive and miss rates per event class
• Pilot on your data: resolution, pitch angle, low/high light, rain, night, crowd density
• Measure 'peak' scenarios (event egress, crush risk) where the cost of error is highest

Two error classes with different real-world costs

A false positive is an alert or flag when nothing of the kind happened; a miss is a failure to detect a real event. Their costs differ in live operations. In a security dispatch center, a stream of false positives drains staff time and erodes operator trust until real alarms are ignored too; misses mean the incident the system was installed for goes unnoticed. In people counting, a false positive usually only skews statistics, while a false alert in an anomaly-detection channel can send a patrol to the wrong place.

Overall 'accuracy' is meaningless without saying which error class and which scenario you mean. NIST researchers stress that error type and search type carry very different consequences: in one-to-many identification, a false positive places an innocent person on a candidate list warranting scrutiny, whereas a false negative in one-to-one verification is often a minor inconvenience. Decide in advance which error class is unacceptable for which scenario, and set alert thresholds accordingly.

• A false positive in one-to-many search can lead to a false accusation — costlier than in verification
• A false positive in counting only distorts statistics; in an alarm channel it triggers a dispatch
• Tune thresholds to the false-alarm rate your operations center can sustain

Bias enters long before the camera is switched on

Algorithms learn from data, and groups under-represented in training sets tend to be mis-detected more often. Bias also enters through camera placement (too high or low an angle), lighting (under-exposure of dark-skinned people or over-exposure of fair-skinned subjects) and labeling. This applies beyond facial recognition: a people counter and a behavior detector also depend on who and what the model 'saw' in training — children, wheelchair users and people in atypical clothing can fall out of the sample.

NIST's 2019 demographic study of 189 face-recognition algorithms found that most exhibit demographic differentials; for some algorithms, one-to-one false positives for Asian and African American faces were 10 to 100 times higher than for Caucasian faces, while false negatives depended strongly on image quality. The European Data Protection Board's video-surveillance guidance notes that recognition and analysis software performs differently by age, gender and ethnicity and calls bias a major problem that controllers must assess and supervise.

The practical lesson is that bias cannot be fixed with a single setting. ISO/IEC TR 24027 describes techniques to detect and treat bias at every lifecycle stage, from data collection and labeling to testing and deployment. Re-validate on your own audience regularly, not just once at acceptance.

• Test on visitor diversity: age, sex, mobility, ethnicity
• Control image quality — lighting and angle drive false negatives more than expected
• Document training-data composition and request vendor reports on heterogeneous test sets

Crowd analytics is not the same as biometric identification

Legally, do not conflate 'analytics' with 'identification'. The EU AI Act prohibits in Article 5 the use of real-time remote biometric identification systems in publicly accessible spaces for law-enforcement purposes (subject to narrow, safeguard-laden exceptions) and the indiscriminate scraping of facial images from the internet or CCTV to build recognition databases. Plain crowd analytics — density, counting, abandoned-object detection — is not biometric identification.

However, Annex III of the AI Act classes biometric categorisation and emotion recognition as high-risk systems, and analytics used by or for law enforcement can also be high-risk. Even where a technology is not prohibited, transparency, risk-management and human-oversight duties apply. Outside the EU the regime varies by jurisdiction, so the legal classification must be done for the specific country of deployment rather than assumed.

• Classify first: analytics (density/count/behavior) versus biometric identification/categorisation
• For the EU, check Article 5 and Annex III of the AI Act and high-risk obligations
• For all jurisdictions, establish a lawful basis for processing and document the risk assessment

Set the limits of acceptable use before you install

Start with a concrete purpose and an honest answer: what real change do you want, and can it be achieved only through video surveillance? The EDPB is explicit that video surveillance is not by default a necessity when other means exist. Privacy-by-design must work from the start: collect as little data as possible, keep it briefly, and bind the system to a single, non-multifunctional purpose.

Before launch, complete a data protection impact assessment, a proportionality check and transparency to people on site. Keep a human in the loop: an analytics alert is a request for verification, not a ready-made accusation. Europol's guidance for law enforcement calls for video analytics to be introduced only for defined use cases, with senior-officer approval and public engagement. Decide how long recordings are kept, who accesses the logs, and who is accountable for periodically re-checking accuracy and bias.

• Write the goal in verifiable terms: not 'improve security' but 'cut average response time to a left object in zone X'
• Run the DPIA before, not after, deployment
• Apply a two-person (four-eyes) rule before acting on analytics
• Schedule periodic audits that compare alerts with real events and recompute metrics on fresh data