Why an AI security system misses real incidents
False alarms and missed incidents are usually not two separate defects but the consequence of one thing: the detector is trained on an averaged scene. It is calibrated on a typical site — even lighting, clean angles, daytime footage.
On a live perimeter, the camera faces backlight, in winter the sensor becomes noisy, and movement in the frame is caused by a blizzard. To reduce the flow of false alarms, the sensitivity threshold is raised — and along with the noise, real events are filtered out.
Analytics zones are marked out for installation convenience, not for the security scenario: masks cover areas that interfere with calibration — the strip in front of the gate, a stair flight, the junction of two cameras.
A person passes through such a zone, the trajectory breaks into fragments, and the rule "object in a restricted area longer than a specified time" does not accumulate conditions. This is not a model error but a labeling error — and it repeats in every similar incident.
The last link is the alarm decision, and it is made by a person on the night shift. With hundreds of alarms per shift, most of them empty, the operator stops reviewing every card: checks selectively, responds with delay, and finds the real incident in the archive the next day.
The chain breaks in three places: training on someone else's statistics, labeling for installation instead of a security scenario, and the absence of automatic rules at the decision-making stage. We break down how each of these places is closed.
What changes after implementation: response speed and error rate
The effect of an AI security system is measured not by the number of cameras, but by four metrics taken from a unified event log and shift reports.
Before implementation, they are usually not tracked by anyone: the operator works by feel, and incident analysis starts with the question of who was on shift.
- Time to alarm confirmation. The event arrives at the post with an attached clip and markup, so security responds to a confirmed situation, not to a motion signal. The path from trigger to decision is reduced from minutes to tens of seconds.
- Share of false alarms. The system distinguishes a person, a vehicle, and an interference such as a glare or a swaying branch — the trigger is for an object, not for a change in the image. Patrols stop responding to shadows, and the shift does not waste time rechecking empty frames.
- Load on the duty shift. The operator sees not a wall of tiles but a queue of priority events: routine passages are marked automatically. The camera fleet at the site grows, but the number of simultaneous streams per person does not.
- Incident analysis via a unified log. Triggers, operator actions, and patrol commands go into a single feed with timestamps and links to recordings. The history is retrieved in minutes, without manually reconciling archives from different recorders.
A separate class of failures goes away, where there is an alarm but no response: the system keeps a counter of unconfirmed events and escalates them according to the procedure.
Cameras from any manufacturer with an ONVIF profile join the common perimeter without replacing the fleet, so metrics are calculated for the entire site, not for a single equipment line.
It is correct to compare the result over the same observation window before and after — usually two to four weeks of shifts.
Comparison of operating modes: security post, hybrid, autonomous perimeter
The operating mode of the perimeter is determined not by the recognition model, but by where the decision is made and what happens when communication is lost.
The local perimeter processes the stream at the site, the hybrid scheme moves resource-intensive tasks to the center, and the security post remains the alarm decision point. The choice between them is a trade-off between analytics completeness and site resilience.
In practice, a hybrid usually works best: local modules handle detection and alarm logic, while the center handles database recognition and aggregate analytics.
If the channel drops, the site switches to autonomous security: events are written to a buffer, alarms are processed by local rules, and after communication is restored the archive catches up without losing recordings.
| Perimeter operating mode | When it fits | Honest limitations |
|---|---|---|
| Autonomous site security (local perimeter) | Remote sites, unstable channel, requirement to store data on site premises | Operates on a local database: recognition for rare scenarios and unfamiliar faces is weaker, model updates require a visit or a secure channel |
| Hybrid scheme | Distributed and urban sites with a stable channel, where fallback is needed in case of a drop | Some analytics are unavailable offline, so priorities are set in advance: what goes to the center and what is decided on site |
| Security post in the perimeter | Sites with a human response procedure and a high cost of a false alarm | Speed depends on the shift, and accuracy depends on how convenient it is for the operator to analyze the alarm |
The mode is not chosen "by eye": we measure channel availability, the share of offline operation time, and the number of alarms per shift, then distribute roles between the local perimeter and the center.
Implementation stages: from site survey to handover of procedures
The work proceeds in six stages, and each has an acceptance point: until the customer confirms the result of a step, the next one does not begin.
This protects against the classic situation where the equipment is installed but no one has tested the alarm scenarios on a real stream.
- Site survey. Engineers walk the perimeter and indoor areas, record blind spots, nighttime lighting, the condition of already installed cameras, available network bandwidth, and power points. The output is a report with a coverage map and a list of equipment that can be reused without replacement.
- Surveillance zone plan. The site is divided by criticality: perimeter, entrance groups, cash area, warehouse, service passages. For each zone, the angle and task are determined — overview, recognition, or identification. Acceptance is an approved plan with the exact number of cameras and their positions.
- Installation and integration. Routes, nodes, storage for the video archive with a specified retention depth, power redundancy, and operator access separation. It is checked that recording runs without loss and that the failure of one node does not take down the entire system.
- Alarm scenario configuration. Rules are configured: line crossing, entry into a restricted zone outside schedule, abandoned object, crowd gathering. Sensitivity thresholds and filters are selected to cut off shadows, precipitation, animals, and headlights. Acceptance is a run on recordings from a real 24-hour period.
- Calibration on site data. Models are additionally trained on labeled frames from this site — this removes some false alarms that cannot be eliminated by settings. Acceptance is metrics on a separate sample that did not participate in training.
- Documentation handover. The operator receives a response matrix for each event type, alarm analysis instructions, a layout diagram, and a configuration change log. Shift training is based on these documents; acceptance is when the operator independently works through a training scenario.
After documentation handover, the system goes into support: new zones and scenario edits are made through the same log, so the configuration can be reproduced and rolled back to a previous version.
What remains at the site: configurations, zone plans, procedures
A physical security system lives not only in cameras and models — its behavior is determined by configurations, plans, and rules.
If these artifacts remain with the contractor, the site loses manageability: changing a zone or switching integrators turns into reconstructing the logic from memory.
That is why we assemble the documentation package during the project and hand it over to the customer — in a repository and on physical media, without proprietary formats.
- Solution configuration — files with detector parameters, trigger thresholds, and camera binding, from which the test bench can be deployed from scratch.
- Zone and access plans — floor plans with markings of controlled zones, passage directions, and role-based access levels.
- Permission matrix — who sees which events, who confirms an alarm, and who has the right to change settings and thresholds.
- Shift procedures — the operator's procedure upon a trigger, response time, escalation rules, and shift handover.
- Deployment and recovery instructions — step-by-step service startup, checking connections with cameras and access control, and rollback to the previous configuration.
- Event storage scheme — where recordings and metadata are stored, how long they are retained, and how they are exported upon a security service request.
- Site datasheet — equipment list, addressing, integration points, and support contacts with a division of responsibility areas.
The package is assembled so that another contractor can take it over: interfaces, exchange formats, and external dependencies are described, not just the final result.
A new team deploys the configuration on its own test bench, verifies the plans, and continues the work — without redesigning the system or making repeat site visits.
Case study: how the flow of false alarms was reduced at a distributed site
What it was before implementation
The client is a network of distributed sites: several dozen locations, each with its own camera fleet.
Detection triggered on motion in a zone, so the unified monitoring center received 1000-1200 alarms per day, and up to 85% of them were false — branches, floodlights, shadows, animals, contractors during non-working hours.
Analyzing one alarm took the operator 3-4 minutes, and the average response to a real incident reached 20 minutes: significant events drowned in the flow.
What was changed
The camera fleet and recorders were left as is — integration was done with the already operating Milestone video surveillance platform.
A detection module appeared at each site that filters events before sending them to the center: by object class, zone entry, and time of day, with verification across several consecutive frames.
The second line is server-side: triggers from several cameras in the same area are merged into one, while short and duplicate ones are suppressed. The operator receives not "motion in a zone" but a card with a verdict and a ready recording segment.
What the metrics showed
The alarm flow dropped from 1000-1200 to 40-60 per day, and the share of confirmed ones grew from 15% to 75%. Response to a significant event was reduced from 20 minutes to 40 seconds — the operator sees it first, not after sorting through noise.
The shift is handled by one operator instead of three with the same number of locations, and no missed real events in the coverage area were recorded. New sites are connected using a standard detection profile: a location is brought into the perimeter in hours.
How does AI video analytics differ from classic video surveillance?
Classic video surveillance reacts to changes in the image: the detector compares pixels in the area of interest and, when the sensitivity threshold is exceeded, writes the event "something happened in the frame." Whether it is a person, a cloud shadow, or snow — the system does not distinguish.
The operator receives a stream of such triggers and manually reviews the archive to find something significant.
AI video analytics works at a different level.
The frame passes through an object detector, a trajectory is built between frames, and the event is described by a scenario: a person crossed a line in a prohibited direction, approached the perimeter, left an object, or remained in a zone longer than a specified time.
The decision is made based on metadata — object class, coordinates, direction of movement, time — and not on pixel brightness.
The differences between the approaches show up in detection accuracy on complex scenes. At night, in rain, or with dense traffic, a sensitivity threshold set during the day produces a flurry of false alarms, while an object classifier filters out the noise.
It is correct to compare systems by the share of false alarms and misses per hundred events and by the time it takes to find an incident in the archive — not by the number of cameras.
The difference is fundamental where real-time response is needed — opening a barrier, stopping a line, notifying security — and where search by attributes is needed instead of reviewing a day's worth of footage.
If the task comes down to recording and storage, the classic scheme remains a reasonable choice. Analytics is installed on top of an already operating platform such as Milestone: the camera fleet does not change, only a processing layer is added.
Frequently asked questions: false alarms, data, and duty shift operations
These questions come up at almost every other meeting about an AI security system, so we answer directly, without "it depends on the scenario." Below are four technical doubts that most often slow down the start.
People constantly walk through the zone — won't there be a stream of false alarms?
An alarm is raised not by a single frame, but when the scene over time matches a rule: entry into a restricted zone, an abandoned object, or movement during non-working hours.
Thresholds and schedules are configured for each camera separately, so a checkpoint at peak hour does not turn into a queue of triggers. We calculate the false alarm filtering rate at a pilot site before scaling.
How long are recordings stored, and how do I find the needed episode?
Retention is defined by rules: continuous archive — one period, alarms with linked clips — longer, service metadata — separately. The event is recorded more densely than the background stream, so volume grows predictably, and the episode is found by time, camera, and event type.
Who inside the company will get access to video and analytics?
Access is role-based: the operator sees only their zone, the security service head sees all cameras without export rights, and the administrator manages the rules.
Views and exports are logged, and processing can run in a local perimeter if frames cannot be taken outside the site.
How difficult is it to train the duty shift?
The duty operator's interface is reduced to three actions: confirm an alarm, reject it as false, or dispatch a patrol.
Training takes two to three shifts of 30-40 minutes; after that, the shift analyzes real triggers together with our engineers — feedback further trains the model for the specific site, and decisions are made without prompts.
Let's discuss the task: what we need to know about your site
To come back with an estimate and work plan rather than general promises, we need input about the site — it determines both the composition of models and hardware requirements.
Below is what is sufficient to describe in the task discussion: the more precise the wording, the fewer iterations in the project.
- List of zones and viewpoints: perimeter, entrances, parking, warehouse and cash areas, where cameras are already installed and what tasks they currently cover.
- Quality of the existing stream: recording stability, nighttime footage, angles, obstructions. This determines whether the current optics can support the detector or replacement is needed.
- What we consider an event: entry into a restricted zone, abandoned object, crowd gathering, attempt to pass two people at once, mask removal. The event list is the scope of work.
- Response to an event: who receives the notification, within what time, and whether integration with the access control system, notification, and security post is needed.
- Data restrictions: where the archive is stored, how long it is retained, whether frames may be taken out for training, and whether there are requirements for biometric processing.
- Infrastructure: where we deploy — on our own equipment in the customer's perimeter or in a dedicated network segment, and what communication channels exist between sites.
- Load: number of cameras per processing node, expected number of events per day, and permissible delay between frame and notification.
Based on this input, we assemble the layout, model composition, and work plan with stages and acceptance criteria. There are no obligations on your side at this step — just a conversation about the matter.
