Regula SDK FAQs: Respuestas a todas las preguntas importantes sobre nuestros SDKs

Regula Document Reader SDK es una solución multiplataforma para la lectura y verificación de documentos de identidad. Funciona con pasaportes, tarjetas de identidad, licencias de conducir, visas, permisos de residencia y otros tipos de documentos. El SDK extrae datos de las zonas visuales, de las MRZ y de los códigos de barras, lee chips RFID cuando son compatibles, y ejecuta comprobaciones de autenticidad y comprobación liveness de documentos para confirmar que el documento es una identificación física real y no una copia o una reproducción digital.

Regula Face SDK gestiona la verificación biométrica. Realiza la comprobación de los rostros uno a uno, busca en una base de datos de descriptores faciales almacenados (1:N) y lleva a cabo prueba de vida y detección de ataques de presentación (PAD). Estas comprobaciones están diseñadas para detectar intentos de fraude comunes y avanzados, incluidas capturas de pantalla, reproducciones de video, flujos de video inyectados, máscaras y otras técnicas de suplantación, y para confirmar que una persona real está presente frente a la cámara.

Ambos SDKs suelen utilizarse conjuntamente. Document Reader SDK extrae las fotos del titular del documento, y Face SDK las compara con una selfie en vivo, lo que le permite verificar que la persona que presenta el documento coincide con el titular del documento.

Ambos SDKs están diseñados para ejecutarse dentro del propio entorno del cliente. Se implementan on-premises o en una nube privada, dentro del perímetro de seguridad del cliente. Las imágenes de documentos, los datos biométricos y los resultados del procesamiento no se comparten con Regula ni con terceros. Los SDKs exponen APIs que sus aplicaciones invocan dentro de su infraestructura, y todas las decisiones se toman allí.

Estos componentes están destinados a integrarse en sistemas web, móviles, de escritorio y de servidor utilizados para KYC, onboarding, prevención de fraude, control de acceso y flujos de trabajo de control fronterizo.

Los SDKs de Regula son soluciones on-premises totalmente multiplataforma que admiten las siguientes plataformas:

• iOS/Android/frameworks multiplataforma para componentes móviles

• Aplicaciones web

• Paquetes Linux/Windows/Docker disponibles para la distribución de servicios

Ya sea que esté trabajando en una aplicación móvil, web o de escritorio, los SDKs de Regula ofrecen la misma funcionalidad para todas las plataformas y arquitecturas.

Los entornos compatibles incluyen distribuciones de Linux como Debian, Ubuntu y Red Hat, Windows, contenedores Docker (incluidas imágenes certificadas de Red Hat) y Kubernetes con gráficos Helm.

Los SDKs de Regula se implementan (se instalan y ejecutan) on-premises, lo que significa que todo el procesamiento se realiza directamente en los servidores del cliente. Por lo tanto, Regula no almacena, procesa, recibe ni transfiere ningún dato a terceros. El control de acceso, la auditabilidad y las restricciones quedan fuera del alcance de nuestro producto, y son aplicables únicamente a los desarrolladores de soluciones de extremo a extremo.

Actualmente, Regula no ofrece servicios SaaS ni de hosting. Después de integrar el SDK, el cliente obtiene control total sobre el flujo de datos, la integridad y el almacenamiento, lo que hace que Regula cumpla con los protocolos de seguridad y cumplimiento. Cuando vea “cloud” en los materiales de Regula, se refiere a una infraestructura bajo su control, no a una plataforma compartida alojada y operada por Regula.

La seguridad informática es una prioridad extremadamente alta y natural para Regula: nuestros procedimientos incluyen (entre otros) pruebas de penetración, evaluaciones de vulnerabilidades, revisiones de código y verificaciones de cumplimiento con estándares de la industria como ISO 27001. Además, actualizamos periódicamente nuestros protocolos de seguridad y realizamos monitoreo continuo para identificar y abordar de manera proactiva cualquier posible vulnerabilidad.

En cuanto a certificaciones específicas:

1. Regula cumple con la normativa de la OACI (ICAO). Asimismo, nuestras soluciones cumplen plenamente con los requisitos de eIDAS y ETSI, y son compatibles con los estándares de chips RFID ISO/IEC 14443-2, ISO/IEC 14443-3 e ISO/IEC 14443-4.

