Facial Recognition at Work: What Brazil's LGPD Requires

Facial Recognition at Work: What Brazil's LGPD Requires

Facial recognition at work is the processing of sensitive personal data under Brazil's LGPD. That means it needs a specific purpose, a legal basis from the list in Article 11, and a showing that less intrusive alternatives do not solve the problem. If you know GDPR, the logic will feel familiar: biometric data used to identify a person sits in a stricter tier than ordinary personal data. In practice, facial recognition tends to be defensible in narrow security and authentication cases, and hard to justify for time clocks or routine monitoring. Before you contract any solution, define the problem, test a simpler method and document the decision.

Key takeaways

• Biometric data is sensitive personal data under the LGPD's own definition, and the list of legal bases for sensitive data is shorter than the list for ordinary data.
• Legitimate interest, widely used in other contexts, is not among the Article 11 grounds, so it should not be your main bet for biometrics.
• Employee consent is fragile because of the power imbalance: if a person cannot refuse without consequences, the consent is hardly free.
• Necessity and proportionality weigh more than the technology: if a badge, a password or an app solves the problem, facial recognition tends to be excessive.
• Anyone who decides to adopt it needs an impact assessment, a clear vendor contract, a defined retention period and a channel for people to exercise their rights.

Why is facial biometrics sensitive data under the LGPD?

In Article 5, the LGPD defines sensitive personal data as data about racial or ethnic origin, religious belief, health, sex life, genetic or biometric data, among others, when linked to a natural person. The image of a face is personal data on its own. Once it is converted into a mathematical template used to identify someone, it becomes biometric data, and therefore sensitive.

The reason for the stricter treatment is practical. A leaked password can be changed. A face cannot. If a company's database of facial templates is compromised, the harm to the person has no simple remedy. Facial recognition also makes it possible to identify people at a distance and without interaction, which widens the risk of use for purposes nobody agreed to.

It helps to separate two things that often get mixed up. Verification compares the face of the person presenting themselves with the template of one specific person (one to one). Identification searches for the person across a whole database (one to many). The second is more invasive, needs stronger justification and usually concentrates more risk. When you talk to vendors, ask which of the two the product really does and where the templates are stored.

When is a legal basis possible?

For sensitive data, Article 11 of the LGPD lists the grounds. These are the ones that come up most in discussions about facial recognition (confirm the fit with legal counsel, because the analysis depends on the case):

• Specific and prominent consent, for specific purposes (Art. 11, I).
• Compliance with a legal or regulatory obligation by the controller (Art. 11, II, a), when a rule genuinely requires the identification.
• Regular exercise of rights, including in a contract (Art. 11, II, d), read carefully so it does not become a generic excuse.
• Protection of the life or physical safety of the person or of third parties (Art. 11, II, e).
• Fraud prevention and security of the data subject in identification and authentication processes in electronic systems (Art. 11, II, g), safeguarding the data subject's rights.

The fraud prevention and authentication ground is the one most often cited for apps and digital sign-ups, where a person confirms they are who they claim to be. It is harder to apply to routine internal uses, such as logging presence at a front desk or during working hours. Here we are separating what the law says (the text of Article 11) from interpretation: the view that the fraud ground covers this or that scenario is a legal assessment, not a ready-made rule.

The principles in Article 6 apply under any ground: purpose, adequacy, necessity, transparency, security and prevention. Necessity in particular requires using the minimum data needed to reach the goal. That principle is what pushes the decision toward less intrusive alternatives.

Does employee consent solve it?

In most cases it should not be the only support. Consent under the LGPD must be free, informed and unambiguous, and under Article 11 it must also be specific and prominent. Between employer and employee there is a power imbalance: if refusing facial recognition means losing access, being singled out or suffering a disadvantage, the freedom of the choice is in doubt. This is a widely discussed risk reading and not an express prohibition, so get a legal opinion before relying on it.

If the company still chooses consent, a few precautions reduce the risk:

• Offer a real and equally practical alternative (badge, code, app), with no penalty for those who decline.
• Explain the purpose, the retention period, who has access and how to withdraw.
• Record the consent separately from other terms of the employment contract.
• Allow withdrawal as easily as it was given, and delete the facial template when that happens.

The same reasoning applies to visitors, customers and contractors. People outside the company have more freedom to refuse, but they must be told before entering the monitored area, not after.

Which less intrusive alternatives should you consider first?

The business question is almost never "which camera should we buy". It is "how do we know who came in" or "how do we prevent fraud at sign-up". Use this order as a decision guide, stopping at the first method that addresses the real risk:

