We have twice been asked to build camera-based safety monitoring for organisations that had already tried and abandoned it. In both cases the technology had worked. The deployment failed because the workforce objected to being continuously recorded, and they were right to.
POPIA is not the obstacle here. It is a useful design brief.
Process on the edge, not in the cloud
The single most important decision is where inference runs. If frames leave the site to be processed centrally, you have created a repository of identifiable footage of employees, with all the retention, access-control and breach obligations that follow.
Running inference on edge hardware at the site means frames never leave. Only structured events do — a timestamp, a detection type, a camera identifier, a confidence score. That is a few hundred bytes rather than a video stream, and it is not personal information in the same sense.
Anonymise before persistence, not after
"We blur faces before storing" is only meaningful if the unblurred frame never touches disk. If the pipeline writes the frame, then blurs it, then deletes the original, you have written identifiable data to storage and are relying on deletion working correctly.
We blur in memory, in the inference pipeline, before any write. The unblurred frame exists only for the duration of the forward pass. This is a demonstrable property of the code rather than a policy commitment, and that difference matters enormously in a consultation.
Detect behaviour, report in aggregate
There is a real distinction between "detect that someone in area 4 is not wearing a hard hat" and "detect that a specific employee is not wearing a hard hat". The first supports a coaching conversation with the area supervisor. The second creates a disciplinary surveillance system.
We build the first deliberately. Reporting is aggregate by area and shift, with no individual attribution. This limits some use cases and it is the reason the system is accepted rather than resisted.
Consult before you build, and show the code
On the gold-mine deployment, the privacy architecture was presented to organised labour and the health and safety committee before development started, and their technical representative reviewed the anonymisation step in the source.
That review was the project's turning point. A promise about data handling is worth very little to someone who has been promised things before. A demonstrable pipeline they can inspect is a different conversation entirely.
Retention has to be enforced, not documented
A retention policy in a document is a policy. A retention policy enforced by a scheduled job that deletes records past their retention period, with the deletion logged, is a control.
Regulators, auditors and unions all distinguish between these two things. Only one of them survives scrutiny.
The practical checklist
Before deploying any camera-based system, we work through: where does inference run; does an identifiable frame ever reach persistent storage; what exactly is transmitted off site; is reporting aggregate or individual; who was consulted and what were they shown; is retention enforced in code; and can every one of those answers be demonstrated rather than asserted.
Projects that can answer all seven get deployed. Projects that cannot should not be.