A European retailer deployed a facial recognition system for loss prevention in 2023. No consent notices. No opt-out mechanism. Eighteen months later, the Swedish data protection authority issued a fine equivalent to roughly €3 million — not because the technology didn't work, but because the legal basis for processing biometric data was missing entirely. The system was switched off. The fine stood. This outcome is not unusual, and it illustrates the central tension in facial recognition deployments: the technical barrier to building the system has fallen dramatically, while the legal and ethical bar for deploying it responsibly has risen just as fast.
The Regulatory Landscape in 2026
Understanding the legal environment is not an optional pre-deployment checkbox. It's the constraint that shapes your architecture. The key frameworks that affect facial recognition deployments globally:
GDPR (EU / EEA)
Facial images that are processed to uniquely identify a natural person constitute biometric data under Article 9 — a special category requiring explicit consent or another narrow legal basis (such as vital interests or specific employment law exceptions). Standard "legitimate interests" balancing — which covers many commercial data uses — is not a valid basis for biometric special-category data. This matters architecturally: if your system identifies individuals rather than just detecting faces, GDPR applies at the strictest tier.
EU AI Act (enforceable from 2025 onwards)
The EU AI Act classifies real-time remote biometric identification in public spaces as high-risk — permitted only for law enforcement under specific judicial authorisation. For commercial deployments in semi-public spaces (retail, offices, transport hubs), the Act imposes conformity assessments, documentation requirements, and human oversight obligations. Prohibited uses include social scoring based on biometric data and retrospective identification from public cameras without specific authorisation.
US State Laws
Illinois BIPA (Biometric Information Privacy Act) remains the most stringent US biometric law, requiring written consent, a publicly available retention policy, and prohibiting commercialisation of biometric data. Texas, Washington, and several other states have passed similar legislation. There is no federal biometric law yet, but the patchwork of state laws means a US-facing deployment needs a compliance map across the states where it operates.
Other Jurisdictions
India's Digital Personal Data Protection Act 2023, Brazil's LGPD, and Singapore's PDPA all treat biometric data as sensitive personal data requiring explicit consent. Canada's PIPEDA (and the forthcoming CPPA) apply similar principles. If your deployment touches multiple markets, your architecture must be flexible enough to accommodate different consent models per jurisdiction.
Consent Architecture: The Foundation
Consent in biometric deployments is not a checkbox on a privacy policy. It needs to be:
- Specific: The user must understand exactly what biometric data is being collected, for what purpose, and for how long.
- Freely given: Consent is not freely given if refusing it means you can't enter the premises or use the product. Offering a non-biometric alternative is often legally required.
- Documented: You must be able to prove consent was obtained, when, and what information was provided at that point.
- Withdrawable: A user must be able to withdraw consent and have their data deleted. Your system must be able to execute this reliably.
Practically, this means building a consent management layer before your first camera goes live — not as an afterthought. The consent record needs to be linked to the enrolled biometric template so that withdrawal triggers deletion across all storage locations.
Architecturing for Privacy by Design
Privacy by design is not just a GDPR phrase — it's a practical engineering approach that makes compliance easier and reduces breach risk.
Store Templates, Not Images
The most significant architectural decision: never store raw facial images after enrolment. Convert the face to a mathematical embedding (a feature vector, typically 128–512 dimensions) and store only the embedding. The embedding cannot be reverse-engineered to reconstruct the original image. This dramatically reduces breach risk and simplifies data minimisation compliance. Raw images should be deleted immediately after embedding generation.
On-Device Processing Where Possible
For access control and attendance use cases, the entire recognition pipeline can run on-device — the camera captures the frame, the edge processor generates the embedding, matches it against enrolled templates stored locally, and the result (granted/denied, employee ID matched) is all that leaves the device. No biometric data traverses a network; no cloud storage is involved. This architecture sidesteps many of the most complex GDPR data transfer requirements.
Separation of Biometric and Identity Data
Store embeddings and identity records in separate databases, linked only by a pseudonymous token. If an attacker compromises the embedding store, they have mathematical vectors — meaningless without the identity lookup table. This is a standard defence-in-depth pattern for biometric systems.
Differential Logging
Audit logs for a facial recognition system (who was recognised, when, where) are themselves personal data. Apply the same retention limits to audit logs as to the underlying biometric data. Automated deletion jobs should treat log records and biometric records as a unit.
Technical Architecture for a Compliant Deployment
| Layer | Component | Privacy Consideration |
|---|---|---|
| Capture | Camera / sensor | Signage required; consent gate before enrolment |
| Detection | Face detector (e.g., RetinaFace, MTCNN) | Run locally; no raw frame transmission |
| Feature extraction | Recognition model (ArcFace, FaceNet) | Run locally or on-premises server; delete source image immediately |
| Matching | Embedding comparison (cosine similarity) | Match against consent-verified enrolled templates only |
| Identity lookup | Pseudonymous token → identity database | Separate database; access-logged |
| Consent management | Consent records, withdrawal API | Audit trail; withdrawal triggers deletion pipeline |
| Retention enforcement | Automated deletion jobs | Embeddings, logs, and identity links deleted per policy |
Bias, Accuracy and the Operational Duty of Care
Regulatory compliance is necessary but not sufficient. Facial recognition systems have well-documented accuracy disparities across demographic groups — darker skin tones and women have historically shown higher false match and false rejection rates in commercially deployed models. The NIST FRVT (Face Recognition Vendor Testing) benchmarks are publicly available and should be the starting point for vendor evaluation.
If you're building or procuring a system that makes consequential decisions — access control, payment authentication, law enforcement support — you have an operational duty to:
- Test accuracy across demographic subgroups in your target population before deployment
- Set threshold parameters that balance false acceptance rate and false rejection rate appropriately for the risk level of the application
- Build a human review path for low-confidence matches or rejected access attempts
- Monitor accuracy continuously in production, not just pre-launch
Legitimate Commercial Use Cases
It's worth being specific about where facial recognition deployments can be justified and built compliantly:
- Employee access control and attendance: Consent is feasible (employment context with genuine opt-out alternatives); data processing is proportionate to the purpose.
- Customer authentication (banking, fintech): Explicit enrolment consent; matches a specific enrolled individual only; strong regulatory precedent.
- Event check-in: Pre-enrolment with explicit consent; time-limited data retention; alternative provided.
- Age verification (restricted content/alcohol): Estimate-only (not identification); no template storage; emerging but gaining regulatory acceptance.
Use cases that remain high-risk or legally untenable in most jurisdictions: passive surveillance of shoppers without consent, emotional or sentiment analysis on customers, tracking individuals across different physical locations without explicit authorisation.
Frequently Asked Questions
Is facial recognition categorically prohibited under GDPR?
No — but it requires a lawful basis under Article 6 AND a specific condition under Article 9 (biometric data). Explicit consent is the most practically available basis for most commercial use cases. Certain narrow exceptions exist (employment law, vital interests), but they don't cover typical commercial deployments. Any system that identifies rather than merely detects faces is subject to Article 9.
What's the difference between face detection and facial recognition for compliance purposes?
Face detection locates faces in an image without identifying who they belong to — it's used for photo cropping, crowd counting, blur effects. This is generally not biometric data processing under GDPR. Facial recognition identifies or verifies the identity of specific individuals. Only recognition triggers Article 9 obligations. Building detection-only systems where the use case allows it is a legitimate privacy engineering choice.
How long can we retain facial recognition data?
Retention must be limited to what's necessary for the specific purpose. For access control, embeddings can typically be retained only while employment or the access relationship is active, then deleted within a defined period after termination (30–90 days is common). Audit logs of recognition events should follow a similar or shorter retention schedule. BIPA in Illinois is more prescriptive: templates must be destroyed within 3 years or when the purpose for collection is fulfilled, whichever comes first.
Can we deploy facial recognition in a country outside the EU to avoid GDPR?
Only if your users are not EU residents. GDPR applies to the data subjects, not to where your servers are located. A system that processes the biometric data of EU citizens or residents is subject to GDPR regardless of where the processing happens. Jurisdictional arbitrage doesn't work here.
This is the kind of work our team handles every day — learn more about our computer vision services and AI solutions.
Designing a system that passes both technical and legal scrutiny from the start is significantly cheaper than retrofitting compliance onto an existing deployment. If you're scoping a facial recognition project and want an honest technical assessment of the architecture, data flows, and compliance requirements for your specific context, book a free discovery call with Mexilet Technologies. We'll help you map out what responsible deployment looks like for your use case before a line of code is written.