Facial Recognition and Biometrics
Biometric verification and identification built to the standard the technology demands: legal basis established first, accuracy tested across demographic groups, liveness handled, and templates protected rather than stored as images.
This is the service in our catalogue we decline most often, and we would rather say that plainly than take the work and hope the questions do not arise. Biometric data is special category data in most jurisdictions, the technology has a documented history of performing unevenly across demographic groups, and several proposed uses are simply unlawful in the markets our clients operate in.
Facial recognition and biometric systems verify that a person is who they claim to be, by comparing a live sample to a stored template, or identify a person by searching a database of templates. Verification is one-to-one and comparatively narrow; identification is one-to-many and carries substantially higher risk, legal exposure and error consequence.
Verification and identification are not the same request
| Verification (1:1) | Identification (1:many) | |
|---|---|---|
| Question asked | Is this the person who enrolled? | Who is this, from a database? |
| Consent | Normally explicit and obtainable | Often impossible to obtain from those searched |
| Error consequence | Legitimate user is inconvenienced | Wrong person is identified and acted against |
| Regulatory position | Widely permitted with safeguards | Restricted or prohibited in several jurisdictions |
| Our position | We build these | Only with a clear lawful basis and narrow scope |
Most business requirements that arrive described as facial recognition are verification: unlocking access, confirming an enrolled customer, matching a person to their own document. Those are tractable and defensible. Identification against a watchlist is a different undertaking and we assess it case by case, including whether to decline.
What a responsible build includes
Legal basis before architecture
Biometric data is special category data in most privacy regimes, requiring an explicit condition for processing, usually a data protection impact assessment, and in several jurisdictions specific restrictions on public spaces, employment and law enforcement. Some proposed deployments cannot lawfully be built, and establishing that in week one is the most valuable thing we do.
Demographic accuracy testing, published internally
Accuracy is measured separately across demographic groups on a test cohort that reflects your actual population. Uneven performance across skin tone, age and gender is a well-documented property of this technology, and a single headline accuracy figure conceals exactly the failure that causes harm and complaint.
Liveness and presentation attack detection
A system that accepts a photograph, a screen or a mask is not a security control. Liveness detection is tested against real presentation attacks rather than assumed, and the results are reported honestly including what still gets through.
Protect the template, never the image
Store irreversible templates rather than face images, encrypted at rest, ideally on the user's own device. Biometrics cannot be reissued after a breach: a compromised password is changed in a minute and a compromised face is permanent, which is why the storage design carries more weight here than anywhere else.
A fallback that is not a punishment
Every biometric system fails for some legitimate users, and disproportionately for some groups. A dignified, equally available alternative is a design requirement, not a courtesy, and in several jurisdictions it is a legal one.
Enrolment, revocation and subject rights
How people enrol, how they withdraw, how templates are deleted on request and how that deletion is evidenced. These processes are what a regulator will examine, and they are usually the least designed part of a biometric deployment.
Ask what happens when it is wrong about a person
For verification, a legitimate user is inconvenienced and uses the fallback. For identification, a person may be stopped, refused service or reported on the basis of a machine's mistake. The second scenario needs a documented human review step before any consequence, and if nobody will own that step, the system should not be built.
Where we will and will not build
- We build: opt-in verification for access, devices and accounts; identity document matching with consent; enrolled-user convenience features with a fallback; time and attendance where consultation obligations are met.
- We assess carefully: retail or venue watchlists, employee monitoring, anything involving minors, and any identification use in a public space.
- We decline: covert identification without a lawful basis, emotion inference presented as fact, demographic inference for targeting, and any deployment where the client will not commit to demographic accuracy testing.
That last one matters. A supplier who will not test accuracy across groups is a supplier who does not want to know, and we would rather lose the work than deliver a system whose failures land unevenly.
How the engagement runs
Legal viability is settled first; if it fails, the engagement stops there and you keep the assessment.
Legal and ethical assessment
Lawful basis, impact assessment, jurisdictional restrictions and a written recommendation on whether to proceed at all.
Requirements and test cohort
Verification or identification scope fixed, fallback designed, and a demographically representative test cohort assembled with consent.
Matching and liveness
Matching engine selected and tuned, thresholds set per error cost, liveness tested against real presentation attacks.
Accuracy and fairness testing
Performance measured per demographic group, disparities reported, thresholds reviewed against them.
Deployment and governance
Template protection, enrolment and revocation, audit logging, and the governance pack for your DPO and regulator.
What you receive
A system that can be defended in front of a regulator, or an honest recommendation not to build it.
Legal and ethical assessment
Lawful basis, impact assessment, restrictions by jurisdiction and the proceed or stop recommendation.
Matching system
Deployed verification or identification with thresholds justified by error cost.
Demographic accuracy report
Performance by group on a representative cohort, with disparities stated plainly.
Liveness testing
Presentation attack results including what still succeeds, not only what is blocked.
Template protection design
Irreversible templates, encryption, storage location and breach response.
Governance pack
Enrolment, revocation, subject rights, retention, audit logging and the fallback process.
Is this the right engagement?
Worth being direct. Facial Recognition and Biometrics is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- The use is verification of enrolled, consenting users.
- Legal and your data protection officer can engage from week one.
- You will commit to demographic accuracy testing and act on the results.
- A dignified fallback is acceptable and will be resourced.
- Template protection and deletion processes can be owned operationally.
Choose something else if
- The use is covert identification without a lawful basis.
- The deployment is restricted or prohibited in your jurisdiction.
- The requirement includes emotion or demographic inference presented as fact.
- Nobody will own the human review step before a consequence is applied.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
Is facial recognition legal?
It depends entirely on the use and the jurisdiction. Opt-in verification of enrolled users is widely permitted with safeguards. Identification against a database in public spaces is restricted or prohibited in several markets, and employment use frequently carries consultation obligations. We establish the position in the first three weeks and will tell you if the answer is that it cannot lawfully be built.
Does facial recognition work equally well for everyone?
Historically it has not, and uneven performance across skin tone, age and gender is well documented. Modern systems are better and the disparity has not disappeared, which is why we test on a cohort representing your actual population and report per-group results rather than a single figure.
What is liveness detection and do we need it?
It distinguishes a live person from a photograph, screen or mask. Without it a face-matching system is not a security control. We test it against real presentation attacks and report what still succeeds, because no liveness system is perfect and you should know its limits before relying on it.
Where are the face templates stored?
Preferably on the user's own device, and otherwise as irreversible encrypted templates rather than images. Biometrics cannot be reissued after a breach, which makes the storage design the most consequential decision in the build.
Will you build a watchlist identification system?
Only with a clear lawful basis, a narrow defined scope, demographic accuracy testing and a documented human review step before any consequence is applied to a person. Where those conditions are not met we decline, and we will explain why rather than propose a workaround.
Often paired with this
Most clients combine two or three engagements from the Computer Vision pillar. These are the ones that most often run immediately before or after.
Video Analytics and Surveillance AI
Video analytics tuned against alert fatigue, with tracking across cameras and privacy designed in from the start.
Read more →Pose Estimation and Activity Recognition
Movement and activity understood over time, using skeletal data that needs no identifiable footage.
Read more →Object Detection and Image Classification
Detection and classification models trained on your own images, with honest labelling and cost-weighted thresholds.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.