Biometría: tipos, tasas de error, liveness y privacidad

Por qué la biometría merece su propio artículo

En el artículo de factores conocimos la biometría como “algo que eres” — una de las cinco categorías, resumida en unos párrafos. Ese resumen basta para diseñar una pantalla de login. No basta para tomar las decisiones que a un profesional realmente le piden: ¿el matching ocurre en el dispositivo o en el servidor? ¿qué FAR aceptamos? ¿nuestro liveness alcanza para un pago? ¿tenemos permitido almacenar este dato en esta jurisdicción?

La biometría es engañosamente simple en la superficie (“escanea tu rostro y entras”) y genuinamente sutil por debajo. Es la única categoría de factor donde un error de diseño puede dañar al usuario de forma permanente, porque no puedes reemitir una huella. Es también el factor más rodeado de ley específica. Por eso se gana una inmersión propia.

Al terminar este artículo entenderás las modalidades principales, qué significan exactamente FAR/FRR/EER y cómo el umbral de matching intercambia una por otra, qué exigen realmente el liveness y el anti-spoofing, cómo deben almacenarse los templates, qué regulaciones te obligan y dónde encaja la biometría comportamental.

Las modalidades principales

“Biométrico” cubre cualquier característica humana medible lo bastante estable para distinguir a una persona de otra. En la práctica dominan un puñado de modalidades.

Dos distinciones estructurales importan más que la modalidad en sí.

Verificación (1:1) vs identificación (1:N). La verificación responde “¿es esta la persona que dice ser?” — una muestra fresca contra un template almacenado. Es lo que hace desbloquear tu teléfono o iniciar sesión. La identificación responde “¿quién es esta persona?” — una muestra contra toda una base de datos. La identificación es mucho más difícil: tasas de error despreciables en 1:1 se disparan al buscar contra millones de templates, porque tienes muchas oportunidades de falsa coincidencia. Casi toda la autenticación es 1:1; el 1:N a gran escala es el terreno del control fronterizo y la aplicación de la ley, con perfiles de riesgo y legales distintos.

Fisiológica vs comportamental. Huella, rostro, iris, voz y vena miden un rasgo físico. La biometría comportamental mide cómo actúas. Los rasgos fisiológicos se capturan en un momento discreto; las señales comportamentales se acumulan de forma continua. Tratamos la comportamental por separado al final porque juega un papel distinto en un sistema.

Cómo funciona el matching en realidad

Entender el pipeline es lo que te permite razonar sobre las fallas. Todo sistema biométrico, sin importar la modalidad, corre aproximadamente las mismas etapas.

flowchart TB
  accTitle: Pipeline de enrolamiento y verificación biométrica
  accDescr: Dos carriles. El carril de enrolamiento captura una muestra, extrae rasgos y almacena un template protegido en un almacén seguro. El carril de verificación captura una nueva muestra, extrae rasgos, corre una comprobación de liveness o presentation attack detection, y luego un matcher compara la muestra contra el template almacenado para producir un puntaje de similitud, que un umbral convierte en una decisión de aceptar o rechazar.
  subgraph ENROLL[Enrolamiento · una vez]
    C1[Capturar muestra] --> F1[Extraer rasgos]
    F1 --> T1[(Almacenar template protegido)]
  end
  subgraph VERIFY[Verificación · cada login]
    C2[Capturar muestra] --> L2{Liveness / PAD}
    L2 -->|Spoof sospechado| RJ[Rechazar]
    L2 -->|Vivo| F2[Extraer rasgos]
    F2 --> M2[Matcher vs template]
    M2 --> S2[Puntaje de similitud]
    S2 --> TH{¿Puntaje ≥ umbral?}
    TH -->|Sí| OK[Aceptar]
    TH -->|No| RJ
  end
  T1 -. comparado contra .-> M2

Vale la pena subrayar tres cosas:

