Most sites that need people to wear protective equipment already have cameras. The footage exists, but someone has to watch it. At Benchmark Data Solutions, that meant people reviewing footage after the fact, so violations surfaced late and how many were caught depended on who was reviewing and how much time they had.
We built them a complete PPE compliance platform: the labelled dataset, the trained models, the AI pipeline, deployment onto hardware at the site, and the web portal their safety team works in. This post covers how we did it and what we learned.
1. The problem: finding violations too late
Checking footage after the fact has two weaknesses:
- It is late: by the time someone spots a worker without a helmet, the shift is over and the risk has already been taken.
- It is inconsistent: two reviewers watching the same footage will not flag the same things, and review quality drops when people are busy, which is exactly when sites are most active.
The goal was not to replace the safety team. It was to give them a consistent, reliable queue of flagged moments to act on, instead of hours of raw footage.
2. Why PPE imagery is harder than it looks
Detecting a helmet in a clean stock photo is easy. Real site footage is not:
- Variable lighting: conditions change across shifts, from bright daylight to low evening light to artificial lighting.
- Partial occlusion: workers stand behind each other, behind machinery, or half out of frame.
- Similar-looking equipment at distance: from far away, different types of protective equipment can look almost the same, and the model has to tell them apart because the compliance rules depend on it.
A generic, off-the-shelf model trained on general images struggles with all three.
3. Starting with the data, not the model
We did not adapt a generic model. We labelled a project-specific dataset from Benchmark’s own site footage.
The main reason: the class definitions had to match their compliance rules exactly. “Wearing PPE” is not one thing; it depends on the site’s rules. By labelling against those rules from the start, the model learned what Benchmark actually needed to detect, not a general idea of “safety equipment”.
Labelling from real footage also meant the dataset already contained the difficult lighting, occlusion and distances the model would face in production.
4. Designing the pipeline end to end
A PPE system is more than a model. We designed the full AI pipeline: how footage comes in, how frames are processed, how detections become flagged events, and how those events reach the people who act on them. Because one team designed every stage, each part was built knowing what the next part needed.
5. Why we deployed at the edge
We optimised the models to run on edge hardware at the site itself, not in a data centre.
- No dependency on a reliable uplink: sites do not always have a strong, stable connection, and running detection on site means the system keeps working either way.
- Detection happens where the footage is: video does not have to travel anywhere before it is analysed.
Running models on edge hardware means making them fast and light enough for that hardware without losing the accuracy the compliance rules need.
6. The portal the safety team actually uses
Detection is only useful if someone can act on it. We built a full-stack web portal for Benchmark’s safety team with:
- A review queue of flagged frames, so reviewers look at specific moments instead of hours of footage.
- An audit trail against each flagged event, recording what was flagged and what was done about it.
- Reporting for the compliance record.
7. What changed
Compliance review moved from ad-hoc footage checks to a consistent queue, with detection running at the site.
And because we owned every layer, there was no handover boundary between the dataset, the model, the deployment and the interface. When something needed to change, one team could change it end to end.
8. Lessons for anyone building computer vision for safety
- Label your own data against your own rules: generic models learn generic ideas.
- Plan for the hard conditions from day one: lighting, occlusion and distance are where these systems fail.
- Decide early where the model will run: edge deployment changes how you build the model.
- Build for the reviewer, not only the model: a detection nobody acts on has no value.
Thinking about computer vision for safety, quality inspection or monitoring? Talk to us.