Facial recognition and biometrics in municipalities: legal risks and practical controls

Why this matters today

The use of facial recognition and other forms of biometrics offers operational benefits (e.g., access control in municipal facilities) but also significant legal and reputational risks. For public administrations, these risks are not only technical: they affect GDPR compliance, the ENS (Royal Decree 311/2022), obligations under the EU AI Act, and public procurement requirements (Law 9/2017). This document provides a practical, actionable approach to assess and control biometric projects in city councils.

Legal framework and key obligations (practical summary)

• GDPR: biometric data that can uniquely identify a person are considered a “special category” (Art. 9) and their processing requires a solid legal basis and enhanced safeguards. Rights related to automated decision-making (Art. 22) and the obligation to carry out Data Protection Impact Assessments (DPIAs, Art. 35) are relevant when risks to rights and freedoms are high.
• EU AI Act: classifies remote biometric identification systems as high-risk or even subject to prohibition for real-time use in public spaces; it imposes requirements for transparency, technical documentation and risk mitigation.
• ENS (Royal Decree 311/2022): requires organizational and technical security measures proportional to the information and public services involved, including access control, encryption and audit logs.
• Law 9/2017 (public procurement): allows and requires the inclusion of technical and compliance clauses in tender documents and contracts (security, audits, intellectual property and continuity).

Practical controls by project phase

1. Avoid when possible: prioritize less intrusive alternatives

• Assess whether the functionality can be solved with card-based access control, temporary codes, multi-factor authentication, or non-identifying analysis (e.g., anonymous footfall counting).
• Document the alternatives comparison in the project’s technical and legal record.

2. Before deployment: legal and governance obligations

• Carry out a DPIA (Art. 35 GDPR) specific to the project: describe purpose, data flows, residual risks and mitigation measures.
• Consult the Data Protection Officer (DPO) and, if appropriate, the AEPD (Spanish Data Protection Agency) before the pilot.
• Classify the system under the EU AI Act: is it remote biometric identification in real time? If so, it may be restricted or prohibited in public environments.

3. Technical requirements (ENS + best practices)

• Minimization and pseudonymization: do not keep unnecessary identifiers and separate identifiers from operational metadata.
• Encryption in transit and at rest; key management with HSMs when risk is high.
• Access control and audit logs with traceability (who, when, why).
• Bias testing and accuracy evaluation by demographic subgroups; document results in model cards.
• Continuous monitoring and an AI-specific incident response plan.

4. Operation and citizens’ rights

• Transparency: signage in physical spaces and clear notices in administrative procedures explaining purpose, legal basis and channels to exercise rights.
• Rights of access, rectification, erasure and objection: internal procedures to handle requests with defined deadlines and responsible parties.
• Human oversight: no administrative decision affecting a person’s rights should be left exclusively to an algorithm (Art. 22 GDPR and principles of the AI Act).

5. Procurement and supplier relationships

• Tender specifications (Law 9/2017) should require: detailed technical descriptions, ENS security requirements, periodic audits, access to training data, non-reidentification obligations, data transfer and portability clauses, and continuity SLAs.
• Right to independent audit and delivery of technical documents: SBOM/model cards, version logs and robustness test reports.
• Responsibilities and limits: clear clauses on liability for failures, bias or data breaches.

Quick checklist (6 steps) before any pilot

1. Is there a less intrusive alternative? Justify in writing if not.
2. Complete DPIA validated by the DPO.
3. Classification under the EU AI Act and legal review of viability.
4. ENS requirements implemented (encryption, access control, auditing).
5. Contractual clauses and audit rights with the provider.
6. Communication and incident management plan + staff training.

Minimum viable use case (90 days)

If the decision is to proceed, run a limited pilot in scope, duration and exposure:

• Enclosed area (e.g., access control in a municipal building), written consent from staff or users, data retained only for the minimum necessary period, and impact and technical evaluations before and after the pilot.

Takeaway / Recommended action

Do not deploy facial recognition in public spaces without technically justifying the need and complying with the DPIA, ENS and the EU AI Act requirements. Prioritize less intrusive alternatives, require transparency and audits in the contract, and plan a limited pilot with legal and technical oversight. To move forward, start with a DPIA and a procurement clause that includes audit rights and ENS requirements: this is the foundation for reducing legal and operational risk.

Diagnostic tools and governance roadmaps (e.g., OptimGov Ready) can help identify specific gaps and prepare tender documents and the DPIA before the project.