La mayoría de los proveedores de sistemas de detección de presencia en vivo te mostrarán la misma demostración: un teléfono, un rostro y una marca de verificación verde. Eso no te dice prácticamente nada sobre cómo se comporta el sistema cuando alguien intenta realmente burlarlo.
Esta guía te ofrece un marco de referencia para evaluar el software de detección de presencia en función de los aspectos que diferencian a un proveedor de otro una vez finalizada la fase piloto y cuando comience el volumen real de trabajo. Aquí no clasificamos los productos. Las clasificaciones de proveedores pierden vigencia rápidamente, y la elección adecuada depende de tu canal, tus dispositivos y tu contexto normativo. Lo que no cambia es el conjunto de preguntas que vale la pena plantearse.
Los deepfakes son cada vez más sofisticados, lo que aumenta el riesgo de fraude y manipulación de la identidad en entornos digitales. Descargue nuestra guía de 10 pasos para aprender a detectar amenazas de forma temprana y proteger su organización con prácticas recomendadas de eficacia probada.
Contra qué protege realmente el software de detección de presencia
La detección de vida responde a una pregunta: ¿la muestra biométrica que se encuentra delante de la cámara procede de una persona real que está físicamente presente en este momento?
Esa pregunta se divide en dos superficies de ataque muy diferentes, y es aquí donde surge gran parte de la confusión entre los compradores.
Los ataques de presentación se producen delante de la cámara. Alguien muestra una fotografía impresa, reproduce un vídeo en una segunda pantalla o lleva puesta una máscara de silicona. El sensor detecta algo real, pero no a una persona real. Esta es la categoría que abarca la norma ISO/IEC 30107, y la norma deja claro que se refiere a los ataques que tienen lugar en el dispositivo de captura durante la presentación.
Los ataques de inyección eluden por completo la cámara. El atacante introduce un flujo de vídeo sintético directamente en la aplicación, utilizando una cámara virtual, un emulador o un dispositivo comprometido. No se envía absolutamente nada a ningún sensor, por lo que un sistema que solo evalúe el contenido de la imagen puede verse engañado por un deepfake bien elaborado. Estos ataques quedan fuera del ámbito de aplicación de la norma ISO/IEC 30107-3, lo que significa que un certificado PAD no dice nada al respecto.
Un proveedor puede destacar en un aspecto y tener carencias en otro. A la hora de comparar programas de detección de actividad, considéralos como dos aspectos independientes, en lugar de como una única puntuación.
Criterio 1: certificación PAD independiente conforme a la norma ISO/IEC 30107-3
Solicita los resultados de evaluaciones realizadas por terceros, no comparativas internas. La norma pertinente es la ISO/IEC 30107-3, que define cómo se prueban y se comunican los resultados de la detección de ataques de presentación. Estas evaluaciones las llevan a cabo laboratorios independientes, y los resultados son lo más parecido que tiene el sector a un lenguaje común.
Hay dos detalles que son más importantes que el propio certificado.
Los niveles 1, 2 y 3 no son la misma prueba
El nivel 1 abarca medios de ataque de menor coste, como fotografías impresas y grabaciones de pantalla.
El nivel 2 abarca instrumentos más sofisticados, incluidas máscaras hechas a medida, y las evaluaciones del nivel 3 introducen instrumentos de ataque que reflejan un mayor esfuerzo y más recursos por parte del atacante, como las máscaras de «Misión Imposible» de Tom Cruise.
Un proveedor que dice «certificado por iBeta» sin especificar el nivel no te ha dicho prácticamente nada.
Comprueba la métrica junto al nivel. Las evaluaciones de subsistemas suelen indicar el APCER, pero es obligatorio confirmar también el BPCER, es decir, las tasas de error de clasificación para los ataques y para los usuarios legítimos. Las evaluaciones completas del sistema indican el IAPMR, la tasa a la que un ataque se identifica erróneamente como un usuario legítimo. Estas métricas no son intercambiables, y un buen resultado en una de ellas no dice nada sobre la otra; por ello, es importante encontrar un equilibrio entre la seguridad y la usabilidad.
Los resultados dependen de las condiciones de la prueba
Cualquier cifra que se te muestre, incluido un resultado de cero falsas aceptaciones, describe el rendimiento frente a los instrumentos de ataque específicos utilizados en esa evaluación, según el protocolo de ese laboratorio y en esa fecha. Es una señal clara. No es una garantía frente a tipos de ataque que no formaran parte del alcance de la evaluación. Un proveedor que explique esta distinción por iniciativa propia suele ser el que mejor conoce su propio sistema.
Evaluaciones impulsadas por el Gobierno
Más allá de la certificación de los laboratorios, hay que fijarse en la participación en programas impulsados por el Gobierno. La Dirección de Ciencia y Tecnología del DHS llevó a cabo el «Remote Identity Validation Rally» hasta 2025, en el que se evaluaron la validación de documentos, la comparación entre selfies y documentos y la detección de ataques de presentación en las instalaciones de pruebas de Maryland, cuyos resultados se publicaron utilizando identificadores de sistema anonimizados.
RIVR resulta útil por una razón concreta: realiza pruebas con participantes humanos en condiciones más cercanas a la implantación real y presenta, en paralelo, métricas tanto de seguridad como de usabilidad. Esa combinación pone de manifiesto la disyuntiva que la mayoría de las presentaciones de los proveedores ocultan. Un sistema puede no sufrir ningún ataque y, aun así, rechazar a una proporción significativa de usuarios legítimos, y RIVR hace visibles ambas cifras a la vez. El mero hecho de estar dispuesto a someterse a esa evaluación pública ya es, en sí mismo, revelador.
Criterio 2: vitalidad pasiva o vitalidad activa
La «vitalidad activa» pide al usuario que haga algo: parpadear, girar la cabeza, seguir un punto o leer un número en voz alta. La «vitalidad pasiva» analiza la captura sin solicitar ninguna acción.
Las comprobaciones activas fueron la primera respuesta a los ataques de presentación, y siguen teniendo su lugar en los flujos de alto riesgo. El coste se mide en términos de abandono. Cada instrucción supone un momento en el que el usuario malinterpreta, se frustra o se rinde, y el efecto no se distribuye de manera uniforme. Los usuarios de más edad, los que tienen movilidad reducida y los que utilizan dispositivos antiguos abandonan con mayor frecuencia.
La «vitalidad pasiva» elimina esa fricción, pero solo si es verdaderamente pasiva. Algunos sistemas que se describen como pasivos siguen requiriendo un encuadre específico o un acercamiento lento a la cámara. Pide que te muestren la experiencia real de captura en un dispositivo Android de gama media, no en el teléfono de demostración.
Ten en cuenta que ambas se evalúan de forma diferente. Las evaluaciones pasivas procesan muestras recopiladas previamente, mientras que las evaluaciones activas analizan el proceso completo de captura con usuarios reales; por eso, el tiempo de transacción y la satisfacción solo aparecen en los resultados activos. Comparar una puntuación pasiva con una activa no es una comparación equivalente.
La cuestión práctica no es qué enfoque es mejor, sino si el proveedor te permite configurar el nivel de seguridad para cada nivel de riesgo, de modo que un inicio de sesión rutinario y la apertura de una cuenta de alto valor no tengan que seguir el mismo proceso.
Criterio 3: procesamiento en el dispositivo o en el servidor
Pregunta dónde se analiza la muestra biométrica. ¿En el dispositivo o en un servidor tras su carga? El procesamiento en el propio dispositivo cambia varias cosas a la vez. La imagen sin procesar no tiene que salir del teléfono, lo que reduce los riesgos en materia de protección de datos y simplifica las conversaciones con los equipos jurídicos y de cumplimiento normativo. La latencia se reduce, ya que no hay ida y vuelta. Además, el flujo sigue funcionando incluso cuando la conectividad es deficiente, lo cual es mucho más importante en operaciones sobre el terreno, sucursales rurales y mercados emergentes de lo que la mayoría de las presentaciones de los proveedores reconocen.
El procesamiento del lado del servidor tiene sus propias ventajas, entre las que se incluyen unas actualizaciones más sencillas de los modelos y un registro centralizado. La cuestión no es que una arquitectura sea mejor que otra. La cuestión es que se trata de una decisión arquitectónica con consecuencias posteriores para las evaluaciones de privacidad, el coste por transacción y el alcance geográfico, y debe tomarse de forma deliberada, en lugar de heredarse del proveedor que se haya elegido.
Criterio 4: detección de ataques por inyección e integridad de la cadena de captura
Aquí es donde se ganan o se pierden los ataques por inyección, y es el criterio que suele faltar con mayor frecuencia en las listas de verificación de evaluación.
Un motor de detección de movimiento que recibe un fotograma de vídeo no tiene forma de saber si ese fotograma procede de la cámara del dispositivo o de un programa que simula ser la cámara del dispositivo.
La protección debe integrarse en el punto de captura. Busca proveedores que puedan explicar, en términos técnicos, cómo vinculan la muestra capturada al sensor físico y cómo detectan emuladores, cámaras virtuales y entornos de ejecución manipulados.
Pregunta directamente: ¿qué ocurre si ejecuto vuestro SDK biométrico en un dispositivo rooteado con una cámara virtual que genera un vídeo deepfake? Una buena respuesta debe ser concreta. Una respuesta vaga sobre la detección avanzada mediante IA suele significar que la comprobación se realiza tras la captura, lo cual es en una capa equivocada.
Obtenga una demostración personalizada de nuestra plataforma biométrica sin contacto y compruebe cómo se adapta a su caso de uso específico.
Criterio 5: cobertura para todos los usuarios y dispositivos
La detección de presencia en vivo tiene que funcionar para todas las personas que necesiten utilizarla, no para el usuario medio de vuestra base de usuarios. Solicita datos de rendimiento desglosados por grupo demográfico, por categoría de dispositivo y por condiciones de iluminación. Los sistemas que funcionan bien en conjunto pueden, aun así, fallar de forma desproporcionada con determinados tonos de piel, edades o clases de dispositivos, y esos fallos se traducen en incidencias de asistencia técnica, visitas a las oficinas y solicitudes abandonadas. La cobertura de dispositivos merece una pregunta aparte.
Si entre tus usuarios hay personas que utilizan teléfonos Android básicos con cámaras frontales sencillas, comprueba que el sistema funcione en ese tipo de hardware, en lugar de requerir sensores de profundidad o chipsets de última generación. La universalidad es una propiedad técnica, y merece la pena probarla antes de dar el paso.
Criterio 6: Integración del SDK y documentación
La calidad de la documentación es un indicador razonable de la calidad de la ingeniería. Antes de firmar, pide a uno de tus propios desarrolladores que integre el SDK en un entorno de pruebas y que cronometre el tiempo que tarda.
Aspectos concretos que hay que comprobar:
- Cobertura de plataformas para los entornos en los que realmente lanzas tus aplicaciones, incluyendo iOS y Android nativos, así como cualquier marco web o híbrido de tu pila tecnológica
- El tamaño del SDK y su efecto en el paquete de tu aplicación
- Cómo se distribuyen las actualizaciones de los modelos y si requieren una versión completa de la aplicación
- Si la interfaz de usuario es lo suficientemente personalizable como para adaptarse a tu marca sin tener que crear una rama del código
- Cómo es la ruta alternativa cuando falla la comprobación de actividad, y si dicha ruta es auditable
Criterio 7: preguntas que hay que plantear en una demostración de detección de presencia
Llévalos a la reunión con los proveedores.
- ¿En qué nivel de la norma ISO/IEC 30107-3 se le ha evaluado, qué laboratorio lo ha realizado y en qué fecha?
- ¿Qué instrumentos de ataque se incluían en el ámbito de aplicación y cuáles no?
- ¿Cuáles fueron tus valores de APCER y BPCER, o tu IAPMR, y qué parámetro se aplica a tu tipo de evaluación?
- ¿Cómo se detectan los ataques por inyección y en qué capa?
- ¿El procesamiento se realiza en el dispositivo, en el servidor o es configurable?
- ¿Puedo ver el rendimiento desglosado por grupo demográfico y categoría de dispositivo?
- ¿Cuáles son los requisitos mínimos de hardware que admiten?
- ¿Qué ocurre con la imagen capturada una vez tomada la decisión?
Las respuestas que obtengas a las preguntas dos, tres y seis te darán más información que cualquier tabla comparativa.
Cómo elegir el mejor software de detección de vida para tu perfil de riesgo
A la hora de elegir un software de detección de presencia, no se trata tanto de buscar la puntuación más alta como de adaptar el sistema al lugar donde realmente se encuentra el riesgo. Un proceso de alta a distancia para un banco digital presenta un perfil de amenaza diferente al de una verificación de identidad en una sucursal o al de un inicio de sesión de un usuario habitual.
Empieza por identificar cuáles de tus flujos de trabajo están expuestos a ataques de presentación, cuáles a ataques de inyección y cuáles a ambos. A continuación, evalúa a los proveedores en función de ese análisis, en lugar de basarte en una lista genérica de características. El proveedor que sea capaz de explicar con claridad sus propias limitaciones suele ser el que seguirá en activo dentro de tres años.
Obtenga una demostración personalizada de nuestra plataforma biométrica sin contacto y compruebe cómo se adapta a su caso de uso específico.
Referencias
- ISO/IEC 30107-3:2023, Tecnología de la información. Detección de ataques de presentación biométrica. Parte 3: Ensayos y elaboración de informes, 2.ª edición, enero de 2023. ISO/IEC JTC 1/SC 37. https://www.iso.org/standard/79520.html
- ISO/IEC 30107-1:2016, Tecnología de la información. Detección de ataques de presentación biométrica. Parte 1: Marco de referencia. ISO/IEC JTC 1/SC 37. https://www.iso.org/standard/53227.html
- iBeta Quality Assurance, ISO 30107-3: Presentación de la metodología de ensayo para la detección de ataques y cartas de confirmación. https://www.ibeta.com/iso-30107-3-presentation-attack-detection-confirmation-letters/
- Departamento de Seguridad Nacional de EE. UU., Dirección de Ciencia y Tecnología, Encuentro sobre validación remota de la identidad. https://www.dhs.gov/science-and-technology/remote-identity-validation-rally
- DHS S&T, «DHS S&T anuncia un nuevo encuentro sobre validación remota de la identidad», comunicado de prensa, 6 de marzo de 2025. https://dhs.gov/science-and-technology/news/2025/03/06/dhs-st-announces-new-remote-identity-validation-rally
- Centro de pruebas de Maryland, prueba de validación de identidad a distancia: resultados. https://mdtf.org/rivr/Results
- Biometric Update: Pruebas de vida activa y pasiva de Aware en la pista biométrica PAD de RIVR, abril de 2026. https://www.biometricupdate.com/202604/aware-active-and-passive-liveness-tested-in-rivrs-biometric-pad-track
- Identy.io, «Identy.io logra una tasa de aceptación de ataques del 0 % en la evaluación de autenticidad facial RIVR del DHS», Business Wire, 18 de marzo de 2026. https://businesswire.com/news/home/20260318279525/en/Identy.io-Achieves-Zero-Attack-Acceptance-in-DHS-RIVR-Face-Liveness-Evaluation-Leads-Field-on-Speed-and-User-Satisfaction
- Identy.io, ISO/IEC 30107-3 PAD Nivel 2: Guía para compradores de sistemas biométricos. https://www.identy.io/iso-iec-30107-3-pad-level-2-biometric-buyer-guide/