2. Regula Face SDK ha sido probado y está certificado bajo el nivel 1 y 2 de Presentation Attack Detection (PAD) de iBeta (ISO/IEC 31007-3) para autenticación biométrica y reconocimiento facial.

3. Regula cuenta con la certificación ISO 27001, lo que garantiza el cumplimiento de estándares internacionales para la gestión de la seguridad de la información.

4. Los algoritmos de Regula Face SDK se someten a pruebas continuas y se evalúan mediante programas como Face Analysis Technology Evaluation (FATE).

5. Regula también dispone de certificaciones adicionales específicas de la industria que validan la seguridad de la plataforma, su fiabilidad y el cumplimiento normativo.

Puede encontrar más información sobre nuestros certificados aquí.

En el modelo de implementación estándar, no lo hacen.

Las imágenes, los contenidos de los chips y las muestras biométricas se envían desde sus clientes a sus propias instancias de los Regula Web Services, o a su propio backend que se integra directamente con los SDKs. Los Web Services procesan los datos en memoria y devuelven resultados estructurados en formato JSON.

Puntos clave:

• La verificación de documentos, la prueba de vida y la comprobación de los rostros se ejecutan en su infraestructura.

• No existe un servicio externo de revisión humana que vea los documentos o las selfies de sus usuarios.

• Las comprobaciones están automatizadas de principio a fin.

Si desea utilizar AML, PEP, listas de sanciones u otras fuentes de datos externas, puede hacerlo en sus propios sistemas utilizando la salida JSON de los SDKs como entrada.

Regula proporciona abundante material gratuito:

• Un Developer Hub con documentación técnica completa para ambos SDKs, que cubre instalación, configuración, APIs, escenarios, parámetros, notas de versión y arquitectura.

• Demos Web API para Document Reader SDK y para Face SDK, donde puede realizar la verificación de documentos, la comprobación de los rostros y ver la prueba de vida/PAD en acción, y luego inspeccionar los resultados JSON.

• Aplicaciones demo e interfaces de ejemplo para iOS y Android que le permiten probar los flujos de captura de documentos y de rostro en dispositivos móviles, en un enfoque similar al de las demos web.

• Artículos y contenido del centro de expertos sobre temas como certificados para documentos electrónicos, requisitos de calidad de imagen y uso de los SDKs en diferentes entornos.

• Una sección de confianza y certificados que enumera el cumplimiento de estándares y las certificaciones de terceros.

Para pruebas más realistas, puede solicitar una licencia de prueba y ejecutar los SDKs con su propio conjunto de datos en un entorno controlado.

Existen tres modelos principales de licenciamiento:

1. Licenciamiento basado en transacciones (en línea): Este modelo utiliza una licencia en línea que se comunica con el servidor de licencias. Usted paga en función del número de transacciones. Funciona en Web API, SDKs móviles, componentes web y componentes de escritorio, y permite un número ilimitado de instancias. Las licencias se renuevan automáticamente a través del servicio de licenciamiento.

2. Licenciamiento basado en sesiones (en línea): En este modelo, usted licencia por sesiones en lugar de llamadas individuales. Una sesión agrupa varias operaciones en una sola unidad, por ejemplo, un escaneo de documento seguido de prueba de vida y comprobación de los rostros, marcadas con la misma etiqueta. Nota: Esta opción es exclusiva para empresas (enterprise-only) y está disponible únicamente para licencias con 100.000 sesiones al año o más.

3. Licenciamiento de tarifa fija (offline, bajo ciertas condiciones): Un modelo de tarifa fija en el que el uso no está limitado por el número de transacciones, sino por la capacidad licenciada. Para implementaciones de Web API, esto generalmente se expresa como un número limitado de instancias de servidor. Para móvil, normalmente está vinculado a una aplicación móvil específica (y en la práctica también al número permitido de usuarios/instalaciones, según el acuerdo). Este modelo no requiere una conexión a internet constantemente disponible, pero conlleva restricciones adicionales y se ofrece bajo ciertas condiciones, por lo que es recomendable analizarlo con el equipo de ventas.

En la práctica, muchos clientes prefieren el licenciamiento basado en transacciones porque funciona en más plataformas y evita pasos de renovación manual.

El SLA estándar de Regula para incidentes relacionados con Document Reader SDK utiliza tres niveles de severidad.

1. Prioridad 1 (Urgente): Las operaciones del negocio están detenidas o los datos no pueden procesarse. Respuesta en un plazo de 12 horas, solución alternativa en un plazo de 3 días hábiles, solución permanente en un plazo de 15 días hábiles.

