“Face recognition in computer vision” is not one capability. It is a label stretched across at least four different engineering tasks, and the choice between them decides the gallery you keep, the threshold you operate at, the error metric that describes the system, and the legal classification of the data you store. Ask a vendor for “face recognition accuracy” and you get a number that describes none of them properly.
The four tasks are worth naming plainly, because requirements documents routinely collapse them:
| Task | What it answers | Gallery needed | Metric that describes it |
|---|---|---|---|
| Face detection | Is a face present in this frame? | None | Precision / recall on face presence |
| 1:1 verification | Is this the person they claim to be? | One reference template per claimed identity | FAR and FRR at a fixed operating threshold |
| 1:N identification | Who is this unknown face, if anyone? | Enrolled gallery of N identities | False-match rate per search, degrading with N |
| Face clustering | Which of these faces are the same person? | None (no identity labels) | Cluster purity / completeness |
How does face detection differ from face recognition?
Detection localises a face region. Nothing about identity is asserted, and nothing needs to be retained — an OpenCV or ONNX-exported detector can count faces, blur them, or trigger a downstream process without ever producing a comparable identity representation. Recognition, in either the verification or identification sense, requires an embedding: a numeric vector derived from the face and stored for comparison.
That storage step is the divergence point. The moment a template or embedding is retained and compared against a gallery, a detection feature becomes biometric identification — and that is where GDPR’s special-category rules, Illinois BIPA, and the EU AI Act’s risk tiering begin to apply. The boundary is not the model architecture or the accuracy figure; it is template retention.
Why the task choice changes what you measure
Verification and identification fail in different shapes. A 1:1 verification system is scoped by false-accept and false-reject rate at a chosen threshold, and both are stable properties of that threshold. A 1:N identification system inherits a per-search false-match rate that grows with gallery size, so a vendor figure quoted against a 500-identity gallery tells you very little about behaviour at 50,000. Specify the task, the gallery size, and the operating threshold in the RFP and you avoid re-running the whole vendor evaluation after the first pilot.
The other saving is structural. Some requirements — occupancy counting, privacy blurring, “was anyone at the door”, queue-length estimation — are satisfied by face-presence detection with no template retention at all. Buying a biometric identification system for those is a compliance cost with no functional return. We see this pattern regularly in early scoping calls, where the stated need is recognition and the actual need is detection.
Each of these four decisions sits at a different stage of the usual detection → alignment → embedding → matching pipeline: detection ends at stage one, clustering stops before matching against labels, verification and identification differ only in the shape of the gallery at stage four. Our computer vision engineering practice covers how those stages are built and where they degrade in deployment.
Before asking how accurate a face recognition system is, it is worth asking which of the four tasks the number belongs to — and whether the system needs to keep a template at all.