• El sistema nunca almacena ni compara imágenes raw en el momento del match. Compara templates de rasgos — representaciones matemáticas compactas. Un buen template no es reversible a la imagen original (más sobre esto en almacenamiento).
• El liveness corre antes, o junto, al matching. Un matcher que aceptaría con gusto una foto de alta calidad no vale nada sin una compuerta de liveness delante.
• La decisión final es una comparación con umbral, y el umbral lo pones tú. De ahí salen las tasas de error.

Las métricas de error: FAR, FRR, EER

Esta es la parte que todo profesional debe saber razonar en voz alta.

Los dos errores

Como el matching es un puntaje de similitud contra un umbral, solo son posibles exactamente dos tipos de error:

• Falsa Aceptación (FA): el puntaje de un impostor supera el umbral y entra. La tasa de que esto ocurra es el FAR — False Accept Rate. Es el error de seguridad. También llamado False Match Rate (FMR) en el vocabulario ISO.
• Falso Rechazo (FR): el puntaje de un usuario legítimo se queda corto y lo rebotan. La tasa es el FRR — False Reject Rate. Es el error de usabilidad. También llamado False Non-Match Rate (FNMR).

El compromiso es todo el juego

FAR y FRR no son perillas independientes — son los dos extremos de la misma perilla, el umbral:

• Subir el umbral (exigir un match más cercano): menos impostores se cuelan (FAR ↓) pero más usuarios legítimos son rechazados en un día un poco malo — dedo húmedo, mala luz (FRR ↑).
• Bajar el umbral (aceptar matches más flojos): los usuarios legítimos pasan sin problema (FRR ↓) pero los impostores tienen mejor oportunidad (FAR ↑).

No puedes minimizar ambos a la vez con un sistema fijo. Eliges un punto de la curva que encaje con el riesgo. ¿Desbloquear una app de música? Inclínate hacia FRR bajo — un usuario frustrado importa más que una falsa aceptación rara. ¿Autorizar una transferencia bancaria? Inclínate hacia FAR bajo — prefieres pedirle a un usuario legítimo que reintente antes que dejar pasar a un impostor.

El EER y cómo leer una ficha técnica

El EER — Equal Error Rate es el punto único donde FAR = FRR. Colapsa toda la curva de compromiso en un solo número, lo que lo hace cómodo para comparar dos sistemas: un sensor con EER de 0.1% suele ser mejor que uno de 2%. Pero cuidado con dos trampas:

• Casi nadie opera en el EER. Los despliegues reales se sitúan deliberadamente fuera de él — normalmente en un FAR bajo y fijo (p. ej. “FAR ≤ 0.001%”) y aceptan el FRR que eso implique. Un proveedor que solo cita el EER está ocultando el punto de operación.
• Una cifra de FAR sola no significa nada sin su FRR, y viceversa. “FAR de 1 en 50,000” suena genial hasta que te enteras de que el FRR en ese ajuste es 8% y a uno de cada doce usuarios lo bloquean las mañanas lluviosas.

Dos tasas más que verás y no debes confundir con las anteriores:

• FTE — Failure to Enroll: la fracción de personas que no logran registrar un template usable (huellas gastadas por trabajo manual, ciertas condiciones oculares para iris). Es un problema de inclusión — tu vía de fallback debe cubrir a estos usuarios, o los has excluido.
• FTA — Failure to Acquire: la fracción de intentos de captura que no producen muestra usable (dedo muy seco, rostro fuera de cuadro). Un FTA alto infla silenciosamente el FRR real.

Liveness y anti-spoofing

Un matcher solo responde “¿coincide esta muestra con el template?” No responde “¿esta muestra viene de un humano real y presente?” Esa segunda pregunta es liveness detection, y formalmente presentation attack detection (PAD), estandarizado en ISO/IEC 30107. Sin él, el matcher más fuerte del mundo lo vence una foto impresa, un video reproducido, un dedo de silicona, un modelo de cera o un deepfake generado por IA.

Los ataques de los que defiende