2. Prioridad 2 (Alta): Existe un problema grave, pero una solución alternativa permite que el sistema siga operando. Respuesta en un plazo de 24 horas, solución alternativa en un plazo de 5 días hábiles, solución permanente en un plazo de 30 días hábiles.

3. Prioridad 3 (Baja): Fallos que no afectan al servicio o solicitudes de funcionalidades. Respuesta en un plazo de 72 horas, solución alternativa en un plazo de 60 días hábiles, solución permanente en la siguiente versión del producto.

El soporte estándar está incluido durante todo el período de la licencia o suscripción. Un SLA 24/7 con tiempos de respuesta más cortos está disponible como opción de pago. Regula también asume la responsabilidad por la disponibilidad y el mantenimiento de su servidor de licencias.

Debido a que los SDKs se ejecutan dentro de su entorno, el soporte efectivo generalmente depende de la cooperación. Por ejemplo, si un pasaporte específico no se lee correctamente, el equipo de soporte necesitará detalles de configuración e imágenes de muestra para reproducir e investigar el caso.

Regula Document Reader SDK lee y verifica documentos de identidad en múltiples plataformas.

En cuanto a los documentos, admite:

• Pasaportes y ePassaportes.

• Tarjetas de identidad nacionales y tarjetas de residencia.

• Licencias de conducir.

• Visas y permisos de residencia.

• Tarjetas de seguridad social y documentos similares.

• Diversos documentos especializados, como licencias marítimas o tarjetas de refugiado.

La base de datos de plantillas contiene alrededor de 16.000 plantillas de documentos de 254 países y territorios. Cada plantilla incluye información de diseño, definiciones de campos, características de seguridad y, cuando corresponde, la estructura del chip.

En el aspecto técnico, Document Reader SDK puede utilizarse:

• Como SDK nativo en plataformas móviles, de escritorio y de servidor, así como en hardware como lectores de documentos.

• Como un Web Service instalado en Linux o Windows, en contenedores o directamente en hosts.

Esto le permite utilizar la misma lógica de verificación en aplicaciones móviles, flujos basados en navegador y sistemas de back-office.

La detección automática de tipo permite que el SDK identifique qué tipo de documento está analizando sin depender de que el usuario seleccione la opción correcta en un menú.

La tecnología de detección de tipo de documento de Regula identifica automáticamente el tipo de documento. Define con precisión cada atributo clave que puede estar presente en un documento de identidad, ya sea MRZ, código de barras, etc.

Tan pronto como el documento aparece en la vista de la cámara, la tecnología de Regula analiza minuciosamente el documento y sus elementos clave, identifica su tipo y país de emisión, qué atributos clave deben estar presentes en ese tipo específico de documento, dónde encontrarlos y cómo deben verse exactamente, incluida su apariencia bajo diferentes fuentes de luz y en distintos ángulos.

A alto nivel, el SDK:

1. Recibe una imagen del documento.

2. Analiza el diseño, las fuentes, las posiciones de los campos clave y los patrones de seguridad.

3. Compara estas características con las entradas de la base de datos de plantillas.

4. Selecciona la plantilla más probable y la utiliza para el reconocimiento y la verificación.

Esta identificación de tipo de documento de alta precisión mejora adicionalmente los procesos de OCR y verificación, independientemente del tipo de documento que usted procese.

Document Reader SDK combina múltiples comprobaciones y proporciona un resultado estructurado en lugar de una simple respuesta de sí/no.

Los elementos clave incluyen:

• Extracción de datos y comprobaciones de consistencia: El SDK lee MRZ, códigos de barras y campos visuales. Valida los checksums de la MRZ, los formatos de fecha y los formatos de número de documento. Compara los valores entre la MRZ, la zona visual, los códigos de barras y los datos del chip RFID. Las discrepancias, como un nombre que difiere entre zonas, son fuertes indicadores de manipulación.

• Elementos de seguridad y comprobación liveness de documentos: El SDK verifica características como hologramas y elementos ópticamente variables cuando se esperan para una plantilla determinada. También busca señales de que un documento sea una impresión o una foto de pantalla en lugar de un documento físico, por ejemplo, mediante el análisis de patrones de ruido y otros artefactos.

