A question we hear regularly: 'isn't face recognition on retail CCTV basically incompatible with UK GDPR?' The short answer is no, but the longer answer is that whether it is compatible or not is entirely determined by architectural choices made on day one. Retrofitting compliance onto a face-recognition system that wasn't designed for it is essentially impossible.
This post is a walk-through of how QuantumEye is built so that a face-recognition deployment is something a retailer can put in front of their DPO without flinching. None of this is secret architecture, there is value in being explicit about it because it is also the answer to whether the system can be trusted.
Principle 1. Vectors and video are stored separately
A face embedding is a 512-dimension biometric vector. A video clip is also biometric data, in a different form. Both are subject to the same special-category rules under UK GDPR. They should not share a database row, a storage object, or an access control boundary.
In QuantumEye, the vector lives in a managed vector index (S3 Vectors / Qdrant). The video lives in object storage (S3). Neither knows about the other directly; the connection is by an opaque individual identifier, dereferenced through an authorisation-gated lookup. Right-to-erasure can act on each side independently. We wrote up the architecture in more detail in a previous post.
Principle 2. Recognition ≠ identification
A high-confidence vector match surfaces a candidate. A human reviewer accepts or rejects before any identity is attached, any ban is applied, or any consequential action is taken. The split between recognition (what the model does) and identification (what a human authorises) is structural, not procedural. RBAC is enforced server-side.
This is why we will not build an automated ban-list pipeline. The bottleneck, a human pausing to look at the candidate, is the feature, not a bug.
Principle 3. Retention is bounded and category-aware
- Non-matched face data: 30 days by default, then purged.
- Whitelisted staff / contractor profiles: retained for the duration of the engagement, then soft-deleted on retirement.
- Banned individuals: retained while the ban is active, plus a configurable grace period, then soft-deleted.
- Right to erasure: soft-delete on the individual record, with vector and video deleted independently per the request.
Soft-delete preserves the audit trail without preserving the biometric data. That is the right answer for a surveillance product, the integrity of the audit log is separable from the persistence of identifiable face data.
Principle 4. Edge inference, not cloud streaming
Face detection and embedding happen at the edge, on a per-store node, on the same network as the cameras. The raw face crop never leaves the building. Only the 512-dimension vector goes to the cloud, and only when there is a recognition event worth persisting.
This matters for two reasons. First, it dramatically reduces the surface area of personal data being transmitted (the embedding is biometric, but it is not a face crop a human can reconstruct). Second, it makes the DPIA fundamentally easier, raw video does not transit between data centres or jurisdictions.
Principle 5. Append-only audit log
Every status change on every event writes to an append-only audit log. The log records who did what, when, with which role, against which event, and against which individual. The log cannot be updated. It cannot be deleted. If it could, it would not be an audit log.
The log is the legal artefact. The defensibility of any consequential decision (a ban, a police forward, a status reversal) rests on the integrity of the chain that produced it.
Principle 6. Camera stream URLs are encrypted at rest
Camera RTSP URLs are encrypted using a data-encryption key, per store, managed by AWS KMS. Plaintext RTSP URLs do not exist in the database. This is a small detail with an outsized blast-radius implication if it is not done, the compromise of an unprotected DB row would otherwise hand an attacker a live video feed of the store.
Principle 7. RBAC enforced server-side
Roles are enforced where the decision happens, not in the UI. A Store Manager cannot approve a banning action. A QE Administrator must. The UI hides what the user cannot do, but the backend would refuse the request anyway.
What we tell DPOs to ask for
If you are a retail DPO being asked to sign off on a face-recognition deployment, here is the short list of things to ask the vendor for:
- An architecture diagram showing vector storage and video storage as separate boxes with an authorisation layer between them.
- The retention policy by data category, with concrete numbers (days, not adjectives).
- Proof that consequential actions require a human authorisation, and proof that the authorisation is enforced server-side.
- The audit log schema and its append-only guarantee.
- ICO registration number, ISO 27001 certificate number, and the certifier (verify it independently).
- Data residency, where compute and storage live, in which region.
QuantumEye publishes answers to all six on the trust centre, and we share the full DPIA template with retailers under NDA. The thinking behind these decisions is the product. We would rather you stress-test it with your DPO before signing than discover the gap later.