用于工作场所安全和 PPE 合规性的计算机视觉

A camera pointed at a worksite can reliably answer a narrow set of questions. Is this person wearing a hard hat? Did anyone walk into the exclusion zone around that press? How many people are in this corridor right now? Those are object detection, segmentation and tracking problems, and modern vision models handle them well.

What a camera cannot do is tell you whether a site is safe. Safety is a judgment about rules, context and intent, and the gap between "detected a person without a visible vest" and "recorded a violation worth acting on" is where most computer vision safety projects either succeed or quietly get switched off.

This guide covers what the underlying detection tasks actually are, when to buy a finished safety platform instead of building one, and how teams that do build use Ultralytics YOLO models to do it.

What computer vision detects on a worksite#

Every safety feature marketed as an outcome breaks down into one or more standard vision tasks. Being explicit about which one you need is the difference between a scoped project and an open-ended one.

Two of these are much harder than vendors imply. Association is the first: detecting a hard hat and detecting a person are easy, and correctly deciding which person that hat belongs to in a group of six overlapping workers is not. The second is real-world geometry. A zone drawn on a 2D image is not a zone on the floor, and without calibration a person standing well outside a hazard area can appear inside the polygon.

PPE detection: what "wearing it" means to a model#

PPE detection sounds binary and is not. A model trained on hard hats will find hard hats. It will not natively know that a hat carried in one hand, worn backwards, or unclipped fails the rule, because those are three different visual states that all contain a hard hat.

If PPE monitoring is the goal, specify the rule at the level a model can be evaluated against:

• Which items, per zone. Hard hat everywhere, plus eye protection only in the grinding bay, is two rules, not one.
• Which people, and which exemptions. Visitors, drivers remaining in cabs and office staff crossing a yard usually fall under different rules.
• What counts as compliant, including partial and incorrect wear.
• What happens on a detection. A live alarm, a shift summary and an anonymized weekly trend are three different products with three different accuracy requirements.

That last point decides the project's difficulty more than the model does. A weekly compliance trend tolerates individual errors because they average out. A real-time alarm does not: a false alarm every few minutes gets the system muted within a week.

Build or buy#

This is the decision most teams make implicitly and should make explicitly, because the vendor market for finished safety products is genuinely good and the build case is genuinely narrower than it looks.

Buy a safety platform when your problem is a safety program rather than a vision problem. If you need incident review workflows, EHS reporting, corrective-action tracking, sign-off trails and someone else's implementation team on site, buy. These vendors have built years of workflow around the detection, and the detection is the smaller part of what you are paying for.

Build when the constraint is something a product cannot bend to. In practice that means:

• Cameras and infrastructure you already own and will not replace, especially non-standard optics, thermal, or feeds already flowing through your own systems. - A site-specific rule no product ships: your own part, your own machine, your own procedure. - A strict on-premise or air-gapped requirement, where footage cannot leave the site at all. - You are shipping a product. If safety monitoring is a feature of something you sell (a machine, a robot, a camera, a site platform) you are a builder, not a buyer. - Integration is the whole job, because the detection must land inside an existing PLC, SCADA, access-control or MES flow rather than a vendor's dashboard.

If none of those apply, buying is usually faster and cheaper, and it is the honest recommendation.

Safety platform vendors worth shortlisting#

These are finished products with deployment teams and EHS workflow. Ultralytics is not an alternative to them; it is what a team uses when it is building rather than buying.

Intenseye. An enterprise EHS vision platform covering PPE, ergonomics, housekeeping and vehicle-related risks across large multi-site footprints. Its strength is breadth of pre-built use cases and the EHS program layer around them. Best fit for large industrial organizations with a mature safety function. Trade-off: enterprise scope and process, not a lightweight deployment.

Protex AI. A privacy-preserving safety intelligence platform that connects to existing CCTV and surfaces risk events and trends. Its strength is the analytics and prioritization layer: helping safety teams see where risk concentrates rather than only firing alerts. Best fit for organizations with existing camera estates. Trade-off: designed around its own workflow rather than deep custom integration.

viAct. Strongest coverage of construction and heavy-civil environments, with scenario-based modules for site safety, plus PPE and equipment monitoring. Best fit for construction and infrastructure projects. Trade-off: construction-oriented modules may fit a manufacturing plant less naturally.

Everguard.ai. Combines vision with wearable and sensor data for worker-safety awareness, targeting heavy industry such as steel. Its strength is multi-sensor fusion rather than cameras alone. Best fit for high-hazard heavy industrial settings. Trade-off: the wearable component adds rollout and change-management work.