• Detección de fraude basada en ML: Además de las comprobaciones basadas en reglas, el SDK aplica modelos de aprendizaje automático entrenados para detectar patrones típicos de documentos falsificados o alterados. Estos modelos ayudan a identificar artefactos sutiles que pueden no violar una regla específica, pero que aun así indican fraude, como texturas anormales, inconsistencias en la impresión o señales de manipulación digital.

• Área de foto e Información Personal Invisible (IPI): El sistema verifica que las fotos del titular estén presentes en las posiciones correctas y tengan el tamaño y la geometría esperados. Detecta métodos típicos de sustitución de la foto en la imagen principal o en la imagen fantasma. En documentos que contienen IPI, se puede confirmar su presencia en el área de la foto del titular, siempre que la resolución de la imagen sea suficiente.

• Control Automático de Autenticidad: Document Reader SDK incluye escenarios de procesamiento que encadenan estas comprobaciones en un único flujo. En dicho escenario, el sistema reconoce el documento, extrae los datos de todas las zonas relevantes y ejecuta las comprobaciones de autenticidad configuradas en un solo paso.

La salida es un informe detallado por comprobación y por campo. Posteriormente, usted aplica su propia política: por ejemplo, puede decidir que una discrepancia entre la MRZ y los datos visuales sea inaceptable, mientras que una pequeña irregularidad de formato en un campo secundario aún pueda considerarse válida.

Para los documentos que utilizan chips RFID compatibles con ISO/IEC 14443, como los ePassaportes y muchas identificaciones electrónicas, Document Reader SDK puede leer y verificar el contenido del chip.

El proceso incluye:

• Lectura de grupos de datos como DG1 (datos de la MRZ), DG2 (imagen facial) y otros, cuando el acceso está permitido.

• Validación de que los datos no han sido alterados, mediante firmas digitales y el objeto de seguridad del documento.

• Aplicación de Autenticación Pasiva, Autenticación Activa y Autenticación de Chip para confirmar la integridad y autenticidad del chip.

• Uso de BAC, PACE y Autenticación de Terminal, cuando sea necesario, para controlar el acceso a grupos de datos sensibles.

La verificación en el servidor es especialmente importante cuando la lectura del documento comienza en un dispositivo móvil. El dispositivo móvil lee los datos mediante NFC y los envía al backend, que luego verifica la integridad y autenticidad en un entorno que no está bajo el control del usuario.

Document Reader SDK no incluye certificados de firma de países, listas de revocación ni listas maestras. Las organizaciones los obtienen de ICAO PKD y de autoridades nacionales, y los configuran en sus propios almacenes de confianza.

De forma predeterminada, Document Reader Web Service no almacena los datos procesados. Recibe las imágenes, realiza las comprobaciones y devuelve un resultado. La retención de imágenes y resultados depende de usted.

El resultado se devuelve en formato JSON e incluye:

• Un estado general del documento.

• Códigos de estado para cada comprobación o campo, como “válido”, “fallido” o “no verificado”.

• Valores extraídos de la MRZ, campos visuales, códigos de barras y datos RFID cuando estén disponibles.

• Comprobaciones cruzadas, por ejemplo “la fecha de nacimiento en la MRZ y en la zona visual coincide” o “el código de país del código de barras no coincide con la MRZ”.

Esta estructura le brinda visibilidad completa sobre por qué un documento fue aprobado o rechazado. Usted puede registrar el JSON como parte de su trazabilidad de auditoría, aplicar reglas de decisión y alimentar el resultado en modelos adicionales de fraude.

El rendimiento del OCR siempre depende de la calidad de la imagen, el estado del documento y las fuentes utilizadas. Las pruebas internas de Regula en conjuntos de datos controlados con referencia conocida muestran una precisión a nivel de carácter de hasta el 99% en buenas condiciones. La precisión en entornos reales será diferente, ya que las imágenes en producción pueden incluir texto dañado, suciedad o errores de impresión previos.

Document Reader SDK admite OCR para más de 130 idiomas, incluidos alfabetos latinos y no latinos, incluidos los utilizados en pasaportes y tarjetas de identidad en todo el mundo. La lista exacta está disponible en la documentación.

Si necesita soporte para un idioma que actualmente no está cubierto, Regula puede, en muchos casos, añadirlo, siempre que usted proporcione suficientes muestras representativas de documentos de identidad para entrenamiento y validación. Ese trabajo se incluye posteriormente en una futura versión del SDK.

