Computer vision beyond the demo: a production guide to CCTV analytics

A useful use case connects something visible to a specific action. Examples include identifying entry into a restricted area, detecting an unattended object in a defined zone, confirming the use of required protective equipment or measuring a queue that has exceeded an operating threshold.

Write the event definition in plain language, including where it applies, when it matters, who receives the alert and how quickly they must respond. If the event cannot be defined consistently by people, the model will not make the ambiguity disappear.

Existing CCTV estates were commonly designed for human review after an incident, not continuous machine interpretation. Resolution, frame rate, field of view, mounting height, compression and lighting all affect whether the event can be detected.

A site survey should map each use case to candidate cameras and record blind spots, scene density, environmental variation and connectivity. Some gaps require repositioning or adding a camera; attempting to compensate with a larger model can increase cost without solving visibility.

Edge processing can reduce response time and bandwidth while keeping more video on site. Central processing can simplify fleet management and provide elastic compute. Many systems use both: lightweight event detection near the camera with centralized configuration, review and analytics.

The decision should reflect latency, connectivity, privacy, retention, hardware support and the number of concurrent streams. Include degraded-mode behavior: what happens when the network, camera or inference service is unavailable?

Precision and recall are operating choices, not abstract leaderboard numbers. Missing a high-severity safety event has a different cost from creating an unnecessary queue notification. Thresholds may also differ by site, time window and zone.

Use site-specific validation data and review errors by condition. An aggregate score can hide poor night performance or a recurring false alert caused by one camera angle. Where consequences are material, the system should assist an authorized person rather than trigger an irreversible action automatically.

An operator needs enough context to decide quickly: event type, camera and zone, timestamp, severity, a short visual clip or frame and the expected action. Duplicate events should be grouped, and escalation should reflect whether the first recipient acknowledged the alert.

Measure acknowledgement time, confirmed-event rate and resolution—not only detections. If alert volume exceeds the team’s capacity, accuracy on paper will not create operational value.

Use the minimum visual data necessary for the stated purpose. Define access by role, encrypt data in transit and at rest, record review activity, set retention periods and protect camera credentials. Depending on jurisdiction and context, notices, impact assessments or additional legal controls may be required.

Features involving identity or sensitive inference require a separate risk decision. Teams should distinguish anonymous event detection from identification and avoid expanding the purpose simply because a technical capability exists.

Production monitoring should cover stream availability, frame quality, inference latency, hardware health, alert rates and confirmed accuracy. Camera movement, seasonal changes or a redesigned floor can create drift even when the software has not changed.

Maintain versioned configurations for zones, thresholds and models. Roll out updates to a small group of cameras first, compare results and retain a rollback path.