• Rostro: una foto impresa, una pantalla reproduciendo video, una máscara de papel o impresa en 3D, y cada vez más deepfakes inyectados en el stream de la cámara.
• Huella: una huella latente levantada y moldeada en gelatina, silicona o cola de madera.
• Voz: una grabación, un empalme concatenado, o una clonación de voz en tiempo real — para mediados de la década de 2020 hay casos documentados de fraude bancario con voces clonadas por IA.
• Iris: un iris impreso en alta resolución, a veces con un lente de contacto superpuesto.

Liveness activo vs pasivo

• Liveness activo le pide al usuario hacer algo: parpadear, girar la cabeza, leer un número aleatorio en voz alta, seguir un punto en movimiento. Es más difícil de falsificar con medios estáticos pero añade fricción y puede sortearse con reproducciones sofisticadas.
• Liveness pasivo analiza la muestra misma en busca de señales de una presentación real — textura y reflectancia de la piel, profundidad de un sensor 3D, micro-movimientos, flujo sanguíneo sub-superficial, artefactos a nivel de sensor de una pantalla re-presentada — sin acción extra del usuario. Mejor UX, y hacia donde se ha movido el mercado en flujos de consumo.

Los sistemas fuertes combinan ambos, y el PAD se califica por nivel en ISO 30107: Nivel 1 defiende contra artefactos baratos (una foto impresa), Nivel 2 contra otros más sofisticados (máscaras bien hechas). Cuando hay un pago o un onboarding en juego, pregunta qué nivel de PAD fue probado de forma independiente, por un laboratorio como iBeta, no solo afirmado.

Almacenar datos biométricos: el problema de la filtración irreversible

Aquí está la propiedad que hace a la biometría distinta de cualquier otro factor: no se puede revocar. Si una base de contraseñas se filtra, todos resetean. Si una base de huellas raw se filtra, esas huellas quedan comprometidas por el resto de la vida de cada persona afectada. No hay reset. Este solo hecho gobierna todas las reglas de almacenamiento de abajo.

Nunca almacenes imágenes raw

Un sistema serio no almacena la foto de tu rostro ni la imagen de tu huella. Almacena un template: un vector de rasgos extraído y compacto. Y debe usar protección de template para que ni siquiera el template pueda volverse el rasgo original ni enlazarse entre sistemas:

• Biometría cancelable: aplica una transformación repetible y revocable a los rasgos antes de almacenar, de modo que un template filtrado pueda revocarse y re-enrolarse con una nueva transformación — recuperando una forma del “reset” que de otro modo no tienes.
• Criptosistemas biométricos: enlazan la biometría a una clave criptográfica (fuzzy vault / fuzzy extractor) para que el dato almacenado no revele ni el rasgo ni la clave por sí solo.
• El estándar de referencia para todo esto es ISO/IEC 24745 (protección de información biométrica), cuyos requisitos centrales son irreversibilidad, no-enlazabilidad y renovabilidad.

Prefiere el matching en el dispositivo, en hardware seguro

La arquitectura más fuerte mantiene el template en el dispositivo del usuario, dentro de hardware seguro, y hace el match ahí:

• Secure Enclave / TEE: el Secure Enclave de Apple, un Trusted Execution Environment o el StrongBox de Android guardan el template en memoria que el propio SO no puede leer. Touch ID, Face ID y Windows Hello funcionan así — tu biometría nunca llega a los servidores de Apple ni de Microsoft.
• Match-on-card / match-in-sensor: en smart cards y algunos sensores, tanto el template como la comparación viven dentro del chip; el rasgo nunca sale de él.
• El dispositivo entonces atestigua el resultado (“una biometría válida desbloqueó esta clave”) al servidor — típicamente vía una aserción FIDO2/WebAuthn. El servidor aprende “el humano enrolado está presente”, nunca la biometría en sí. Por eso exactamente passkeys + biometría del dispositivo es un diseño tan limpio: la red ve una firma criptográfica, no tu rostro.

Las bases biométricas centralizadas a veces son inevitables (identidad nacional, algunos sistemas fronterizos), pero concentran riesgo irreversible y exigen controles extremos a la altura. Para un producto ordinario, el default debe ser: en el dispositivo, en hardware seguro, con match local.