La calidad de la imagen es uno de los principales factores para un reconocimiento exitoso, por lo que se dedica un importante esfuerzo de ingeniería a la captura y al preprocesamiento.

Document Reader SDK puede:

• Detectar los bordes del documento y corregir la inclinación y la rotación.

• Aplicar preprocesamiento para reducir los reflejos, especialmente en hologramas, dentro de los límites del hardware.

• Imponer umbrales mínimos de calidad, de modo que las imágenes muy borrosas o de baja resolución se rechacen antes del procesamiento.

Para imágenes capturadas en UV o IR, opciones especializadas como Smart UV y compensación IR ayudan a reducir los efectos de la luz ambiental y la sobreexposición.

En escenarios típicos, Document Reader SDK puede procesar un documento por ambas caras en aproximadamente un segundo. Cuando se añaden determinadas comprobaciones de autenticidad, como el análisis de hologramas, el tiempo total de procesamiento puede aumentar algunos segundos.

Desde el punto de vista del usuario, el tiempo total incluye:

• La captura y carga de imágenes.

• El reconocimiento y la verificación en el servidor o dispositivo.

• La aplicación de reglas de negocio y la visualización de la decisión en su interfaz.

Varios factores influyen en el procesamiento:

• El escenario de procesamiento seleccionado.

• El número y tipo de campos que usted extrae.

• Los recursos de hardware en los servidores que ejecutan el Web Service.

• El uso de verificación de chip.

Usted puede escalar el rendimiento horizontalmente ejecutando más instancias del Web Service y distribuyendo el tráfico entre ellas.

La integración y el monitoreo se basan en herramientas estándar.

Para la integración:

• Implementación como Web Service: Usted ejecuta Document Reader SDK como un Web Service en su entorno. Las aplicaciones cliente envían imágenes y parámetros a través de HTTP(S), y el servicio devuelve resultados estructurados en formato JSON.

• Uso como SDK nativo: Document Reader SDK también puede integrarse como una biblioteca nativa en aplicaciones móviles, de escritorio o de servidor. En este caso, el procesamiento del documento se realiza directamente dentro de la aplicación o en el propio dispositivo, sin enviar imágenes por HTTP a un servicio separado.

Para el monitoreo:

• El Web Service expone un endpoint de métricas en un formato compatible con Prometheus. Usted puede recopilar esas métricas y visualizarlas en herramientas como Grafana.

• El registro configurable almacena errores, advertencias e información de depuración, lo que ayuda en la resolución de problemas y auditorías.

Las métricas típicas incluyen número de solicitudes, tasas de error, latencia y estado de los workers. Combinadas con el monitoreo de su propia aplicación, le ofrecen una visión clara de cómo se comporta la verificación de documentos bajo diferentes cargas y configuraciones.

Sí. Regula mantiene su propia base de datos de documentos y puede ampliarla.

Durante muchos años, Regula ha colaborado directamente con diversas organizaciones internacionales como Interpol, Europol, ICAO, la ONU y otras. Intercambiamos conocimientos forenses e información sobre documentos de identidad, lo que nos ayuda a obtener una sólida experiencia y no dejar margen para la falsificación. Además, nuestro I+D interno, fabricación propia y expertos especializados provenientes de laboratorios forenses facilitan el tiempo de salida al mercado más rápido.

Existen dos formas de añadir nuevos documentos, según el caso:

1. Si una nueva identificación incluye un nuevo elemento de seguridad, nuestros expertos forenses lo examinan cuidadosamente con la ayuda de nuestros dispositivos profesionales. Luego creamos y probamos nuevos algoritmos de verificación y lanzamos una actualización para todos los documentos con esa característica de seguridad en nuestra base de datos, que se utiliza en las soluciones de Regula.

2. Si una nueva identificación incluye características de seguridad ya conocidas y compatibles, simplemente añadimos una nueva plantilla y la nueva información a nuestra base de datos.

En cualquier caso, normalmente se necesitan de tres a cinco días para añadir un nuevo documento a nuestra base de datos.

Regula Face SDK ofrece varias capacidades biométricas:

• Detección de rostro.

• Comprobación de los rostros uno a uno con una puntuación de similitud.

• Búsqueda uno a muchos en una base de datos de descriptores faciales almacenados.

• Prueba de vida para distinguir a una persona real de un intento de suplantación.

