Development of an AI system for detecting safety violations on construction sites

Safety control on site relies on walkarounds and human attention — violations are noticed after the fact. We develop and implement turnkey AI detection of safety violations: the system detects in real time the absence of a hard hat, work at height without fall protection, and hazardous zones. Reaction time is reduced severalfold, and the share of violations drops in the first weeks.
Frequently Asked Questions

Developing AI for construction: where safety control is lost

Video surveillance on site usually covers the "recording exists" task: cameras are installed on the perimeter, at the crane, and at site cabins, and the archive is recorded continuously.

But construction safety control does not become tighter because of this — a single occupational safety engineer covers dozens of zones and cannot watch everything at once while a shift runs in several streams.

As a result, a violation — working without a hard hat, no fall protection at height, passing under a load — is recorded after the fact: during a walkthrough or after an incident.

The most expensive part is the post-incident review.

The dispute is based on words, not recordings: the archive holds hundreds of hours of video, no one finds the needed fragment, the contractor disputes the order, and there is no way to prove that a person was in a hazardous zone at a specific minute. Some violations go unpunished, and safety culture rests on verbal warnings.

Safety violation detection closes this gap. The model works on the camera stream in real time and checks a set of rules on every frame: hard hat and hi-vis vest, safety harness at height, entry into the crane operating zone, unacceptable proximity to machinery.

The event receives a timestamp, camera number, and zone, and a short clip is automatically written to it — the shift is closed not by a walkthrough but by a log with evidence.

AI development for construction here begins not with the model but with the rules: what we consider a violation, in which zone, and with what delay.

Below we break down how this is assembled for a specific site — from camera placement and trigger thresholds to export into a log that is accepted by both the occupational safety department and the customer.

What changes on site: response time and violation rate

The shift ends, and violation review begins only when someone watches the archive — if they get to it at all. Cameras record the stream, but events in it are not marked: work at height without fall protection is learned about from a report or after an incident. The response speed to a violation is measured in hours, not minutes.

Automatic violation detection moves the decision point to the moment of the event. The frame is analyzed on site: absence of a hard hat, work without a safety harness, entry into the crane hazard zone.

We fix the list of events in advance — according to Occupational Safety Rules and the customer's internal regulations — so that the system looks for exactly what actually stops work on site.

A unified safety violation log collects events from all cameras and all contractors: not emails and calls, but a single feed with time, zone, violation type, and supporting fragment.

Contractor control on site becomes comparable — you can see who has the same violations recurring, not who has the loudest foreman.

Reducing false positives is a separate effort. A hard hat glimpsed in a reflection and a crane lift are not considered violations: the decision is made across several consecutive frames, with checks of zones and the person's position.

The share of events that an operator reviews manually drops severalfold, and attention goes to real risks rather than watching the archive.

In total, this shifts two metrics: the time from violation to signal is reduced to a minute, and shift review is replaced by working from the log.

AI detection implementation options: cloud, on-site perimeter, hybrid

The choice between cloud video processing, a local on-site perimeter, and a hybrid scheme is determined not by habit but by three site conditions: how stable the communication channel is, where recordings must be stored according to requirements, and who maintains the equipment.

The same safety violation detection models behave differently in these schemes, so deploying video analytics begins with measuring the channel and auditing camera installation points.

Option When it fits Limitations
Cloud video processing Stable communication channel, 1–3 cameras, no server room on site Channel degradation stops detection: the stream is lost, events go into a queue and are reviewed later
Local on-site perimeter Many cameras, unstable channel, video storage required inside the site Requires a room, cooling, and maintenance; model updates require a scheduled visit or remote access
Hybrid processing scheme Medium-quality channel, some cameras critical, some overview More complex setup: detection is split between the site and the cloud, and a coordinated event queue is needed

On active construction sites, the hybrid scheme more often wins: detection and a short-term buffer remain on site, while events with timestamps and exports for reporting go to the cloud.

The communication channel stops being a single point of failure — during degradation, incident review relies on already recorded events rather than on a continuous stream that may not have arrived.