Visionify. Focused on a catalogue of workplace-safety vision applications deployable on existing cameras. Its strength is a defined use-case library that keeps scoping simple. Best fit for teams wanting a specific safety use case running quickly. Trade-off: narrower platform surface than the enterprise EHS suites.

Groundlight. Takes a different approach, letting teams define visual questions in natural language with human escalation when the model is unsure. Its strength is speed to a working check without assembling a dataset first. Best fit for teams validating whether a visual check is even feasible. Trade-off: the escalation model suits intermittent checks better than continuous high-volume monitoring.

Building safety monitoring with Ultralytics YOLO models#

For teams in the build column, the vision layer is the part that is now well-solved. Ultralytics YOLO models (YOLOv8, YOLO11 and YOLO26) cover the tasks in the table above: object detection for PPE and equipment, tracking for zone and vehicle logic, pose estimation for posture and fall detection, and segmentation where boundaries matter more than boxes.

A workable build looks like this.

Start from the rule, not the model. Write the rule in enforceable language, define the zone in real-world coordinates, and decide what a detection triggers. This is the step that gets skipped and the reason most pilots stall.

Collect from the cameras you will actually use. A model trained on public PPE datasets and deployed on your yard camera at dusk will disappoint. Your own footage (night shift, rain, backlight, the awkward angle nobody wanted to remount) is the dataset that matters. Ultralytics Platform can annotate that footage with SAM-based Smart Annotation and train on it without moving the data into a separate system.

Choose the deployment target early, because it constrains the model. A model running on a small edge device next to the camera has a different size and latency budget from one running on a site server handling twenty streams. Ultralytics models export to formats including ONNX and TensorRT for that reason, and the export target should be fixed before you tune for accuracy you cannot deploy.

Put the logic above the model. Detections are not violations. The layer that converts boxes into events (persistence over N frames, zone geometry, exemptions, shift schedules, debouncing) is where the false-alarm rate is actually controlled, and it is normal for it to be more code than the model integration.

Route alerts where people already work. A dashboard nobody opens is not a control. Existing channels, existing shift handovers, existing corrective-action systems.

Plan for retraining. Sites change: new equipment, new vest colour, a camera repositioned, seasonal light. Production monitoring exists to catch the resulting drift, and the loop back to annotation and retraining should be a routine, not an incident.

On licensing, one thing to settle before a pilot becomes a product: Ultralytics YOLO models are offered under AGPL-3.0, and commercial or proprietary deployments generally need an Ultralytics Enterprise licence. If safety monitoring is going into a product you ship or a system you cannot open-source, resolve that at the start rather than after the build.

Privacy, consent and worker monitoring#

This determines whether a safety system survives its first month, and it is not primarily a technical question.

Safety monitoring does not require identifying anyone. Every task in this guide (PPE compliance, zone intrusion, crowd density, posture) works on anonymous person detections. None of it needs facial recognition or identity matching, and Ultralytics does not recommend building worker identification into safety systems. Detect the condition, not the person.

Practical constraints to design in from the start:

• Purpose limitation. A system installed for safety should not quietly become a productivity monitor. Once workers believe it has, cooperation stops.
• Consultation. In much of the EU, camera-based worker monitoring requires works-council involvement, and in many jurisdictions it requires consultation, notice or both. This is a precondition, not a formality.
• Data minimization. Prefer counts and events over stored footage. Where clips are retained, retain them briefly and for a stated reason.
• Aggregate reporting by default. Zone-level and shift-level trends drive improvement. Individual-level compliance scoring turns a safety tool into a disciplinary one and destroys trust.
• Local processing where possible. On-premise or on-device inference keeps footage on site and removes a whole class of compliance argument. This is a common reason teams build rather than buy.
• Access control and audit. Who can see footage, who can export it, and what is logged.

The organizations that get value from this technology treat it as a way to find hazardous patterns (this crossing is used unsafely on night shift, this zone is entered whenever that machine jams) not as a way to catch individuals.

Why demo accuracy does not survive a real site#

Every vendor demo works. The gap between a demo and a deployment is predictable enough to plan for.

Detection quality falls with distance and resolution: a person occupying thirty pixels of height is a much harder detection than one filling the frame, and a hard hat on that person is harder still. Lighting is the second reliable disappointment: dusk, headlights, welding arcs, mixed sodium and LED lighting, and rain on the lens all degrade models trained on clean daylight footage. Occlusion is the third: real sites are full of people behind machinery, racking and each other.

Then there is the association problem again. In a group, correctly attributing equipment to individuals is where PPE systems generate most of their false positives, and it is the metric worth demanding in a pilot.

Run the pilot accordingly. Insist on your own footage, your own worst camera, and your night shift. Measure false alarms per shift rather than accuracy on a curated test set, because false alarms per shift is what determines whether the system is still switched on in three months.