Privacidad y regulación

Como el dato es sensible e irrevocable, la biometría es una de las áreas más específicamente reguladas de toda la identidad. No puedes tratarla como “un atributo más.”

• BIPA — Illinois Biometric Information Privacy Act: la más estricta y litigada de EE. UU. Exige notificación por escrito y consentimiento explícito previo antes de recolectar identificadores biométricos, obliga a un calendario de retención/destrucción y, crucialmente, otorga un derecho privado de acción — los individuos pueden demandar directamente, con daños estatutarios por violación. Varios acuerdos muy grandes han salido de BIPA. Texas y Washington tienen sus propias leyes biométricas; más estados de EE. UU. van siguiendo.
• GDPR Artículo 9 (UE/RU): el dato biométrico usado para identificar de forma única a una persona es una categoría especial de dato personal, prohibida de procesar salvo que aplique una condición específica (típicamente consentimiento explícito, u otra base del Art. 9). Arrastra protección-de-datos-por-diseño, DPIAs, minimización y estricta limitación de finalidad.
• Regímenes locales: la mayoría de leyes modernas de protección de datos reflejan esto. La LFPDPPP de México clasifica la biometría como sensible; la LGPD de Brasil la trata como dato personal sensible; otras jurisdicciones siguen el mismo patrón “especial/sensible”. Asume que la biometría es una categoría regulada dondequiera que operes y revisa la ley local.

La columna práctica de cumplimiento es consistente entre regímenes: consentimiento explícito e informado; minimización de datos (almacena un template protegido, no una imagen; mantenlo en el dispositivo cuando puedas); una política definida de retención y borrado; y una alternativa para quienes no pueden o no quieren enrolarse — lo que regresa directo al FTE como requisito de inclusión y legal, no un lujo.

Biometría comportamental: algo que haces

Todo lo anterior es fisiológico. La biometría comportamental identifica a una persona por patrones en cómo actúa, y juega un papel genuinamente distinto en un sistema.

• Dinámica de tipeo: tu ritmo, los tiempos de permanencia y de vuelo entre teclas, tus erratas habituales.
• Dinámica del mouse: cómo lo mueves, curvas y clics.
• Toque y swipe: presión, velocidad, arco y ángulo del dedo en pantalla; cómo sostienes el teléfono.
• Marcha y manejo del dispositivo: patrones de los sensores de movimiento al caminar o cargar el dispositivo.

Sus rasgos definitorios:

• Silenciosa y sin fricción. No le pide nada al usuario. No hay prompt ni escaneo — observa señales ya presentes mientras la persona usa la app.
• Continua, no puntual. Donde una huella prueba la presencia en el momento del login, las señales comportamentales siguen probándola durante toda la sesión — un encaje natural con la idea de verificación continua que desarrollamos en el artículo de Zero Trust.
• Auxiliar, nunca factor único. Es una señal de riesgo, no un login. Necesita un periodo de aprendizaje para construir un perfil por usuario y deriva con el tiempo, así que alimenta un motor adaptativo en vez de bloquear el acceso por sí sola.
• Excelente contra el account takeover (ATO). Cuando “alguien que teclea y desliza distinto” conduce una sesión cuya contraseña era correcta, la analítica comportamental es a menudo lo que lo atrapa. Por eso se despliega intensamente en banca y CIAM — proveedores reales aquí incluyen BioCatch, TypingDNA y módulos comportamentales dentro de plataformas de fraude — precisamente porque sube la seguridad sin fricción visible.

Piensa en la biometría comportamental como el copiloto silencioso del motor de riesgo del artículo de factores: no te detiene en la puerta, vigila si la persona adentro sigue moviéndose como la que fue dejada entrar.

Elegir y combinar modalidades

Ninguna modalidad es “la mejor” — la elección correcta es aquella cuyo perfil de error, costo y resistencia al spoofing encajen con el caso de uso y la población. Una app de pagos en teléfonos modernos se apoya en rostro o huella porque el hardware y el secure enclave ya están ahí. Un puesto fronterizo puede justificar iris por su precisión y estabilidad. Un call center puede estar atado a la voz y por ello debe invertir fuerte en anti-spoofing contra clones.

