What does AI add to building CCTV? Standard CCTV records continuously and relies on human review after an incident. AI analytics change the mode of operation: instead of passive recording, the system actively processes video and generates alerts or events when specific conditions are met. For building security, this means the distinction between “we have footage” and “we were notified when something happened.” Whether AI analytics justify the additional cost and operational complexity depends on the specific analytics being deployed, the accuracy of those analytics in the deployment environment, and whether the building has the infrastructure to act on alerts. The deeper architectural question — how to decompose detection, classification, temporal context, and alerting into independently testable stages — is covered in our parent piece on observable CV pipelines for CCTV. This article stays one layer above that: what analytics work, where to mount the cameras, and how much storage and bandwidth the result actually costs. Analytics options and their reliability Not all building security analytics deliver equivalent reliability. The most commonly deployed options, with honest performance assessments (accuracy ranges are observed patterns from deployment experience, not benchmarked rates — environment-specific): Analytic Typical Accuracy (observed-pattern) Primary False Positive Sources Recommended Use Intrusion detection (perimeter crossing) High (85–95%) Animals, blowing vegetation, lighting changes Access control zones, after-hours perimeters People counting High (90–97% in controlled conditions) Occlusion in crowded areas, children Occupancy management, capacity monitoring Loitering detection Moderate (65–80%) Smokers, people waiting legitimately High-risk zones; requires human review of alerts Abandoned object Moderate (60–75%) Stationary objects in normal use, people returning to objects High-security contexts; high false positive burden Aggression/fight detection Low–Moderate (50–70%) Energetic movement, sports, children playing Experimental; not production-reliable for most environments Vehicle detection and LPR High (90–98%) for detection; variable for LPR Partial plate obscuration, angle, lighting Parking management, access control In our experience, intrusion detection and people counting are the two analytics that consistently deliver production-reliable results across building deployments. Loitering and abandoned-object analytics require careful threshold tuning and human review workflows to be operationally useful rather than a source of alert fatigue. This is an observed pattern across our engagements, not a benchmarked rate: the specific numbers shift with camera quality, lighting, and the model release in use (YOLO-class detectors and ONNX-exported classifiers behave differently from older background-subtraction analytics). Why does camera placement matter more than camera count? Camera placement for AI analytics has different requirements from camera placement for post-incident forensics. CCTV for forensics wants coverage — every area captured at enough resolution to identify individuals after an event. AI analytics need capture geometry compatible with model inputs: the camera must see the scene from an angle, at a resolution, and with lighting conditions that the model can process reliably. We see this pattern regularly — a perfectly adequate forensic camera produces noisy analytics output because nothing about its mounting was chosen with a model’s input distribution in mind. Key placement principles: Intrusion detection. The camera should view the perimeter line at a near-perpendicular angle. Cameras mounted at steep angles looking along a fence line produce inconsistent results because the entry event (a person crossing the perimeter) appears as a small, ambiguous motion. Mount cameras to create a clear crossing plane in the field of view. People counting. Overhead mounting (90° or close to it) gives the most reliable person segmentation and count accuracy. Side-mounted cameras at entrance points work but are more affected by occlusion in groups. Minimum resolution for reliable counting: sufficient to fill approximately 80–120 pixels of height with a standing person. Loitering detection. Wide field of view from an elevated position. The camera needs to see enough of the zone that dwell time can be measured across the full area, not just at one point. LPR (licence plate recognition). Constrained geometry. The vehicle must approach within a narrow angle range (typically ±15–20° horizontal, ±15° vertical from perpendicular to the plate) at consistent speed. Lighting — typically IR illumination at the camera — must be controlled. LPR is not reliably achievable from general CCTV cameras at arbitrary angles, which is why it is usually a dedicated camera lane. Storage and bandwidth requirements AI analytics does not automatically reduce storage requirements. Unless the system is configured to store only event clips rather than continuous footage, storage requirements are unchanged from standard CCTV. Continuous storage requirements (vendor-published H.265 reference figures, treated here as planning heuristics rather than a benchmarked rate): Resolution Frame Rate H.265 Bitrate (motion scenes) Daily Storage (24hr) 1080p 15 fps ~1–2 Mbps ~10–22 GB 1080p 25 fps ~1.5–3 Mbps ~16–32 GB 4K 15 fps ~3–6 Mbps ~32–65 GB 4K 25 fps ~5–8 Mbps ~54–87 GB For a 50-camera building with mixed 1080p and 4K cameras, 30-day retention requires roughly 15–40 TB depending on scene activity and compression settings. AI analytics can enable event-based storage — store clips around detected events at full quality, compress continuous footage more aggressively — to reduce storage by an observed 30–60% in low-activity environments. The saving collapses in busy public spaces where most of the day registers as “event.” Network bandwidth. Each camera requires approximately the values above in continuous network bandwidth from camera to NVR/server. For a 50-camera system, this is 50–300 Mbps in aggregate — well within the capacity of a dedicated security VLAN on a modern network infrastructure. On-camera vs server-side analytics. AI analytics can run on the camera (if it has an onboard accelerator), on an edge compute server at the building, or in the cloud. On-camera inference reduces bandwidth to the server but limits per-camera compute and model size. Server-side analytics — typically TensorRT- or ONNX Runtime-based inference behind a Kubernetes-managed service — can process more cameras with more complex models but require adequate bandwidth from cameras to server. Cloud analytics introduce latency and ongoing data-egress costs and are generally unsuitable for real-time alerting. Alert response workflow A camera system generating alerts without a defined response workflow creates alert fatigue, not security improvement. Before deploying AI analytics, define: Who receives alerts (security desk, building manager, mobile app) What the response procedure is for each alert type (verify on camera, dispatch, document) What happens during business hours vs after hours How alerts are reviewed and actioned (interface requirements) What the SLA is for alert response (seconds for intrusion, minutes for loitering) AI analytics deployment checklist Analytics requirements defined per zone (not “add analytics everywhere”) Camera placement reviewed against analytics geometry requirements Lighting conditions assessed for night performance (IR illumination where needed) Test footage from each camera position reviewed for analytics compatibility before finalising placement Network bandwidth planned for camera-to-server and server-to-storage paths Storage capacity calculated for retention requirement Alert response workflow documented and communicated to relevant staff False-positive threshold tuned during commissioning period (first 2–4 weeks) Privacy compliance review completed (GDPR Article 35 DPIA for systematic surveillance) Common failure modes The most common failure in AI CCTV deployments is not the technology — it is the operational wrapper. Systems where no one is monitoring alerts, where alerts go to email inboxes that are checked sporadically, or where the response to a loitering alert is “someone will look at it in the morning” deliver no security improvement over continuous recording. The value of AI analytics is in real-time response, and that requires real-time monitoring capacity. The hidden cost of that gap is something we have written about separately in the context of fragmented security systems. FAQ How do I design observable CV pipelines for CCTV at scale? Decompose the pipeline into independently testable stages — capture, decode, inference, alerting — each emitting operator-readable confidence scores and trace metadata. The architectural pattern is covered in detail in observable CV pipelines for CCTV; this article addresses the analytics, placement, and infrastructure layer that sits on top of that decomposition. Which metrics, traces, and logs make a video-analytics pipeline debuggable in production? Per-stage latency, per-camera frame-drop counts, model confidence histograms versus ground-truth samples, and alert/disposition logs that record what the operator did with each alert. Without disposition logging you cannot measure false-positive rate over time. Which modular boundaries (capture, decode, inference, alerting) should be independently observable? All four. Capture failures (camera offline, lens occluded) must be detectable without inspecting model output; decode failures (corrupt RTSP streams) must be distinguishable from inference failures (low-confidence detections); alerting must log both the trigger and the operator response. How do I detect upstream camera failures before they show up as model-quality drops? Instrument the capture stage with synthetic-image checks (blur, brightness, scene-change anomalies) and stream-health probes. A camera that has drifted out of focus or been repointed will produce confident but wrong detections — the model itself will not flag the problem. What does an SRE-grade SLO look like for a CCTV CV pipeline? Typical SLOs cover end-to-end alert latency (intrusion alerts within seconds, loitering within the configured dwell window), per-camera uptime, and a bounded false-positive rate per zone per shift. Each SLO needs a corresponding dashboard and an on-call response procedure. How do observability investments change incident response time for a security-operations team? Observable pipelines collapse the diagnosis step: when an alert misfires, the operator can see which stage produced the spurious confidence score and adjust the threshold or rule for that zone rather than escalating to the integrator. The result is a system that can be tuned in place rather than re-procured every refresh cycle.