• Control without sensitive personal data: proximity card badge, physical key, individual password or a short-lived QR code.
• App authentication: login with a second factor on the person's own phone, with no central database of faces.
• Local verification: when biometrics are used, prefer the kind stored on the data subject's own device and not on a company server (check whether the design fits your case).
• Human check: a receptionist or supervisor checks an ID document in occasional higher-risk situations.
• Facial recognition with one-to-one verification, in a restricted flow, with a clear legal basis and an impact assessment.
• One-to-many identification: last resort, only with strong justification, a short retention period and robust governance.

If the goal is to track team performance or attendance, the problem is usually in how the measurement is designed, not in a lack of biometrics. The article on how to measure AI productivity without surveillance covers that boundary in more detail.

What checklist should you follow before contracting?

A short step-by-step list helps avoid impulse purchases. Each step should produce a record you can show later.

• Describe the problem in one sentence without naming a technology: which risk, in which place, for whom.
• List the alternatives from the previous section and note why each one is not enough, if that is the case.
• Define the specific purpose and the intended legal basis, with a legal opinion.
• Prepare the data protection impact assessment (Article 38 of the LGPD provides that the ANPD, Brazil's data protection authority, may request it) and review the risks.
• Appoint the data protection officer and confirm that the channel for data subjects is active (Art. 41).
• Require from the vendor: where the data lives, who accesses it, encryption, retention period, deletion policy, subcontractors and incident response.
• Check whether data is sent abroad. The article on international data transfer when using AI providers shows what to verify.
• Define who can review a recognition error. If a failure denies access or produces a decision against the person, the right to review under Article 20 may be relevant, as we explain in automated decision-making under the LGPD.
• Inform the person before the processing starts, with a clear notice on site and in the privacy policy.
• Plan for an incident: if the template database leaks, who notifies the ANPD and the data subjects (Art. 48) and within what internal deadline.

Illustrative scenario: access to an equipment room

Imagine a mid-sized company that keeps valuable equipment in a restricted room and wants to know who goes in. A vendor's first proposal is to install cameras with facial recognition at the door.

Following the guide above, the company starts with the problem: the risk is improper removal of equipment, and what it needs is a reliable record of who accessed the room and when. An individual proximity card, with an access log and a periodic review of who holds permission, meets the need without processing any sensitive data. For removing higher-value items, a human check with a signature handles the rest.

Facial recognition would only return to the table if the card pilot showed a concrete failure, such as people lending cards to each other. Even then, it would come in as one-to-one verification, only at that door, with an alternative for anyone who declines and with an impact assessment before the system is switched on. This is an illustrative scenario, not a real case.

How to map, limit, pilot and hand over on this topic

The method we use in AI projects applies here with little adaptation. Mapping means describing the current process and the risk that motivated the idea, including the controls that already exist. Limiting means deciding which data goes in and which actions the system may take: for example, only verify, never identify in bulk, and never decide alone on a sanction against a person.

Piloting means testing a small, real flow, with logs, an agreed success indicator (rate of wrongly denied access, queue time, incidents) and a criterion for stopping. Handing over means transferring the operation with named owners, documentation and an explicit decision to expand, adjust or end. If the pilot does not show a clear gain over the simple alternative, ending it is also a valid result.

If the solution involves AI models that process images, it is worth following the ongoing regulatory debate. The article on Brazil's AI regulation and what companies should do points to what to watch. As a comparative reference, the European AI Act treats the use of biometrics as an area of special attention, which helps show where the discussion is heading.

Frequently asked questions

Does the LGPD ban facial recognition at work? There is no general ban in the text of the law. What exists is a stricter regime for sensitive data: you need an Article 11 legal basis, a specific purpose, demonstrated necessity and security measures proportionate to the risk.

Can I use facial recognition for employee time tracking? It is a high legal risk use, because necessity is hard to prove when less intrusive methods exist and because employee consent is fragile. Before adopting it, assess alternatives, consult employment and data protection counsel, and carry out the impact assessment.

Does the company need an impact assessment to use biometrics? Article 38 of the LGPD provides that the ANPD may order an impact assessment, and in practice it is the best way to show that risks and alternatives were evaluated. For sensitive data processed at scale or with significant risk, treating it as mandatory internally is the safest stance.

What if the vendor stores the faces in another country? Treat it as an international transfer and check the mechanism the LGPD allows, in addition to the contract and the security measures. Ask the vendor for the server locations, the list of subcontractors and the deletion policy, and record everything in the impact assessment.

Sources

• Planalto: Lei Geral de Proteção de Dados Pessoais (Lei 13.709)
• ANPD: Autoridade Nacional de Proteção de Dados
• NIST AI Risk Management Framework
• EU Artificial Intelligence Act overview