Data Protection Impact Assessment (DPIA) · Tratamiento de datos biométricos de comportamiento e imágenes de documentos · Conforme al Art. 35 RGPD (Reglamento 2016/679)
DPIA obligatoria — Art. 35(3)(a) RGPD
Esta evaluación es legalmente obligatoria conforme al Art. 35(3)(a) RGPD por tratarse de un tratamiento a gran escala de categorías especiales de datos (datos biométricos, Art. 9 RGPD) destinados a identificar de forma única a personas físicas. También concurre el criterio de «evaluación sistemática» (Art. 35(3)(a)) al tratarse de un sistema automatizado de puntuación con efectos potencialmente significativos sobre los interesados.
| Responsable del tratamiento | Deep-Check |
| DPO | Pendiente de designación formal (obligatorio si >250 empleados o tratamiento habitual de categorías especiales a gran escala) |
| Denominación del tratamiento | Verificación de identidad mediante biometría conductual y análisis forense de documentos |
| Referencia interna | DPIA-DC-001 v1.0 |
| Fecha de inicio | Enero 2026 |
| Revisión prevista | Agosto 2026 (semestral) o ante cambios sustanciales |
| Normativa aplicable | RGPD (UE) 2016/679 · LO 3/2018 LOPDGDD · Reglamento IA 2024/1689 · ENS RD 311/2022 |
| Evaluador | Equipo técnico-legal de Deep-Check |
Deep-Check es una plataforma SaaS que realiza dos tratamientos diferenciados, ambos con impacto en la privacidad:
Tratamiento A — Biometría conductual
Tratamiento B — Análisis forense documental
| Categoría | Datos específicos | Clasificación RGPD | Dónde se procesa |
|---|---|---|---|
| Datos biométricos | Patrones temporales de pulsación de teclado (flight time, hold time, dígrafos) | Categoría especial — Art. 9 RGPD | Extracción: client-side (navegador). Vectores derivados: servidor → Supabase |
| Datos de identificación | Nombre, email del candidato (enlazado al perfil) | Dato personal ordinario — Art. 4(1) RGPD | Supabase (EU) |
| Imágenes de documentos | Fotografías de documentos (DNI, pasaporte, facturas, etc.) | Dato personal si contiene imagen/datos del titular | Procesado client-side; no almacenado en servidor (solo análisis ELA en canvas) |
| Metadatos EXIF | Software editor, fecha/hora, dispositivo, coordenadas GPS (si presentes) | Dato personal si incluye localización o ID de dispositivo | Extraído client-side; resumen almacenado en Supabase (JSON) |
| Datos de red | Dirección IP (pseudonimizada), User-Agent | Dato personal ordinario | Middleware → dc_audit_logs (IP hasheada SHA-256+salt) |
| Datos de sesión | Token de sesión admin (hash SHA-256), timestamp | Dato de autenticación | dc_admin_sessions (Supabase) |
| Finalidad | Descripción | Base jurídica (Art. 6/9 RGPD) |
|---|---|---|
| Verificación de identidad | Comprobar que el candidato que realiza una sesión es la misma persona que enroló su perfil biométrico | Art. 9(2)(a) — Consentimiento explícito previo al tratamiento |
| Detección de fraude/bot | Identificar comportamiento automatizado (bots, scripts) o suplantación de identidad en procesos de selección o acceso | Art. 9(2)(a) — Consentimiento explícito |
| Análisis forense documental | Detectar manipulación o generación sintética de documentos aportados como prueba | Art. 6(1)(f) — Interés legítimo del operador (prevención de fraude documentario) |
| Registro de actividad (audit log) | Mantener trazabilidad de accesos y operaciones del sistema para cumplimiento ENS/ISO 27001 | Art. 6(1)(c) — Obligación legal (ENS RD 311/2022 op.exp.7) |
| Mejora del sistema | Análisis agregado y anonimizado de métricas de rendimiento del algoritmo | Art. 6(1)(f) — Interés legítimo (únicamente datos anonimizados; no aplica RGPD) |
| Destinatario | Rol | País/Región | Garantías |
|---|---|---|---|
| Supabase Inc. | Encargado del tratamiento (base de datos) | UE (región eu-central-1) | DPA firmado, ISO 27001, SOC 2 Type II, clausulas contractuales tipo (CCT) |
| Vercel Inc. | Encargado del tratamiento (hosting/CDN) | EE. UU. (con Edge UE) | DPA firmado, SCCs, SOC 2 Type II. Datos de sesión pueden procesarse en nodos UE |
| Clientes de Deep-Check (operadores) | Responsables conjuntos o encargados según contrato | Variable | Contrato de servicio + DPA; obligados a garantizar base jurídica y derechos de interesados |
La biometría conductual mediante análisis de pulsaciones de teclado es actualmente el método menos intrusivo disponible para verificación continua de identidad en entornos digitales remotos, en comparación con alternativas como:
| Alternativa | Intrusividad | Motivo de descarte/complemento |
|---|---|---|
| Reconocimiento facial | Muy alta | Procesa imágenes del rostro (Art. 9); más intrusivo; requiere cámara activa |
| Huella dactilar / iris | Alta | Requiere hardware dedicado; no aplicable en contextos remotos SaaS |
| OTP / MFA tradicional | Baja | No detecta suplantación post-autenticación; no verifica identidad continua |
| Biometría conductual (keystroke) | Media-Baja | Seleccionado: no captura datos morfológicos; solo patrones temporales estadísticos |
| Sin verificación biométrica | N/A | Inaceptable: el producto no cumpliría su finalidad de detección de fraude |
Los datos biométricos recogidos solo se utilizan para la finalidad declarada(verificación de identidad / detección de bot). Están contractualmente prohibidos: perfilado de personalidad, inferencia de estado de salud, monitorización fuera del contexto de verificación, venta a terceros.
Conforme a la metodología de la AEPD y CNIL, cada riesgo se evalúa por probabilidad de materialización (sin medidas) y gravedad del impacto sobre los interesados, obteniendo un nivel de riesgo residual tras aplicar las medidas de mitigación.
| ID | Riesgo | Prob. | Gravedad | Medidas de mitigación | Riesgo residual |
|---|---|---|---|---|---|
| R-01 | Acceso no autorizado a perfiles biométricos almacenados | Media | Alta | RLS Supabase (service_role only), AES-256 en reposo, audit log de accesos, rate limiting, CSP | Bajo |
| R-02 | Re-identificación de datos pseudonimizados (ataque de correlación) | Baja | Alta | Solo se almacenan estadísticas agregadas (no raw timings); IP hasheada con salt; sin cruce con otras BBDD | Muy bajo |
| R-03 | Suplantación de identidad (spoofing biométrico — replay o sintético) | Media | Alta | 4 capas anti-adversarial: blink rate, rhythm_shift, inconsistency, saccade gate; detección de bursts; validación en enroll | Medio |
| R-04 | Falso positivo: rechazo erróneo de persona legítima (discriminación algorítmica) | Media | Media | Umbral calibrado (FPR < 5% en benchmark); supervisión humana obligatoria (Terms §2.3); posibilidad de apelación | Bajo |
| R-05 | Decisión automatizada sin intervención humana (Art. 22 RGPD) | Media | Alta | Términos de servicio prohíben uso como decisión automatizada exclusiva; dashboard requiere revisión humana; EU AI Act Art. 14 implementado | Bajo |
| R-06 | Exfiltración de datos vía ataque XSS / inyección en la aplicación | Baja | Alta | CSP estricta (no unsafe-inline); TypeScript strict; no eval(); queries parametrizadas (Supabase ORM); npm audit | Muy bajo |
| R-07 | Uso secundario no autorizado de datos biométricos por parte del operador | Baja | Alta | DPA contractual con operadores; auditoría de uso; acceso API restringido por API key; audit log de todas las consultas | Bajo |
| R-08 | Violación de seguridad sin notificación en plazo (RGPD Art. 33 — 72h) | Baja | Media | Audit log permite detección rápida; alertas de Vercel en 5xx; procedimiento de notificación AEPD documentado | Bajo |
| R-09 | Transferencia internacional insegura (Vercel EE.UU.) | Media | Media | DPF (Decisión de Adecuación jul-2023) + SCCs; datos biométricos almacenados en Supabase EU; Edge Functions configuradas para UE | Bajo |
| R-10 | Retención excesiva de datos biométricos tras finalidad cumplida | Baja | Media | Expiración automática a 90 días (campo expires_at); endpoint DELETE /api/enrollment/:id para ejercicio de supresión | Muy bajo |
| R-11 | Tratamiento de datos de menores sin consentimiento parental | Baja | Alta | Términos de servicio prohíben uso con menores de 18 años; responsabilidad contractual del operador de verificar edad | Bajo |
| R-12 | GPS / datos de localización en metadatos EXIF de documentos | Media | Media | EXIF leído client-side; coordenadas GPS en análisis forense nunca se transmiten al servidor (solo flag booleano de presencia); usuario informado | Muy bajo |
| Medida | Descripción técnica | Control RGPD |
|---|---|---|
| Privacidad por diseño | Extracción biométrica 100% client-side (browser Web API). Solo vectores estadísticos derivados se transmiten. Sin almacenamiento de timings individuales. | Art. 25 RGPD |
| Pseudonimización | IPs hasheadas SHA-256+salt antes de almacenarse. Perfiles identificados con ID opaco (ep_*). Email solo para lookup de perfil. | Art. 4(5) + Art. 32(1)(a) |
| Cifrado en tránsito | TLS 1.3 enforced via HSTS (max-age=31536000, preload). Sin downgrade HTTP. | Art. 32(1)(a) |
| Cifrado en reposo | AES-256 gestionado por Supabase (PostgreSQL). Claves gestionadas por proveedor ISO 27001. | Art. 32(1)(a) |
| Control de acceso | RLS Supabase: audit_logs solo service_role; API keys en Vercel env; dashboard con sesión httpOnly/Secure; timingSafeEqual. | Art. 32(1)(b) |
| Limitación de acceso | Rate limiting por IP: 20 req/min en /api/ml-score, 5 req/min en /api/auth. Bloqueo automático con Retry-After. | Art. 32(1)(b) |
| Audit logging | Registro completo en dc_audit_logs: eventType, endpoint, IP pseudonimizada, status_code, duration_ms. Append-only. | Art. 5(2) — Responsabilidad proactiva |
| Consentimiento técnico | Modal de consentimiento RGPD Art. 9 obligatorio antes de cualquier captura biométrica. No bypass posible. | Art. 7 + Art. 9(2)(a) |
| Minimización | Solo stats agregadas almacenadas (no raw). El texto escrito por el candidato no se transmite ni registra. | Art. 5(1)(c) |
| Expiración automática | Campo expires_at en perfiles biométricos: 90 días. Sin renovación automática. | Art. 5(1)(e) |
| Cabeceras de seguridad | CSP, HSTS, X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff, Permissions-Policy: camera=(self). | Art. 32 — Integridad aplicación |
| Medida | Estado | Plazo |
|---|---|---|
| Política de privacidad publicada (Art. 13/14 RGPD) | ✓ Hecho | — |
| Cláusulas de consentimiento explícito (Art. 9(2)(a)) | ✓ Hecho | — |
| Registro de actividades de tratamiento (Art. 30 RGPD) | ○ Pendiente | Q2 2026 |
| Designación formal de DPO (si aplica Art. 37) | ○ Pendiente | Q2 2026 |
| DPA firmados con Supabase y Vercel | ○ Pendiente | — |
| DPA con clientes/operadores (plantilla) | ○ Pendiente | Q2 2026 |
| Procedimiento de respuesta a violaciones (Art. 33/34) | ◎ Parcial | Q2 2026 |
| Procedimiento de ejercicio de derechos (Art. 15-22) | ◎ Parcial | Q2 2026 |
| Formación en protección de datos del equipo | ○ Pendiente | Q3 2026 |
| Auditoría de privacidad por tercero | ○ Pendiente | Q4 2026 |
| Derecho | Art. | Implementación técnica | Canal |
|---|---|---|---|
| Acceso | Art. 15 | Endpoint GET /api/enrollment?email={email} devuelve perfil completo | Email a privacy@deep-check.app |
| Rectificación | Art. 16 | Re-enrolamiento del perfil biométrico corrige el vector de referencia | Email + re-enrolamiento |
| Supresión (derecho al olvido) | Art. 17 | DELETE /api/enrollment/:id elimina perfil biométrico; datos de audit log pseudonimizados no vinculables | Email a privacy@deep-check.app |
| Limitación del tratamiento | Art. 18 | El operador puede marcar perfiles como inactivos (flag enabled=false) sin suprimirlos | Dashboard del operador |
| Portabilidad | Art. 20 | GET /api/enrollment/:id devuelve perfil en JSON exportable | Email a privacy@deep-check.app |
| Oposición | Art. 21 | El interesado puede retirar el consentimiento; el sistema no puede usarse sin consentimiento | Retirada de consentimiento en plataforma |
| No decisión automatizada exclusiva | Art. 22 | Términos prohíben uso sin supervisión humana; el resultado es siempre una puntuación, no una decisión | Contractual con operadores |
✓ Riesgos residuales aceptables
9 de los 12 riesgos identificados tienen riesgo residual Bajo o Muy bajo tras la aplicación de las medidas técnicas. El tratamiento cumple el principio de minimización, aplica privacidad por diseño y pseudonimización.
⚠ Riesgo residual Medio — R-03
El riesgo de spoofing biométrico sofisticado permanece en nivel Medio. Se acepta como riesgo inherente al estado del arte en biometría conductual. Las 4 capas anti-adversarial implementadas son las medidas disponibles sin incrementar la intrusividad del sistema.
Decisión: El tratamiento puede llevarse a cabo
Con base en el análisis de necesidad, proporcionalidad y riesgos realizado, el tratamiento de datos biométricos y forenses por parte de Deep-Check es lícito y puede continuar, condicionado a:
Aprobación de la DPIA
Responsable del Tratamiento
Deep-Check
25/02/2026
DPO (pendiente designación)
—
—
Próxima revisión
Agosto 2026
o ante cambio sustancial