Why video surveillance does not replace AI construction monitoring
Almost every site has a camera archive, and it seems that this is enough.
But an act about equipment downtime or violation of the sequence of work cannot be compiled from such an archive: the recording is continuous and not marked up, and confirming one fact takes days of viewing. By the time of the dispute, the recording has already been overwritten in a loop.
The camera answers the question "what was in the frame", but not the question "what happened on the site".
AI construction monitoring begins where the stream turns into a marked-up event feed: equipment is working or idle, a crane is lifting a load, a person enters a danger zone, work is not proceeding in the sequence specified in the schedule.
Video analytics for construction divides the stream into intervals with features and puts them into a journal — with a timestamp, camera, and section.
Event recognition on the site then gives not an abstract "smart camera", but an accurate signal about a violation: it goes to the foreman and the control service at the moment when the situation can still be changed.
For contractor control, this changes the nature of the conversation. Instead of "we think the work was stopped", a sample appears: hours of equipment downtime, episodes of sequence violation, each with time and a recording fragment.
The dispute moves from the realm of opinions to the realm of facts, and deadlines and volumes are discussed based on data, not memory.
Below we analyze how construction site monitoring is assembled — from camera placement and rules to the event journal and exports that go into acts.
What constant site control provides: measurable effects
Constant site control makes sense when its effect is expressed in numbers. Below are five metrics that we take at the start of the project and recheck every month: they show where control is already working and where the camera is standing without benefit.
- Reduction of downtime. Equipment and crew downtime is visible on the day of the event, not at the end of the stage: detectors based on YOLO mark equipment, people, and the work zone boundary in the frame, so a shift without movement in the work zone gets into the sample. The share of downtime that we learn about on the same day grows from a few to most cases.
- Control of stage deadlines. Stage readiness is confirmed by frames, not a report: deviation from the schedule is noticeable days before completion, the share of stages closed without delay grows.
- Transparency of work. Continuous recording of shifts removes the dispute "we did this": the share of shifts with a continuous archive — almost all, instead of selective engineer visits.
- Reduction of rework. Hidden works — reinforcement, joints, foundation — get a frame before closing, and the share of work that goes into rework falls several times.
- Reporting on the site. Each remark is closed with a pair of frames "before" and "after": the share of orders with evidence grows, and report collection takes minutes instead of a day.
The five metrics answer one question — control has ceased to be a formality and has become a source of data for decisions on the site.
System operating modes: from event recording to shift analysis
The configuration is determined not by the model, but by where the video stream lives and how quickly a response is needed.
The local contour computes on the site: frames do not leave the site, reaction is in real time even with a weak channel, but the site needs to be equipped and maintained.
The cloud contour computes on the server side: connection is simpler, resources are scaled to the number of cameras, but recognition quality depends on connection stability.
Between them is event recording: the stream is constantly written to a ring buffer on the site, and only fragments around the rule triggering go up. The channel is offloaded several times, and the evidence base for the incident is preserved.
| Mode | When suitable | Limitations |
|---|---|---|
| Real time, local contour | One site, reaction in seconds: exiting the fence, working without a helmet, equipment in a danger zone | Requires a node on the site and its maintenance |
| Real time, cloud contour | Several sites, cameras connect in stages, a single monitoring center is needed | Depends on the channel: during connection degradation, alerts arrive with delay |
| Event recording | Narrow channel or paid traffic; incident analysis is needed, not instantaneous reaction | Will not stop work in the moment — only records and confirms |
| Shift analysis from archive | Acceptance of volumes, reconciliation with the work log, reporting for the period | Result appears after processing, not during the shift |
The modes are compatible and usually combined: event recording on all cameras, local contour on critical zones, cloud — for an overview of all sites. We fix the choice in the configuration before launch so that a change of work stage does not require rebuilding the system.
Implementation of monitoring: survey, setup, handover
The work proceeds sequentially: each stage is closed with an artifact that can be checked before moving to the next. This way, a situation does not arise when the system is formally launched, but the working scenarios on the site are not tested.
- Site survey. We walk the site together with the foreman and security: we record work zones, equipment routes, storage locations, blind spots, and available infrastructure for power and communication.
- Scheme design. We determine camera placement and angles for specific scenarios — helmet control, fences, presence in a danger zone, movement of special equipment. We agree on the scheme before installation so as not to move equipment afterwards.
- Camera setup. We set the view and zones of interest, shooting modes, archive depth, and link cameras to the site plan. Here the main part of false alarms from glare, shadows, and swinging structures is cut off.
- Calibration of models on site. We run real recordings of the site, retrain recognition on the local background and lighting of shifts, set sensitivity thresholds and rules for notifying responsible persons.
- Control day. The system operates in full mode for a day, and we compare signals with actual events: we calculate the share of correct alarms and misses, measure the time from event to notification.
- Acceptance and handover of regulations. We test failure and recovery scenarios according to a checklist, then hand over instructions for the security shift and engineers: who and how reacts to a signal, how to export reports, in what order to retrain the system for new work.
Composition of the delivered system: access roles and documentation
The handover of an AI construction monitoring system is not a demonstration of a working stand, but a set with which the operation service and labor protection work independently.
Below is what remains with the customer after delivery: configurations, schemes, access rights, regulations, and instructions.
- Access roles — a matrix of accounts: observer, shift operator, engineer, administrator, with separate rights to the archive, export of fragments, and editing thresholds.
- Camera placement scheme — plans of capture areas with reference points of view and overlap zones; according to it, the site is equipped further without re-design.
- System passport — composition of nodes, list of controlled events, and limits of applicability: what is recognized reliably and what requires human verification.
- Operator instructions — procedure for working with a shift: how to confirm and reject alarms, what to do in case of a false one, where to write quality remarks.
- Response regulations — the chain "event — notification — responsible person — reaction time" with escalation and recording of incident closure in the journal.
- Configurations — files of zones, sensitivity thresholds, and schedules; versioned so that an unsuccessful change can be rolled back with one command.
- Acceptance protocols — running scenarios on your recordings, error analysis, and a list of resolved remarks.
We write documents for your processes, not for the developer's convenience: acceptance is based on scenarios on a real video stream. After delivery, the system lives on your infrastructure — you can maintain it on your own, and we will discuss a second support contour separately.
Case on site: disputed acts, downtime, and inspection accuracy
The site is a residential complex of three buildings and four contractors.
Inspections were recorded in a journal and photos from a phone, so at the monthly review, 8–10 disputed acts consistently surfaced: the contractor showed a picture, the customer could not confirm either the time or the place. Equipment downtime was explained by waiting for materials — there was nothing to verify this with.
What was changed in the scheme and settings
We kept the existing Hikvision cameras and added two PTZ cameras — at the entrance and near the warehouse, marked responsibility zones for each contractor.
In analytics, we set thresholds: equipment stands in the zone longer than a shift, a person did not appear at the checkpoint during the inspection window, perimeter crossing without a work order.
The event is written with a timestamp and zone reference, and the export goes to the shift supervisor.
What was measured on control shifts
We compared three shifts before and three after. The share of inspections confirmed without manual analysis grew from 46% to 91% — the journal stopped being kept in parallel with the system.
Disputed acts decreased from 8–10 to 1–2 per month, and those are closed by export, not by correspondence.
The downtime picture turned out to be more illustrative. Previously, equipment was idle until the first complaint: the average time from the start of downtime to a decision decreased from about six hours to forty minutes.
At the review, it is clear whose zone it is and how many units were standing — the conversation moves from "it seems to me" to a verification of facts.
What to do if the site already has its own cameras?
The existing camera fleet is not a sentence for the project: on most sites it is supplemented, not completely replaced.
The key question is one — does the camera output a video stream to an external contour and can it be connected to it in parallel with the recorder without breaking the archive recording.
Then everything is decided by the class of equipment. Network cameras with open access to the stream connect directly: the analytics system reads the same video stream as the recorder, and recording does not suffer.
An analog fleet requires a multi-channel video encoder or a hybrid recorder that digitizes the signal and passes it on — the cameras themselves and their wiring remain in place.
The recorder is the most common bottleneck.
Models with closed access to the stream do not output video externally and do not allow a second connection, so the computing node is placed as a separate contour: cameras continue to record to the standard archive, and analytics receives the stream over the network.
Replacing the recorder is inevitable where it cannot withstand parallel load or does not support time synchronization with the rest of the fleet.
Time synchronization is not a formality. Without a single time on cameras, recorder, and server, an event cannot be matched with a recording, and incident analysis turns into a manual search through hours of archive.
The same story with the network: for some sites, it is enough to move video to a separate segment so that the stream does not fall apart under overload during peak hours.
We start with an inventory — we go through cameras and recorders, check access to the stream, image quality at night and in rain, overlap of view zones at key areas.
We set up a pilot on two or three cameras: it shows whether the existing optics are sufficient for monitoring equipment, people, and materials, and only after that we roll out to the entire fleet.
Technical doubts: communication channels, privacy, video quality
Communication on the site is the weakest point: the channel becomes unstable for hours, and the contour should not depend on it. Therefore, recognition takes place on the local node of the site, and events and short fragments go out, not the entire stream.
Privacy is covered by access differentiation: faces and numbers are depersonalized at the input, source data are available by roles, the archive is formed depersonalized — according to 152-FZ. The operator sees the event and its context, but not the personal data of the employee.
What happens if the channel at the site disappears?
The node writes the stream to a ring buffer and sets priorities: alarm events go first. When the channel returns, missing fragments are automatically downloaded — a delay appears in the center, but not a gap in history.
Night shooting gives false alarms. How is this removed?
Night means noise, glare, and insects near the lens. We build detection on several features at once: scene illumination, equipment movement, thermal contour. We calibrate the confidence threshold on the site itself, for its light and work schedule.
How long is the archive stored and can it be compressed?
The term is set by policy: the full stream remains on the site with overwriting in a loop, events and metadata go to the center. The storage volume is reduced several times, and the evidence base for disputed situations is preserved.
Let's discuss the task: we will select a scheme for your site and stages
To offer a scheme for your site, and not a typical set of cameras, in the first conversation we clarify three things: which events are critical — a person in a danger zone, work without protective equipment, equipment off route, lag in stages; which zones need to be covered first; who on your side will handle notifications.
The placement of view points and the rules by which an event is considered a violation depend on these answers.
In return, we send a document: a site view scheme, a list of events with fixation conditions, a breakdown of work by stages, and an implementation plan with dates. Then we launch a pilot on one site — it shows how the solution behaves in your specific conditions.
- Task agreement: we fix the list of events and what we consider a false alarm, so that later there is no dispute about quality.
- Site survey: we look at view zones, lighting, height differences, communication channels and power — the placement depends on this.
- Demonstration on your recordings: we run the model on the archive from the site and show behavior in your conditions before starting work.
- Pilot on one site: several weeks in live mode, daily reports and analysis of alarms together with your security service.
- Calibration of rules: we remove unnecessary alarms, set zones and thresholds — accuracy becomes predictable before scaling.
- Handover and training: access, instructions for reports, regulations for reaction to notifications for the shift and security.
- Scaling: we transfer the proven scheme to other sites and add new events without rebuilding the contour.
