“Face recognition computer vision” is sold as one product category. In practice it names two capabilities with different cost, accuracy and legal profiles: detecting that a face is present, and matching that face to an identity in a gallery. Most procurement trouble starts when a single vendor accuracy figure is accepted as the answer to both.
The practical definition is short. Detection answers “is there a face here, and where?” Recognition answers “whose face is this?” — which requires a stored numerical representation of the face (an embedding), a gallery of enrolled identities to compare it against, and a similarity threshold that decides when a comparison counts as a match.
How is face detection different from face recognition?
Detection can be tuned and tested on your own footage before you buy anything. You can run candidate models against your cameras, at your angles, under your lighting, and count the misses yourself. Identity matching cannot be evaluated that way, because its accuracy is a property of your gallery — enrolment image quality, how many identities it holds, how stale it is — and of the operating threshold you choose, not of the model in isolation.
| Face detection | Face recognition (identity matching) | |
|---|---|---|
| Question answered | Is a face present, and where? | Which enrolled person is this? |
| Needs a gallery | No | Yes |
| Stores biometric data | Not necessarily | Yes — embeddings are biometric |
| Testable on your own footage pre-purchase | Yes | Only partially; depends on gallery |
| Tuning knob that dominates results | Model choice, resolution, framing | Similarity threshold and gallery quality |
| Typical legal weight | Ordinary video processing | Biometric identification duties |
A vendor’s headline accuracy number is almost always a figure from a public evaluation set at an unstated threshold. It tells you the model is competent on that distribution. It tells you nothing about your false-match rate at your chosen threshold on your population, which is the number acceptance testing actually needs.
Where processing becomes biometric identification
The divergence point is concrete: the moment a face embedding is stored and compared against a gallery, the system is performing biometric identification. That is the line where GDPR’s special-category rules, US state biometric statutes such as BIPA, and the EU AI Act’s risk tiering begin to govern the deployment — not the moment a camera is installed, and not the moment a bounding box is drawn.
The practical consequence: if your use case is counting people, checking that a face is present and in-frame for a document photo, blurring faces for privacy, or measuring queue length, you do not need identity matching. Scoping the smaller system removes gallery management, consent handling and re-identification review from the programme entirely. We see teams specify recognition when presence detection was the requirement more often than the reverse, and unwinding that later is expensive.
Where matching genuinely is required, name the operating threshold and its false-match rate in the specification before the pilot. In our engagements, that single scoping distinction typically reduces the vendor shortlist that survives technical review to a handful, before any pilot spend — an observed pattern from selection work, not a benchmarked figure.
The embedding stage itself is a learned representation problem, which is why it shares methodology with vector-search and representation work rather than with classical detection. That is also why the two halves of a “face recognition” system rarely come from the same engineering discipline.
For the full four-stage pipeline — detection, alignment, embedding, matching — and how each stage fails, see our computer vision engineering practice.
Before funding a pilot, the question worth settling is not which vendor scores highest, but whether your use case ever needs an identity at all.
