Development of an AI system for detecting the absence of PPE on construction workers

On a construction site, taking off a hard hat or vest for a couple of minutes is already a violation that an inspector will not always notice. We develop and implement turnkey PPE detection systems: cameras automatically detect the absence of a hard hat, vest, or safety harness and send a signal to the responsible person. The share of violations that reach review is reduced several times over.
Frequently Asked Questions

Why PPE detection fails on a real construction site

The naive setup looks like this: the detector finds a hard hat and vest in the frame, and occupational safety control at the construction site boils down to the rule "object present — no violation." On studio datasets, such hard hat recognition yields suspiciously even metrics, and it is on them that the decision to implement is made. The construction site breaks this picture in the first shift.

A hard hat in the frame does not equal a hard hat on the head. A crew enters the zone, people overlap each other, rebar and the crane boom cut through the silhouette — the detector loses the person or associates the headwear with someone else's torso.

Hard hats in a truck bed, on a table, and in a hand divert some detections into noise: this is not a model defect but the absence in the labeling of a separate state "hard hat not on head."

Shooting conditions finish off the rest. Low sun in backlight turns a person into a black outline, a night shift with infrared illumination zeroes out color, a wet vest after rain reflects differently and falls outside the learned color range.

Dust, steam, a water jet, and fast motion produce a blurred frame where none of the modalities holds reliably.

False positives and misses are linked by feedback through the confidence threshold. Lower the threshold — the notification stream grows and security stops looking at them; raise it — the system silently misses a violation.

The gap closes only when "head not visible" becomes a separate state rather than being equated with the absence of a hard hat.

That is why we start not with the model but with the protocol: which zones, which angles, how uncertainty is captured. We look at how this is closed at the level of PPE detection and acceptance of the result.

What changes at the site after launching occupational safety video analytics

An occupational safety engineer cannot stand at every point all day — therefore, before the implementation of occupational safety video analytics, a violation was mainly recorded when a walkaround caught it.

PPE detection removes this limitation: cameras parse the stream continuously, and an episode with a timestamp, zone, and person association goes into the log, rather than a note "no comments." The share of detected violations changes from selective to continuous.

PPE control stops depending on the walkaround schedule, and the reaction speed to a violation is measured in minutes: the event goes to the security post and the site foreman at the moment of the episode, while work is still ongoing and the person can be stopped. This is what distinguishes a management tool from a recorder.

The confidence threshold, zones, and set of classes — hard hat, vest, safety harness at height differences, presence in a dangerous area of machinery — are calibrated against recordings from the specific site.

Otherwise the operator drowns in false positives and stops trusting the system. The event log also serves as an evidence base under ISO 45001.

Incident analytics turns from manual notes into an export: a report by zones, contractors, time of day, and type of violation. It is visible that a violation repeats with one contractor or in one area — and it is closed by organizing the work, not by another order.

A whole class of repeat incidents goes away: not one-off errors but systemic ones disappear, and it is they that account for the main share of injuries.

Operating modes: cloud processing, on-premises loop, hybrid

Compute placement schemes differ not only in where frames are processed but also in behavior when the connection drops. Cloud video analytics removes the load from the site: streams go to external capacity, and no servers are needed on site.

On-premises video processing keeps the entire loop inside — frames do not leave the site, and PPE detection continues to work when the external channel goes down.

The hybrid scheme divides tasks: primary parsing happens at the site, while aggregate analytics and reports are in the cloud.

Scheme When it fits Signal latency Channel Archive storage
Cloud video analytics Stable internet, one or two sites Grows with unstable connection High: constant stream upload from cameras Archive in the cloud, access from anywhere
On-premises video processing Closed site, weak external channel Minimal, alarm at the site Low: only events go outside Archive on the site server
Hybrid scheme Network of sites, aggregate picture needed Low at the site, reports with delay Medium: events immediately, video on demand Hot archive at the site, depth in the cloud

The choice is determined by three questions: channel stability, how many seconds until an alarm is needed, and what archive retention period is required.

With a weak connection and strict privacy requirements, an on-premises loop is chosen; with scattered sites that need to be brought into one picture, the hybrid scheme.

Stages of implementing PPE detection at a site

The first two stages almost always change the initial setup: some cameras are positioned so that a hard hat cannot be distinguished in the frame, while angles appear that were not in the original plan.

That is why we begin the implementation of video analytics with a survey, not with model configuration.

  1. Video surveillance audit — we collect the camera fleet layout, actual viewing angles, night footage, and archive depth. We mark where the stream is suitable for detection, where the lens needs to be turned, and where an additional point is needed.
  2. Zone marking — we separate work areas from walkways and site cabins, and identify places where a hard hat or safety harness is mandatory by regulation. Each zone has its own set of PPE classes; otherwise the system catches violations where there are none.
  3. Control scheme — we fix what is considered a violation, how many seconds a person may remain without a hard hat, and who receives the notification.
  4. Setting trigger thresholds — we balance sensitivity to cut off glare, hoods, and partially occluded figures; we check quality on a labeled sample from the site archive.
  5. Archive validation — we run recordings from past shifts and compare them with the safety log, counting misses and false alarms; if there is a discrepancy, we return to zone marking and thresholds.
  6. System handover — integration with the security console or existing panel, notifications, access roles, shift training.
  7. Procedure — who responds to an event and how, and how zones are updated when the site is reconfigured.

At the output, the customer receives not a set of models but a working loop: a clear area of camera responsibility, a predictable number of alarms per shift, and instructions by which the site operates without us.

What we hand over to the customer after system launch