• Evaluación de calidad y atributos, incluida la estimación de edad y la detección de oclusiones.

Estas capacidades se utilizan para verificaciones KYC, apertura de cuentas, inicio de sesión sin contraseña, prevención de fraude, control de acceso y casos de uso similares.

Muchos clientes vinculan Face SDK con Document Reader SDK para que el rostro en vivo pueda compararse con la foto del titular impresa en el documento o almacenada en el chip RFID.

Face SDK utiliza prueba de vida. En lugar de basarse en una única heurística, la decisión de prueba de vida es generada por modelos de aprendizaje automático entrenados con grandes conjuntos de ejemplos.

En términos prácticos, los modelos se entrenan mostrándoles numerosas muestras de:

• Capturas en vivo de cámaras reales bajo diferentes condiciones.

• Ataques no vivos, como fotos impresas, imágenes mostradas en pantallas, reproducciones de video, máscaras y flujos de video inyectados o alterados.

Los modelos aprenden a separar estas clases basándose en patrones que difieren de manera consistente entre una captura genuina y una entrada suplantada. Debido a que las señales exactas son aprendidas por los modelos y no reglas codificadas manualmente, no es correcto describir la prueba de vida como “verificar X micro-movimiento” en todos los casos.

Lo que importa para quien evalúa la solución es que la decisión se basa en entrenamiento con ejemplos reales de ataques y que el conjunto de entrenamiento se amplía a medida que aparecen nuevas técnicas de ataque.

Face SDK admite dos estilos de prueba de vida:

• Prueba de vida pasiva, en la que el usuario simplemente mira a la cámara mientras el sistema toma una decisión.

• Prueba de vida activa, en la que el usuario sigue indicaciones en pantalla, por ejemplo moviéndose o girando de formas específicas.

Face SDK está diseñado para detectar varias categorías de ataques:

• Fotos impresas mostradas frente a la cámara.

• Fotos mostradas en teléfonos, tabletas o monitores.

• Videos reproducidos del usuario.

• Inyección de video mediante cámaras virtuales o flujos de video alterados.

• Máscaras de silicona y cabezas impresas en 3D.

• Deepfakes generados por IA.

Los modelos de prueba de vida y PAD están entrenados con estos tipos de amenazas. En el lado del servidor, comprobaciones adicionales pueden ayudar a señalar patrones asociados con la inyección, como determinadas características de los datos entrantes.

Las comprobaciones están totalmente automatizadas.

El SDK no depende de analistas humanos cuando el nivel de confianza es bajo, y Regula no ofrece un servicio de revisión manual que opere detrás del SDK. Todas las decisiones en las respuestas de la API son generadas por algoritmos.

Si su proceso requiere revisión humana, usted puede construir esa capa dentro de sus propios sistemas. Por ejemplo, puede decidir enviar a un equipo especializado los casos con puntuaciones de similitud dentro de un rango específico, mientras que los casos claramente aprobados y claramente rechazados avanzan automáticamente.

En cuanto a la velocidad, las mediciones internas indican que una sesión típica de prueba de vida activa (con indicaciones en pantalla) en el dispositivo del usuario toma aproximadamente de cuatro a diez segundos, dependiendo de la experiencia del usuario con el flujo.

El procesamiento en el servidor y la respuesta de la API suelen añadir menos de un segundo cuando Face SDK se ejecuta con aceleración GPU. En implementaciones solo con CPU, el procesamiento del lado del servidor sigue siendo rápido, pero puede tardar más bajo cargas más altas, según el hardware y la concurrencia.

Face SDK devuelve un resultado estructurado en formato JSON.

Para una comparación uno a uno, el resultado generalmente contiene:

• Una puntuación de similitud que refleja qué tan similares son los dos rostros.

• Decisiones binarias opcionales derivadas de umbrales que usted configura en su propia lógica.

Para una búsqueda uno a muchos, el resultado enumera candidatos de su base de datos, cada uno con un identificador y una puntuación de similitud. Los candidatos se ordenan por similitud, por lo que la mejor coincidencia aparece primero.

Usted decide cómo interpretar las puntuaciones. Por ejemplo, puede definir un umbral alto para aceptar una coincidencia, un umbral más bajo que active una revisión manual, y considerar todo lo que esté por debajo como una no coincidencia clara.