How implementation proceeds: from site audit to handover to operation

The work order is structured so that the solution is confirmed by facts from the site, not by a demonstration on pre-prepared frames. Each stage ends with an artifact that the customer accepts: a zone map, an annotated dataset, a control regulation, a shift testing protocol.

  1. Site survey. We walk through zones and floors, record angles, lighting across different shifts, obstructions by cranes and scaffolding, and the condition of already installed cameras.

    The output is a control zone map: where visibility is sufficient and where the point needs to be moved.

  2. Data preparation for the model. We annotate frames specifically from this site, not only open datasets: night shifts, rain, dust, partial obstructions. We monitor class balance, otherwise rare violations drop out of training while frequent ones draw attention to themselves.

  3. Configuration of control scenarios. We fix what is considered a violation, set trigger thresholds for each zone, and define the notification route.

    Welding and the unloading zone have different sensitivity — otherwise one zone drowns in false positives while the other misses real cases.

  4. Testing on real shifts. We run in observation mode without notifications and compare triggers with the foreman's walkthroughs: we count misses and false positives and review every discrepancy.

    Based on the results, we adjust thresholds and scenarios rather than tweaking by eye on a single frame.

  5. Shift training and regulations. We document who responds to a trigger and how, how a false positive is disputed, and how the shift is handed over. Without this, the system lasts a week and becomes background noise.

  6. Handover to operation. We provide configured scenarios, instructions, access rights, and the escalation procedure, and support the first weeks of operation. We separately document how to update zones and thresholds when machinery or the number of floors changes on site.

What remains with you: configurations, zone maps, regulations

A safety violation detection system is not only a model that finds a hard hat or a safety lanyard. Its operability rests on configuration: where cameras are installed, what is considered a violation in a specific zone, and who responds to a signal and how.

We hand all of this over to you as working files and regulations — you can change zone boundaries and trigger thresholds without contacting us.

  • Control zone map: outlines of hazard areas, crane operating zone, places with mandatory hard hats — linked to cameras and angles.
  • Scenario configurations: list of detected events, sensitivity thresholds, and rules for suppressing false positives on obstructions and at dusk.
  • Signal response regulation: who receives the notification, within what time, what is recorded in the log, and when an event is escalated to the work manager.
  • Operator access rights: roles, visibility of cameras and events, prohibition on deleting recordings, procedure for granting and revoking access when personnel changes.
  • Instructions for security and the duty shift: how to confirm or reject a signal, what to do at night, and whom to notify on a repeat violation.
  • System documentation: architecture, list of cameras and zones, procedure for updating models, list of checks after commissioning and work on site.
  • Event log and export procedure: format and retention period, how quickly to pull a sample for incident or dispute review.

After several months of operation, it is these documents that hold the system together: the camera contractor changes, security shifts rotate, while detection zones and rules remain operational and reproducible.

Case study at an active site: what changed over a quarter

The pilot was launched at an active site where several contractors work in parallel. Before implementation, violations were recorded by a walkthrough: PPE, work at height without fall protection, entry into the hazard zone under the crane.

Between walkthroughs, episodes did not make it into reporting, and a dispute with a contractor came down to "word against word" — neither a fragment nor an event time.

We configured the Occupational Safety Pilot: cameras at the entrance, at the crane, and on facade sections were separated by zones and work types, with their own rule set for each zone.

The duty shift operator receives a signal with a fragment and confirms or rejects it; rejected ones also go to review, so trigger thresholds were adjusted based on facts, not feelings.

Metric Before pilot After a quarter
Violation episodes included in reporting only from walkthroughs, about 40% 9 out of 10 with confirmation
Time from violation to security signal until the next walkthrough within the shift
Confirmed signals 5 out of 10 at start 8 out of 10
Repeat violations by contractor not tracked visible for each one

The customer's feedback boiled down to one thing: the signal must arrive before the morning walkthrough, not after.