After launch, the site retains not only a working system but also a package by which it can be operated and handed over to another contractor. Below is what is fixed in the settings and documentation so that PPE detection quality does not depend on a specific engineer.

  • Documentation package — model datasheet with a list of classes (hard hat, vest, safety harness, safety glasses), confidence thresholds, and known limitations: night, glare, occlusions.
  • Control zone schemas — mapping cameras to areas, coordinates of working regions, and a list of excluded zones: checkpoints, site cabins, vehicle parking. This is exactly what removes most false positives.
  • Labeling rules — requirements for the training dataset and the procedure for replenishing it with frames from the site, including resolution of disputed cases between labelers.
  • Stream settings — how often the system looks at the stream, the confirmation window, and deduplication of repeats, so that one pass without a hard hat does not produce a dozen notifications.
  • Access policies — roles and visibility areas: occupational safety sees the whole site, the contractor only its own zones; retention period for clips and export procedure.
  • Response procedure — notification route, responsible person on shift, response times, and escalation for repeated violations in one area.
  • Event log — export with filters by zone, time, and type of violation for reviews and contractor reporting.

Any change — moving a camera, a new area, a change of angle — is entered into the schemas and the log, so that six months later it is clear why the thresholds are set exactly this way.

Case study: how violations involving hard hats and vests were reduced at a site

The site is a residential complex of three buildings, with contractor crews changing almost every shift.

Before implementation, occupational safety relied on walkarounds: the engineer walked the site once per shift and entered violations into the log, while disputed cases were reviewed after the fact using an archive that no one viewed.

What the pre-launch measurement showed

For two weeks we counted manually from archive recordings: how many people were in the zone and how many of them were without a hard hat or vest. The walkaround recorded roughly every tenth violation — the rest did not make it into either the log or occupational safety reporting.

It is not a matter of the engineer's carelessness but of event density: dozens of people work at the site per shift, and they cannot be covered by eye.

What was changed

A detection model based on YOLO was installed on the existing cameras. An event triggers only if a person without PPE remains in the work zone longer than the set threshold — briefly taking off a hard hat near the site cabin does not produce false positives.

The frame with the notification goes to the crew leader almost immediately, and shift monitoring is carried out separately for each contractor organization.

Indicator Before After
Violation detection rate about 10%, walkaround once per shift all zones, continuously
Reaction to violation hours, sometimes next shift up to a minute
Hard hats, violations per 100 person-shifts 24 7
Vests, violations per 100 person-shifts 19 8

The growth in detection rate initially looks like a deterioration — the comparison baseline simply became honest.

After three months, hard hat violations fell by a factor of three, and vest violations by more than half: reviewing a case in the same shift works no worse than the detector itself.

What to do if video surveillance cameras are already installed at the site

A complete replacement of the loop is rarely needed. In most cases, existing cameras continue to work, and PPE detection is installed on top of the existing streams — the recorder outputs the same frames as before.

Whether the current points are suitable is determined by image quality specifically in the risk zones. The frame must reliably show a hard hat and high-visibility vest, night mode must work, and there must be no glare or stream interruptions. A camera with a top-down angle or in backlight will give nothing but false positives.

In practice, a hybrid is more common: an upgrade without replacing the core of the loop plus two or three cameras for problem areas.

We check camera compatibility at the site — we capture test frames from working points and run them through the model, rather than checking against spec sheet characteristics.

Then we configure zones and thresholds: what is considered a violation, how many consecutive frames are needed for confirmation, and who receives the notification.

As a result, PPE detection works on already installed cameras, and expanding the system means adding points, not rebuilding the entire loop.

Common technical questions about occupational safety video analytics

Occupational safety and IT engineers at approval ask almost the same thing: how the model behaves in rain and at night, where recordings are stored, who sees them, and how to retrain the system for the site. Below are brief technical answers.

How accurate is PPE detection at night and in bad weather?

The miss and false alarm rate is measured on labeled frames from your site, not taken from the model description. An event is confirmed by a series of consecutive frames, so glare, a drop on the lens, or a dropped stream do not create a violation.

Where is video stored and what goes to external storage?

The full stream remains at the site; only events with a window before and after go outside. Archive depth is set by the retention period, and old episodes are collapsed into a still frame and event card.

Who has access to recordings and labeling?

Roles are separated: occupational safety sees events in its areas, operations sees camera status, IT sees services without frame content. Views and exports are logged, and external export requires confirmation by the responsible person.

How to distinguish a violation from interference and retrain the model?

The decision is made based on the person's zone and track, not on an individual object: a hard hat on a neighboring worker or a reflection in a puddle is not considered a violation.

We check protection classes against GOST 12.4.011, retrain on frames from your site, and the new version passes a regression set of old scenarios.

Let's discuss the task: we will select a configuration for your site

An estimate "from a description" gives a spread of several times: PPE detection quality depends on camera angle, lighting, stream density, and how the workwear of a specific contractor looks. That is why discussion of the task begins with your data, not with a calculation from a template.

To come back with a project estimate rather than general words, it is enough to send what is already available at the site:

  • 5–10 minutes of recording from each camera — different shifts, morning and twilight, normal and emergency situations.
  • Camera layout diagram, mounting height, and coverage areas — this determines which classes are distinguishable at all.
  • List of PPE to monitor: hard hat, high-visibility vest, safety harness, safety glasses, gloves.
  • Procedure for responding to a violation: who receives the signal and in what form, who closes it and how.
  • Requirements for recording storage and access control — including retention periods and user roles.
  • Site restrictions: where compute may be placed, whether there is a stable channel to the server.
  • Desired launch timelines and the order of sites if implementation proceeds in phases.

Then we review the recordings together with your engineer: we note which violations the model will catch immediately, and where the training dataset will need to be expanded for specific equipment.

As a result, we come back with an implementation plan — stages, areas of responsibility, launch timelines for each site, and target metrics: miss rate and false positive rate.

We separately fix the points where the decision remains with you: notification mode, retention depth, and procedure for camera output.

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