El rendimiento de la comprobación de los rostros depende en gran medida de dos factores: la calidad de las imágenes y el umbral de similitud que usted elija. El mismo algoritmo puede comportarse de manera muy diferente si cambian la iluminación, la óptica de la cámara, la distancia de captura, el desenfoque por movimiento, la pose y las oclusiones.

El rendimiento se mide de varias formas:

• Pruebas externas a través de NIST FRVT en verificación uno a uno, que evalúa algoritmos de múltiples proveedores.

• Benchmarks internos en conjuntos de datos propietarios que incluyen diferentes edades, condiciones de iluminación, poses y oclusiones.

Es importante señalar que es difícil seleccionar un umbral universal que funcione igual de bien en todos los entornos. Incluso si mantiene el umbral constante, los cambios en el tipo de cámara, el comportamiento del usuario, la iluminación o la interfaz de captura pueden modificar la distribución de las puntuaciones de similitud. En otras palabras, “0,8” puede ser un buen umbral en una configuración y un umbral inadecuado en otra, incluso cuando el modelo subyacente es el mismo.

Por ello, Regula suele proporcionar un umbral inicial recomendado basado en la experiencia del producto y en condiciones de captura típicas, pero recomienda firmemente que los equipos midan el rendimiento utilizando datos propios similares a los de producción y luego ajusten el umbral según su política de riesgo:

• Si usted optimiza para reducir las falsas aceptaciones, eleva el umbral.

• Si optimiza para reducir los falsos rechazos y lograr un flujo de usuario más fluido, lo reduce, a menudo combinado con comprobaciones adicionales en casos límite.

Face SDK separa la evaluación de atributos y calidad de la comprobación de identidad. Junto con la salida biométrica (puntuaciones de coincidencia y decisión de prueba de vida), proporciona señales de calidad para entender si las condiciones de captura son demasiado desfavorables para una comprobación sólida.

Puede detectar:

• Máscaras y coberturas faciales intensas. Si las regiones faciales clave están ocultas, la prueba de vida y la comprobación de los rostros se vuelven menos fiables. En flujos de mayor nivel de garantía, el comportamiento esperado es fallar o solicitar una nueva captura, ya que aceptar rostros con fuertes oclusiones incrementa el riesgo de suplantación.

• Gafas y reflejos. Las gafas normalmente no bloquean la comprobación de los rostros, pero el deslumbramiento y los reflejos pueden reducir la calidad de la imagen y disminuir las puntuaciones de similitud. En prueba de vida, los reflejos intensos también pueden interferir con el flujo de captura.

• Barbas y cambios de apariencia. Cambios normales como el crecimiento de la barba, un corte de cabello o el maquillaje pueden reducir las puntuaciones de similitud, pero normalmente no impiden la comprobación de los rostros. La respuesta adecuada suele ser el ajuste del umbral junto con una ruta alternativa clara para casos límite.

• Otras oclusiones y accesorios. Gafas de sol, coberturas de cabeza, auriculares y elementos similares pueden detectarse como oclusiones o problemas de calidad. Según su política, puede tratarlos como advertencias, requerir un nuevo intento o dirigir la sesión a un flujo más estricto.

Los productos de Regula están diseñados para comportarse de manera consistente entre diferentes grupos demográficos.

Esto se aborda principalmente a nivel de datos y entrenamiento:

• Conjuntos de datos de entrenamiento y prueba diversos: Los modelos se entrenan y evalúan con conjuntos de datos que incluyen una amplia variedad de edades, tonos de piel y otras variaciones del mundo real.

• Refinamiento continuo de los conjuntos de datos: En estrecha colaboración con los clientes, Regula analiza cómo se comporta el SDK en implementaciones reales. Cuando se identifican condiciones específicas del mundo real o casos límite, se utilizan para ampliar y reequilibrar los conjuntos de datos de entrenamiento y prueba.

De este modo, los datos representativos y la retroalimentación continua del uso en producción ayudan a Regula a reducir el sesgo y mantener un rendimiento estable entre diferentes grupos de usuarios.

Sí. Face SDK admite la creación de descriptores faciales y su uso para búsquedas uno a muchos (1:N), lo que lo hace adecuado para la detección de duplicados y comprobaciones tipo lista de vigilancia.

Usos típicos:

• Detección de duplicados: Cuando un nuevo usuario se registra, usted crea un descriptor a partir de su selfie y ejecuta una búsqueda uno a muchos en sus registros existentes. Si el mismo rostro aparece bajo identidades diferentes, el resultado de la búsqueda lo señalará con puntuaciones de similitud altas.