Cuando una modalidad no basta, los sistemas usan biometría multimodal — combinando dos rasgos (digamos rostro y voz) y fusionando sus puntajes. La fusión puede ocurrir en distintas etapas (nivel de rasgo, de puntaje, de decisión), y bien hecha baja ambas tasas de error a la vez y sube la valla para un atacante, que ahora debe falsificar dos rasgos distintos simultáneamente. El costo es más fricción de captura y más hardware, así que lo multimodal se reserva para contextos de mayor aseguramiento en vez de un desbloqueo de consumo.

Una regla de diseño útil: haz coincidir el modo de falla de la modalidad con tu tolerancia al riesgo. Si los falsos rechazos son solo molestos (desbloquear una app de medios), afina flojo y elige una modalidad cómoda. Si una falsa aceptación es catastrófica (mover dinero, cruzar una frontera), afina estricto, exige liveness probado, y considera un segundo rasgo o un segundo factor por completo.

Accesibilidad: la biometría puede excluir en silencio

Una biometría que funciona para la mayoría puede dejar fuera en silencio a una minoría — y eso es a la vez una falla de inclusión y, cada vez más, una legal. El Failure to Enroll (FTE) no es una métrica abstracta; son personas reales que no pueden usar tu sistema:

• Trabajadores manuales, adultos mayores y algunas condiciones médicas producen huellas gastadas o difíciles de leer.
• Ciertas discapacidades, lesiones o condiciones oculares interfieren con la captura de iris o facial.
• Impedimentos del habla o entornos ruidosos rompen la voz.
• Los sistemas faciales y otros han mostrado brechas de desempeño demográficas — tasas de error más altas para algunos tonos de piel, edades o géneros cuando los datos de entrenamiento no eran representativos. El programa FRVT de NIST mide explícitamente los diferenciales demográficos, e ignorarlos despacha un sistema que es menos preciso para algunos de tus usuarios que para otros.

La regla que se sigue es firme: la biometría debe tener siempre un fallback equivalente y no biométrico — un PIN, una passkey, un token hardware — que no sea más débil que la biometría a la que respalda. Un fallback tan débil que los atacantes lo apunten en su lugar (el problema de la vía de recovery del artículo de MFA) frustra el propósito; uno tan incómodo que los usuarios excluidos queden efectivamente bloqueados frustra la inclusión. Diseña el fallback como una vía de primera clase, no una ocurrencia tardía.

Envejecimiento del template: el enrolamiento no es para siempre

Una sutileza que hace tropezar a despliegues reales: los rasgos biométricos derivan. Los rostros envejecen, ganan y pierden peso, dejan barba; las huellas se gastan con el trabajo manual; las voces cambian con la salud y la edad. El template capturado en el enrolamiento diverge lentamente de la muestra viva, y el resultado práctico es un FRR que sube en silencio con el tiempo — usuarios legítimos rechazados cada vez más, no porque el sistema empeorara, sino porque ellos cambiaron respecto a una referencia congelada.

Los sistemas maduros manejan esto con actualización de template: refrescando con cautela el template almacenado a medida que el usuario se autentica con éxito, para que siga el cambio gradual. Esto debe hacerse con cuidado — actualiza con demasiada ansia y un casi-acierto de un atacante podría envenenar el template; actualiza desde matches fallidos y entrenarías al sistema para aceptar a la persona equivocada. Así que las actualizaciones ocurren solo en verificaciones exitosas de alta confianza. Algunos despliegues también programan re-enrolamiento periódico. La conclusión para un diseñador: la precisión biométrica no es un número fijo de ficha técnica sino un valor que decae sin mantenimiento, y tu plan operativo debe tomarlo en cuenta.

Cómo encajan la biometría y las passkeys

