Un portal técnico sobre detección de vida y anti-spoofing: cómo se comprueba que hay una persona física delante de la cámara, qué señales delatan un rostro sintetizado y cómo se calibran los umbrales cuando el riesgo cambia. Material de trabajo para equipos que despliegan identificación remota y necesitan evidencia defendible, no solo una puntuación de confianza.
La detección de vida no es una casilla más del onboarding. Es la capa que decide si la persona frente a la cámara existe en ese momento y en ese dispositivo. Estos son los resultados que nuestros clientes reportan al integrar anti-spoofing con liveness en sus flujos de identificación.
Los retos activos combinados con análisis pasivo de microtextura y coherencia temporal elevan el coste de un ataque por reproducción. Un video grabado en pantalla deja marcas de doble compresión y desajustes de reflejo que el motor correlaciona antes de aceptar la sesión.
Cuando el flujo de video se sustituye antes de llegar al SDK, el ruido de sensor desaparece y la latencia entre fotogramas se vuelve anómala. Registramos esa evidencia para que su equipo de fraude pueda auditar cada rechazo con datos, no con sospechas.
No todas las verificaciones exigen el mismo rigor. Un alta de cuenta nueva tolera más fricción que un acceso recurrente. Configuramos el punto de operación entre APCER y BPCER según el tipo de trámite, el dispositivo y el historial del usuario.
Cada sesión queda con marcas de tiempo, señales capturadas y decisión del motor. Su equipo legal y de cumplimiento puede reconstruir qué ocurrió sin depender de capturas manuales ni de registros dispersos entre sistemas.
Una tasa global de error esconde fallos en cámaras de gama baja, tonos de piel oscuros o condiciones de contraluz. Publicamos el rendimiento desglosado para que usted sepa dónde va a fallar antes de que lo haga en producción.
Ver casos de uso por sector · Conocer el enfoque técnico del laboratorio
Ruta de verificación
Cada solicitud recorre una cadena de decisiones donde se cruzan señales de sensor, coherencia temporal y umbrales de riesgo. El orden importa: si una etapa se salta, el resultado deja de ser auditable.
El sistema identifica el tipo de operación (alta de cuenta, acceso, firma) y asigna un nivel de exigencia. No es lo mismo validar un inicio de sesión rutinario que autorizar una transacción sensible.
Se abre la cámara y se registran condiciones de luz, resolución y estabilidad del dispositivo. Una captura mal iluminada o con compresión agresiva condiciona todo lo que viene después.
Según el perfil de riesgo, se pide un reto concreto (movimiento, parpadeo, respuesta) o se analizan señales pasivas como microtextura de piel y reflejos. Cada capa cubre lo que la otra no ve.
Se revisan marcas de doble compresión, ruido de sensor y latencia entre fotogramas para descartar cámaras virtuales o flujos sintéticos insertados antes del SDK.
El motor emite un veredicto con su punto de operación declarado y guarda los indicadores que lo sustentan. Sin ese registro, una revisión posterior no tiene nada que auditar.
Los casos dudosos pasan a revisión manual y alimentan la calibración del umbral. El objetivo no es bajar la tasa de error a cualquier coste, sino sostenerla entre dispositivos y condiciones reales.
Para entender cómo se elige el punto de operación en producción, conviene revisar los casos de uso documentados y el detalle de cómo trabajamos la validación.
Respuestas directas sobre liveness, inyección de vídeo y umbrales de decisión. Sin jerga legal ni promesas de precisión absoluta: solo cómo funciona el sistema y qué conviene medir antes de ponerlo en producción.
La activa pide una acción concreta al usuario: girar la cabeza, seguir un punto o leer una frase corta. Sube el coste de un ataque grabado, pero añade fricción y depende de la cámara y la luz del entorno. La pasiva trabaja en segundo plano con microtextura de piel, reflejos especulares y coherencia temporal entre fotogramas. En operaciones reales se combinan ambas capas y el umbral se ajusta según el riesgo de la transacción, no según una única cifra de precisión.
Los ataques de inyección sustituyen la señal física antes de que llegue al SDK. Se detectan por inconsistencias de ruido de sensor, marcas de doble compresión, geometría de lentes imposible y latencias anómalas entre fotogramas. Ningún indicador aislado basta: el valor está en correlacionar señales y guardar evidencia para auditoría posterior.
APCER mide la aceptación de ataques y BPCER el rechazo de usuarios legítimos. Se mueven en direcciones opuestas al ajustar el umbral, así que una cifra suelta de error no dice nada útil. Para evaluar un motor hay que fijar el punto de operación, declarar la composición del conjunto de prueba y revisar el rendimiento por subgrupos de hardware y demografía.
Los ataques de presentación con foto impresa, pantalla o máscara siguen siendo frecuentes porque son baratos. Un motor entrenado solo con caras reales falla ante ellos. La defensa práctica combina análisis de textura, respuesta al parpadeo y estimación de profundidad; en mascarillas y pantallas de alta resolución, la clave es la coherencia entre canales, no la resolución de la imagen.
No hay un umbral universal. Se fija según el coste de un falso positivo frente al de un falso negativo en cada operación: un alta de cuenta bancaria tolera más fricción que un acceso recurrente. Lo razonable es registrar el punto de operación, monitorizar la deriva con datos de producción y revisar el umbral cuando cambian los dispositivos o la iluminación.
Fotogramas clave, marcas de tiempo, versión del modelo, resultado por señal y puntuación de confianza. Guardar solo el veredicto final impide reconstruir por qué se aceptó o rechazó una sesión. Con ese registro se puede auditar un caso concreto, comparar versiones del motor y detectar patrones de ataque que no aparecían en el conjunto de prueba.
Si necesitas revisar el marco de tratamiento de datos antes de integrar, consulta la política de privacidad o escríbenos desde contacto.