Reconocimiento facial y biometría en ayuntamientos: riesgos legales y controles prácticos

Por qué este tema importa hoy

El uso de reconocimiento facial y otras formas de biometría plantea oportunidades operativas (p. ej. control de accesos en instalaciones municipales) pero también riesgos legales y reputacionales significativos. Para las administraciones públicas, esos riesgos no son sólo técnicos: afectan al cumplimiento del RGPD, al ENS (RD 311/2022), a las obligaciones que impone el EU AI Act y a las exigencias de contratación pública (Ley 9/2017). Este texto ofrece un enfoque operativo y accionable para evaluar y controlar proyectos de biometría en ayuntamientos.

Marco jurídico y obligaciones clave (resumen práctico)

RGPD: los datos biométricos que permitan identificar de forma unívoca a una persona se consideran “categoría especial” (Art. 9) y su tratamiento requiere una base legal sólida y garantías reforzadas. Además, los derechos sobre decisiones automatizadas (Art. 22) y la obligación de realizar Evaluaciones de Impacto en la Protección de Datos (DPIA, Art. 35) son relevantes cuando el riesgo para los derechos y libertades es alto.
EU AI Act: clasifica sistemas de identificación biométrica remota como de alto riesgo o incluso sujetos a prohibición para usos en espacios públicos en tiempo real; impone requisitos de transparencia, documentación técnica y mitigación de riesgos.
ENS (RD 311/2022): obliga a aplicar medidas de seguridad organizativas y técnicas proporcionales al nivel de información y a los servicios públicos, incluyendo control de accesos, cifrado y registros de auditoría.
Ley 9/2017 (contratación pública): permite y exige incorporar cláusulas técnicas y de cumplimiento normativo en pliegos y contratos (seguridad, auditoría, derechos de propiedad intelectual y continuidad).

Controles prácticos por fase del proyecto

1. Evitar cuando sea posible: priorizar alternativas menos intrusivas

Evalúa si la funcionalidad se puede resolver con control de acceso con tarjetas, códigos temporales o autenticación multifactor, o con análisis no identificativo (p. ej. conteo anónimo de afluencia).
Documenta la comparación de alternativas en la memoria técnica y jurídica del expediente.

2. Antes del despliegue: obligaciones legales y de gobernanza

Realiza una DPIA (Art. 35 RGPD) específica: describir finalidad, flujos de datos, riesgos residual y medidas de mitigación.
Consulta al Delegado de Protección de Datos (DPD/DPO) y, si procede, a la AEPD antes del piloto.
Clasifica el sistema frente al EU AI Act: ¿es identificación biométrica remota en tiempo real? Si es así, puede estar restringido o prohibido en entornos públicos.

3. Requerimientos técnicos (ENS + buenas prácticas)

Minimización y pseudonimización: no conservar identificadores innecesarios y separar identificadores de metadatos operativos.
Cifrado en tránsito y reposo; gestión de claves con HSM cuando exista riesgo alto.
Control de accesos y registro de auditoría con trazabilidad (quién, cuándo, por qué).
Pruebas de sesgos y evaluación de precisión por subgrupos demográficos; documentarlas en model cards.
Monitorización continua y plan de respuesta a incidentes específico para la IA.

4. Operación y derechos de la ciudadanía

Transparencia: señalética en espacio físico y avisos claros en procedimientos administrativos explicando la finalidad, base jurídica y canales para ejercer derechos.
Derechos de acceso, rectificación, supresión y oposición: procedimientos internos para atenderlos con plazos y responsables definidos.
Supervisión humana: ninguna decisión administrativa que afecte a derechos de una persona debe quedar exclusivamente en manos del algoritmo (Art. 22 RGPD y principios del AI Act).

5. Contratación y relación con proveedores

En pliegos (Ley 9/2017) exige: descripción técnica detallada, requisitos de seguridad ENS, auditorías periódicas, acceso a datos de entrenamiento, obligaciones de no reidentificación, cláusulas de cesión y portabilidad y SLA de continuidad.
Derecho de auditoría independiente y entrega de documentos técnicos: SBOM/model cards, registros de versiones y pruebas de robustez.
Responsabilidades y límites: cláusulas claras sobre responsabilidad por fallos, sesgos o fugas de datos.

Checklist rápido (6 pasos) antes de cualquier piloto

¿Existe alternativa menos intrusiva? Justificar por escrito si no.
DPIA completa y validada por el DPO.
Clasificación frente al EU AI Act y consulta legal sobre viabilidad.
Requisitos ENS implementados (cifrado, control de accesos, auditoría).
Cláusulas contractuales y derechos de auditoría en el proveedor.
Plan de comunicación y gestión de incidencias + formación al personal.

Caso de uso mínimo viable (90 días)

Si la decisión es avanzar, hacer un piloto limitado en alcance, tiempo y exposición:

Área cerrada (p. ej. control de accesos en edificio municipal), consentimientos escritos del personal o usuarios, datos no conservados más allá del mínimo necesario, y evaluación de impacto y técnicas antes/después del piloto.

Takeaway / Acción recomendada

No implantes reconocimiento facial en espacios públicos sin justificar técnicamente la necesidad ni cumplir la DPIA, ENS y los requisitos del EU AI Act. Prioriza alternativas menos intrusivas, exige transparencia y auditorías en el contrato y planifica un piloto acotado con supervisión legal y técnica. Para avanzar, arranca con una DPIA y una cláusula de contratación que incluya derechos de auditoría y requisitos ENS: es la base para reducir riesgo legal y operativo.

Herramientas de diagnóstico y roadmaps de gobernanza (p. ej. OptimGov Ready) pueden ayudar a identificar lagunas concretas y preparar los pliegos y la DPIA antes del proyecto.