Integramos la capa de detección de vida pasiva en el onboarding de una financiera. El primer mes tuvimos rechazos altos con cámaras frontales de gama baja y luz de oficina. Ajustamos el umbral por franja horaria y el problema bajó sin abrir la puerta a ataques con pantalla. Lo que más nos sirvió fue el registro de evidencia por intento: pudimos discutir cada caso con el equipo de fraude en lugar de aceptar o rechazar a ciegas.
Preguntas que aparecen en cada auditoría de liveness
Recogemos aquí las dudas que más se repiten cuando un equipo evalúa si su verificación de presencia resiste ataques generativos. Sin jerga innecesaria y sin prometer milagros.
¿Basta con pedir un parpadeo para confirmar que hay una persona real?
No. Un parpadeo grabado y reproducido en el momento correcto supera esa prueba. Sirve como capa adicional, pero necesita correlación con microtextura de piel, coherencia temporal entre fotogramas y respuesta al reto. Si el umbral depende solo del gesto, cualquier atacante con paciencia lo resuelve.
¿Qué diferencia hay entre una prueba activa y una pasiva en producción?
La activa exige que el usuario haga algo y eleva el coste del ataque, pero añade fricción y depende del entorno: luz, cámara, nervios. La pasiva analiza señales sin pedir nada, aunque es más frágil ante compresión de vídeo o iluminación pobre. Los despliegues serios combinan ambas y ajustan el umbral según el riesgo de la operación, no según una cifra única.
¿Cómo se detecta una cámara virtual o un flujo inyectado con OBS?
No hay un indicador aislado que lo resuelva. Se observan inconsistencias de ruido de sensor, marcas de doble compresión, geometría de lentes y latencia anómala entre fotogramas. El valor real está en correlacionar varias señales y dejar registro de evidencia para auditoría posterior, porque un solo artefacto puede tener explicación legítima.
¿Por qué una tasa de error baja en laboratorio no se traduce en producción?
Porque el conjunto de prueba rara vez reproduce la mezcla real de dispositivos, iluminación y compresión. APCER y BPCER se mueven en direcciones opuestas al ajustar el umbral, y un motor puede verse impecable en un banco controlado y fallar cuando cambia el parque de móviles. Evaluar exige declarar el punto de operación y revisar subgrupos demográficos y de hardware.
¿Qué evidencia conviene guardar cuando se rechaza una verificación?
Fotogramas clave, marcas de tiempo, versión del SDK, señales calculadas y motivo del rechazo. Sin ese paquete, una apelación del usuario se convierte en un intercambio de opiniones. Con él, se puede reconstruir qué vio el sistema y por qué decidió lo que decidió, algo imprescindible si el caso escala a revisión manual.
¿Cómo se mantiene actualizado un motor frente a nuevas técnicas generativas?
Con ciclos cortos de reentrenamiento y un flujo constante de muestras de ataque reales, no solo sintéticas. Los modelos de difusión cambian rápido y lo que ayer funcionaba hoy deja residuos distintos. Conviene reservar un conjunto de validación que no se use para entrenar y revisar el rendimiento por subgrupos antes de subir cualquier versión a producción.
Si tu caso no encaja en ninguna de estas preguntas, revisa primero las condiciones de uso y luego escríbenos con el detalle técnico.