If you're evaluating a face-recognition product, here is the single most important architectural question you can ask: where does the face embedding live, and where does the video clip live? If the answer involves both being in the same row or the same object, the rest of the security claims are on shaky ground.
Why the separation matters
A face embedding is a 512-dimensional vector. It is biometric data. A video clip is also biometric data, in a different form. Under UK GDPR, both are subject to strict rules around storage, retention, and right to erasure.
When you store them together, three things go wrong:
- Right to erasure becomes coupled, you can't delete the vector without deleting the clip, even when the retention requirements differ.
- Access control becomes coupled, anyone who can read the row can read both, even if their role only justifies one.
- Anonymisation becomes harder, blurring the face in the clip doesn't help if the vector is still right next to it.
How QuantumEye separates them
Face vectors live in S3 Vectors (Qdrant) under an index that is access-controlled separately from any video storage. Video clips live in standard S3 buckets, also separately access-controlled. The connection between the two is by reference, a vector match returns an individual ID, which can then be used to fetch the relevant clips, subject to a separate authorisation check.
What this looks like in your DPIA
If you're writing a Data Protection Impact Assessment for a face-recognition deployment, the architecture diagram needs to show vector storage and video storage as separate boxes, with the connection between them flowing through an authorisation layer. Anyone evaluating the DPIA will look for exactly this.
QuantumEye's architecture is built to make that DPIA easier, the separation is fundamental, not bolted on.