Facial recognition is an expression used for very different problems. One is confirming whether the person in front of a device corresponds to a reference that has already been selected. Another is searching for a face in a collection of images. Treating both as the same thing leads to confused projects, weak acceptance criteria and unclear explanations for the people whose data will be processed.
This article addresses the first case, known as 1:1 facial verification. Consider a field team that needs to authenticate a professional before opening a shift, accessing a restricted function or confirming a sensitive step. There is one person present, one reference defined by the workflow and one response that must be interpreted under known rules.
AreaFACE was designed for this setting. It guides capture, can analyze liveness signals on the device and prepares the individual comparison. Its response does not replace the operational rule, the legal assessment or the human path established for inconclusive cases.
1:1 and 1:N answer different questions
In 1:1 verification, the question is limited: does this capture correspond to the reference selected for this authentication? In a 1:N search, the question is different: does this reference appear among several searchable images or records?
| Aspect | 1:1 verification | 1:N search |
|---|---|---|
| References compared | One previously selected reference | A collection of references |
| Typical use | Authenticate one person in a defined workflow | Locate possible matches for further analysis |
| Response | Compatible, incompatible or inconclusive under the adopted rule | A candidate list that requires its own review criteria |
| Controls | Authorized reference, capture quality, threshold and an alternative access path | Search base, purpose, filters, review and treatment of possible matches |
This distinction is not merely about terminology. It changes the architecture, the expected errors, the impact on the data subject and the way processing must be explained. Within the Areatec ecosystem, AreaFACE covers individual 1:1 verification. A 1:N search, when applicable and authorized, belongs to a separate workflow between Olho Vivo City and Olho Vivo Patrol.
Capture quality comes before comparison
A camera pointed at a face does not automatically produce a useful sample. Distance, framing, movement, light, shadows, reflections and the condition of the sensor all affect capture. A well designed field interface therefore starts by guiding the person instead of hiding the process behind a button.
Real time guidance helps correct position and stability while a new image can still be captured. This reduces inconclusive responses and prevents a simple capture issue from being mistaken for an identity mismatch.
The device also matters. A project should be accepted using the camera model, device, application and conditions planned for the street. A result obtained on a test bench does not, by itself, describe performance under side light, low illumination, rain, device movement or prolonged use during a shift.
How a clearly defined 1:1 workflow operates
- The system identifies the context. The operation establishes who is trying to access which function and which reference may take part in that comparison.
- The interface guides capture. The person receives framing and positioning instructions before analysis.
- Available signals are evaluated. Liveness analysis looks for signs of an improper presentation within the coverage tested for the sensor and configuration.
- The capture is compared with one reference. A 1:1 workflow does not search a crowd or an open collection.
- The operational rule interprets the response. The project decides when to proceed, request another capture, use another factor or send the case for review.
This sequence keeps each responsibility in the right place. The mechanism produces signals and a technical response. System policy defines what that response permits. The organization remains responsible for purpose, access, security and the treatment of exceptions.
Liveness reduces one risk, but does not solve every risk
Liveness analysis looks for signals compatible with a person being present in front of the device and for signs of an improper presentation. Its coverage depends on the sensor, configuration, environment and attack types included in acceptance testing.
This calls for precise language. It is not correct to promise infallible protection or to claim that a single mechanism eliminates fraud. A secure deployment must also consider reference protection, application integrity, device control, complementary credentials, event records and incident response.
With AreaFACE, part of the liveness analysis can take place on the device. The complete workflow and the data that leaves the device depend on the architecture approved for each project. The choice between local processing and integrated services should therefore be documented in the technical design, not presented as a universal promise.
Acceptance testing must reproduce the field
An isolated accuracy percentage says very little. To evaluate a facial verification system, the acceptance report should explain what was measured, with which sample, on which device, under which conditions and at which threshold.
Useful measures include:
- False acceptance: how often a person who does not correspond to the reference meets the configured criterion.
- False rejection: how often the corresponding person does not meet the configured criterion.
- Inconclusive response: cases in which quality or available signals do not support an adequate decision.
- End to end latency: the time perceived from capture to the response used by the workflow.
- Liveness coverage: the improper presentation scenarios actually included in testing.
These measures must be examined together. A stricter threshold may reduce certain false acceptances while increasing incorrect rejections. A more permissive threshold can have the opposite effect. The choice only makes sense when the operational impact and case specific risk have been documented.
An inconclusive response needs a safe path
The field is not a laboratory. Glasses, helmets, changes in appearance, reflections, dirt on the lens and difficult lighting can prevent an adequate capture. A person should not be labelled as a fraudster because capture failed.
The workflow should provide a guided retry, another authentication factor or review by an authorized person. It should also record the operational reason without retaining more data than necessary. This path protects both the operation and the people who depend on it.
In the Electronic Citation Device, for example, authentication can be part of opening a sensitive activity. This does not make facial comparison the author of the administrative act. It is one part of a broader chain that includes profile, device, access rule and audit records.
Biometrics requires purpose, necessity and governance
Brazilian LGPD classifies biometric data linked to a natural person as sensitive personal data. Technology alone does not make a project compliant. The controller must define purpose, legal basis, necessity, transparency, access, retention, disposal, security and how data subject rights will be handled.
Before deployment, the project should answer concrete questions:
- Which action needs authentication, and why is another factor insufficient?
- Who selects the reference, and how is its origin verified?
- Which data remains on the device, which data goes to other services and for how long?
- Who can review events, and how is access audited?
- What alternative exists when a person cannot complete verification?
- How will the project identify and correct uneven performance across groups and capture conditions?
The answers should appear in contracts, architecture, privacy notices, procedures and testing. General statements such as compliant by nature or secure by definition do not replace that work.
Human review is not a minor interface detail
When a technical response can affect access, work or a relevant decision, the process should name who reviews exceptions and what information is available. A reviewer should not receive only a green or red signal. They need to understand capture quality, the rule that was applied, the necessary history and the limits of the response.
Review should also remain distinct from automatic confirmation. The comparison is supporting evidence. The final action follows the procedure established by the party responsible for the operation, with a path for challenge and correction when applicable.
Questions to ask in a technical assessment
A sound conversation about facial verification does not begin with a marketing figure. It begins with the real case:
- Is the workflow truly 1:1, or is it trying to search several references?
- Which device and sensor will be used?
- How does the interface guide capture before comparison?
- Which liveness scenarios are included in acceptance testing?
- How will false acceptance, false rejection, inconclusive responses and latency be measured?
- What alternative is available when the response does not permit the workflow to proceed?
- How will purpose, access, retention and disposal be documented?
These questions make it possible to compare proposals without confusing a demonstration with an operation. The AreaFACE page presents the product architecture and its public boundaries for this assessment.
Official sources for further reading
- Brazilian General Data Protection Law, compiled text
- Brazilian Data Protection Authority technology radar on biometrics
- Face Technology Evaluations, an international reference for understanding the evaluation of facial technologies, without implying AreaFACE certification.
By Fábio Eduardo Cressoni Batistella, director at Areatec.