Episodes were included in the morning review — the foreman receives a list for their people and closes it before work starts, and recurring cases with one contractor are taken to a separate safety meeting.

The accuracy of violation detection grew precisely from this: the rules were further tuned to real site conditions — dust, dusk, cramped installation.

What if cameras and security are already on site?

An existing surveillance system is an asset, not dead weight: cameras, cables, the recorder, and the electrical panel are already installed.

Therefore integration with existing cameras begins not with dismantling but with an inventory: which models are installed, where recordings are physically stored, whether there is a free video stream for an external consumer, and what network access exists to it.

Next is checking angles for each zone.

We look at whether the work zone fits entirely in the frame, whether it is obstructed by a material stack or the crane boom, whether there is enough detail for a hard hat, safety carabiner, and fencing, and what the picture is like at night and in backlight.

From experience, 10-20% of cameras have to be repositioned or replaced — the rest of the fleet feeds data into analytics without changes.

Upgrading the surveillance system is a separate compute node on site that takes streams, recognizes violations, and sends outward only events with a frame and timestamp.

Existing security retains familiar access to recordings and live video: the current setup is not broken and is not reconfigured manually.

Work with existing security is built around their regulations — the event arrives where the shift already looks: at the post, on the radio, in the shift log.

The duty operator confirms or rejects the trigger, and this feedback goes into further training, so the share of false positives declines from week to week.

We start phased implementation with two or three risk zones and testing on real shifts, and expand only after detection metrics are stable. This order makes it possible to see the effect before scaling and to avoid stopping work on site.

Common technical concerns: accuracy, false positives, access

False positives are not a property of the model but a consequence of threshold settings and annotation.

Steam from concrete work, sun in backlight, and a swinging crane cable look to frame-by-frame analysis like the absence of a hard hat — that is why recognition is built on a time window.

How is a violation separated from interference?

A trigger passes two filters: model confidence on the frame and verification of the feature across a sequence. The threshold is calibrated on site recordings, so the night shift and fog do not produce a stream of empty alarms.

What about recording storage and access?

We write fragments around the event, not a continuous stream: storage volume drops severalfold while the evidence base remains complete. Access is role-based — security sees the alarm, the safety engineer sees review and export, the contractor sees only their zones.

Is a human in the loop mandatory?

At the start — yes: an operator confirms or rejects the event, and decisions go into further training. Then the threshold is raised, and some violation types move to automatic mode with spot checks.

How does the system adapt to a new site and a change of contractors?

A site is described by zones and rules, not by rebuilding the model: geometry is annotated, thresholds are calibrated on several days of recording. A change of contractor changes the people in the frame but not the settings — the system relies on protective equipment.

Let's discuss the task: what to send to evaluate your site

To come back with a project estimate rather than general considerations, it is enough to send what you already have at hand. We will clarify the rest in conversation — usually half an hour of discussing the task closes questions that would otherwise stretch into a week of emails.

  • site map: boundaries, zones with different safety rules, and places where violations are recorded most often;
  • list of cameras with coverage zones — currently installed or planned, with installation points;
  • how data transmission is arranged: recorder, server, or cloud, whether there is a dedicated channel and capacity reserve;
  • examples of violations to catch: work without a hard hat, at height without fall protection, entry into a hazard zone — 5–10 short recording fragments;
  • who responds today: duty operator, security, site foreman — and by what scheme the signal is transmitted;
  • storage and access requirements: how long to keep recordings, who needs access, whether there are internal restrictions on data processing;
  • restrictions on work at the site: windows when installation and configuration can be carried out without stopping construction, and the contact of the responsible person.

As a result, you receive a site control scheme with camera placement and zone rules, an implementation stage plan with acceptance points and a clear scope of work for each step. Then we fix the timelines and launch the first stage.

AI Development Areas

Latest works

  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1393
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1368
  • B2B Advance company logo design
    B2B Advance company logo design
    815
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1139
  • AIDER company logo development
    AIDER company logo development
    1057
  • CRM development for Chasseurs
    CRM development for Chasseurs
    1152