El lugar más limpio donde vive la biometría en la autenticación moderna es detrás de una passkey, y entender por qué ata todo este artículo con los anteriores. Una passkey (credencial FIDO2/WebAuthn) mantiene una clave privada en el hardware seguro del dispositivo. Tu huella o rostro no te autentica ante el servidor — desbloquea la clave privada local, que luego firma el desafío del servidor. La biometría nunca sale del dispositivo; la red solo ve una firma criptográfica.

Este arreglo te da lo mejor de ambos mundos y esquiva el peor riesgo de la biometría:

• El problema de la filtración irreversible desaparece en el servidor — no hay base biométrica central que romper, porque el rasgo se queda en el enclave.
• El liveness y el matching los maneja la plataforma (Touch ID, Face ID, Windows Hello), que invierte fuerte en PAD que a ti te costaría construir.
• La experiencia de usuario es exactamente la que la gente ya espera: “mira tu teléfono” o “toca el sensor” para iniciar sesión.

Así que en la práctica, el diseño de autenticación de consumo más fuerte no es “agregar reconocimiento facial a nuestro login”. Es “adoptar passkeys, y dejar que la biometría de la plataforma las desbloquee.” La biometría se vuelve la cómoda compuerta local sobre un factor criptográfico resistente a phishing — que es justo por qué los artículos de factores y de MFA seguían apuntando aquí.

Recapitulación

La biometría es el factor donde los detalles deciden todo:

1. Las modalidades difieren en costo, precisión y facilidad de spoofing; la división más profunda es verificación (1:1) vs identificación (1:N) y fisiológica vs comportamental.
2. El matching es un puntaje de similitud contra un umbral — nunca un sí/no limpio.
3. FAR/FRR son dos extremos de un mismo umbral; el EER compara sistemas pero rara vez es el punto de operación; exige siempre el FAR con su FRR, más FTE y FTA.
4. El liveness / PAD es innegociable — un matcher sin él lo vence una foto, grabación o deepfake.
5. El almacenamiento debe evitar imágenes raw, preferir templates protegidos/cancelables, e idealmente hacer match en el dispositivo, en hardware seguro — porque una filtración biométrica es irreversible.
6. BIPA, GDPR Art. 9 y las leyes locales de datos sensibles te obligan: consentimiento, minimización, límites de retención y un fallback inclusivo.
7. La biometría comportamental es una señal silenciosa, continua y auxiliar que brilla contra el account takeover.

Tres preguntas para autoevaluarte

1. Un proveedor anuncia un sistema facial con un EER de 0.4%. ¿Qué tres preguntas de seguimiento haces antes de confiarle un flujo de autorización de pagos?
2. Tu equipo de producto quiere almacenar templates faciales en una base cloud central “para que los usuarios inicien sesión desde cualquier dispositivo.” Explica el riesgo específico que esto crea y que una base de contraseñas no tiene, y propón una arquitectura que cumpla el mismo objetivo sin biometría raw central.
3. Te piden agregar login por huella a una app de almacén usada por trabajadores cuyas huellas suelen estar gastadas o sucias. ¿Qué dos métricas de error vigilas más de cerca, y qué fallback diseñas para que ningún trabajador quede bloqueado?

Ejercicios prácticos

1. Lee el punto de operación de una ficha real. Encuentra un reporte público NIST FRVT o FpVTE (o una ficha de proveedor que lo cite) y localiza un par FAR/FRR a un umbral declarado. Escribe una frase describiendo el punto de operación en lenguaje llano (“a una tasa de falsa aceptación de 1 en N, alrededor del M% de los usuarios legítimos son rechazados”).
2. Audita tus propios dispositivos. Para un teléfono y una laptop que uses, determina dónde almacena cada uno su template biométrico (secure enclave / TEE / otro) y si el matching ocurre en el dispositivo. Anota si la biometría alguna vez sale del dispositivo.
3. Redacta un aviso de consentimiento. Escribe un aviso corto estilo BIPA para enrolar empleados en un reloj checador por huella: qué recolectas, por qué, cuánto lo conservas, cuándo lo destruyes y la alternativa para quien decline. Contrástalo con la exigencia de consentimiento explícito del Art. 9 del GDPR.