• Listas de vigilancia: Usted puede mantener grupos separados de descriptores, por ejemplo “casos de fraude” o “clientes VIP”, y limitar las búsquedas a un grupo específico cuando sea necesario.

• Reautenticación: Para usuarios recurrentes, puede comparar una nueva selfie con el descriptor almacenado en el momento del registro, en lugar de someterlos nuevamente a verificaciones completas de documentos.

La gobernanza de datos depende del modelo de implementación que usted elija. Si utiliza el almacenamiento 1:N integrado de Face SDK, la configuración de almacenamiento y retenciónse gestiona dentro de esa implementación. Si mantiene las plantillas en sus propios sistemas, el almacenamiento, la retención y el control de acceso se gestionan en su infraestructura.

En ambos casos, todo se ejecuta dentro de su entorno, dentro de su perímetro de seguridad, y usted decide cómo se integra en su política.

Face SDK puede integrarse en flujos móviles y web en dos partes: un componente del lado del cliente que captura la entrada (selfie o fotogramas de video) y un componente del lado del servidor que realiza la prueba de vida y la comprobación de los rostros.

La integración del cliente es el primer paso.

En móvil, la integración se realiza añadiendo la biblioteca correspondiente de Face SDK a su aplicación (para iOS, Android y stacks multiplataforma comunes como Flutter, .NET MAUI y React Native). El SDK gestiona los flujos de captura, la guía al usuario y el empaquetado de los datos para su procesamiento.

En web, el punto de partida habitual son los Regula Web Components, que proporcionan una interfaz de captura lista para usar y gestionan el flujo de interacción para la captura de rostro y la prueba de vida. Si lo prefiere, también puede desarrollar su propia interfaz y llamar directamente a los endpoints del backend desde JavaScript, pero los Web Components son la opción estándar cuando desea una implementación más rápida y controlada.

Luego usted decide dónde se realiza el procesamiento.

El procesamiento biométrico de Face SDK se ejecuta en un backend que usted controla, implementado como un Web Service. Usted lo instala en Windows o Linux, lo ejecuta en contenedores o directamente en hosts, y lo escala con Kubernetes cuando sea necesario.

Una vez que su backend está implementado, el lado cliente necesita conocer con qué backend debe comunicarse. En la práctica, eso significa configurar el SDK o los Web Components con la URL del endpoint del Web Service utilizado en su entorno. El cliente envía entonces las imágenes o fotogramas capturados a ese endpoint, recibe los resultados JSON y su aplicación aplica su lógica de decisión.

En todos los casos, el procesamiento permanece dentro de su infraestructura. Las imágenes y fotogramas de video de los usuarios se envían a sus servidores, y los clientes reciben únicamente resultados estructurados.

A medida que el fraude de identidad continúa desafiando a las empresas con tácticas nuevas y en evolución, los SDKs de Regula ofrecen las respuestas, protegiendo a los usuarios frente a una amplia gama de amenazas, suplantaciones y manipulaciones.

En el ámbito documental, Regula Document Reader SDK combina una de las bases de datos de plantillas más grandes del mundo con comprobaciones profundas de MRZ, códigos de barras, zonas visuales, características de seguridad y chips RFID. Puede detectar inconsistencias entre campos de datos, identificar manipulaciones en las zonas de foto del titular y confirmar que el chip de un documento electrónico no ha sido alterado ni clonado.

En cuanto a la base de datos, consta de más de 16.000 plantillas detalladas de documentos de 254 países y territorios. Más específicamente, contiene todos los tipos comunes de identificación (pasaportes, ePassaportes, licencias de conducir, etc.), así como identificaciones poco frecuentes (licencias marítimas, tarjetas de refugiado, credenciales de votante y muchas más). Actualizamos nuestra base de datos semanalmente, añadiendo alrededor de 500 documentos cada trimestre.

En el ámbito biométrico, Regula Face SDK incorpora prueba de vida, detección de ataques de presentación y comprobación de los rostros de alta precisión dentro de su propia infraestructura. Está diseñado para afrontar la realidad del fraude moderno: fotos impresas, reproducciones en pantalla, máscaras, medios sintéticos e intentos de inyección que utilizan cámaras virtuales.

¿Tiene más preguntas? Póngase en contacto con el equipo de Regula ahora — estamos aquí para ayudarle.