Video monitoring with AI analytics turns up in a specific kind of conversation: a warehouse operator wants automated safety-zone alerts, a call centre wants to flag disengaged agents, a logistics firm wants proof of who accessed a loading bay. The technical ask is usually straightforward. The part that gets underestimated is that the moment a camera feed is analysed to say something about a named or identifiable person, the project is no longer just a computer vision problem. It is a data protection problem with a computer vision component attached.
We build this kind of system as part of our Webcam Platform work, and the legal questions come up before the technical ones almost every time. This is a walk through what UK GDPR actually requires, written for whoever has to sign off the project, not for a compliance department that does not exist yet.
Why this is stricter than CCTV
Plain CCTV recording to a hard drive that nobody reviews unless there is an incident sits in relatively well-understood territory. Add AI analytics and the calculation changes on two fronts.
First, the processing becomes continuous and automated rather than incidental. Software that scores attentiveness, flags loitering, or clusters faces across a shift is generating new personal data about employees on an ongoing basis, not just storing footage for later human review. Under UK GDPR that counts as monitoring, and the Information Commissioner’s Office treats employee monitoring as a distinct category with its own expectations, separate from general workplace CCTV.
Second, some analytics features edge into special category data. Emotion detection, gaze tracking and anything that infers health, tiredness or mood from facial features can be treated as inferring biometric or health-related information, which carries a higher bar than standard personal data. Face recognition used for identification, rather than just detection, is unambiguously biometric data. Which features you actually need should be decided with that distinction in mind, not added by default because the vendor’s SDK supports it.
Get the legal basis straight before writing a line of code
Employers usually reach for consent as the legal basis, and it is usually the wrong choice. Consent has to be freely given, and an employee cannot meaningfully refuse to be monitored by their employer without consequence for their job. The ICO’s position is that consent is rarely valid in an employment relationship for this reason. Legitimate interests, backed by a documented Legitimate Interests Assessment, is the basis that tends to hold up, but it only holds up if the interest is real, the monitoring is proportionate to it, and less intrusive options were genuinely considered and ruled out.
That means the first project artefact should not be a technical spec. It should be a short document that states the specific problem the monitoring solves, why less invasive measures will not solve it, and what the system will not be used for. That last part matters more than it sounds: a safety-monitoring system that is quietly repurposed for performance management six months later is exactly the scenario regulators and employment tribunals look for.
A DPIA is not optional here
Systematic monitoring of employees at scale, particularly with automated analytics, sits squarely in the category of processing that UK GDPR expects a Data Protection Impact Assessment for. Doing it after the system is built is a common failure pattern: it turns the DPIA into a rubber stamp instead of a design tool, and it means any changes the assessment surfaces become expensive retrofits rather than early decisions.
Run it early enough that it can still shape the architecture. Useful questions to answer in it: what is the retention period and how is it enforced technically, not just in policy; who can access raw footage versus derived analytics, and are those the same permission; what happens to the data if the vendor relationship ends; and can an employee actually find out what has been recorded about them if they ask.
Engineering choices that reduce exposure
Several decisions made at build time do more to keep a deployment defensible than any policy document written afterwards.
- Process on-device or at the edge where possible, so raw video does not need to leave the site or sit in cloud storage longer than necessary.
- Store derived analytics separately from raw footage, with tighter access controls on the raw feed than on aggregate reports.
- Build retention into the system, not the runbook: automatic deletion after the stated period, rather than a policy that assumes someone remembers to purge it.
- Default to aggregate or anonymised outputs (occupancy counts, zone alerts) and only keep identifiable data where the stated purpose genuinely requires it.
- Log who accessed which footage and when, since that log is often what an employer is asked to produce if a complaint is raised.
None of this is exotic. It is the same discipline as any system handling sensitive data, applied consistently rather than bolted on once someone asks about compliance.
Tell people before the cameras go live
Transparency is a legal requirement, not a courtesy. Employees need to be told what is being monitored, why, what is done with the output, and how long it is kept, before monitoring starts. In practice this means a monitoring policy that is actually communicated, not filed in an intranet nobody reads, and for anything beyond passive CCTV, consultation with staff or their representatives before rollout. A system that works perfectly and was never disclosed is still a compliance failure, and it is the kind that surfaces at the worst possible time, usually during a grievance or an employment tribunal claim.
A checklist before you commission this
Before briefing a development partner on an AI-powered monitoring system, you should be able to answer:
- What specific problem does this solve, and did we rule out a less intrusive way of solving it?
- What is our documented legal basis, and does it survive the question “could an employee refuse this without consequence”?
- Has a DPIA been done, or scheduled, before design starts?
- Does any feature we plan to use touch biometric or health-adjacent inference, and do we actually need it?
- Where is raw footage stored, who can access it, and how is retention enforced in the system itself?
- Have employees been told, and consulted where required, before the system goes live?
If any of those answers is “we will figure that out later”, that is the point to pause, not the point to start writing detection code. The technical build is usually the easy part.