Operar con un único proveedor de biometría le quita a la operación dos activos que solo existen con competencia activa: datos de comparación en producción y una posición real de negociación en la renovación del contrato. Sin ambos, la evaluación de desempeño y las decisiones de precio dependen de lo que el proveedor actual decida reportar.

Este artículo explica cuándo la dependencia de un proveedor único se convierte en riesgo operacional, cómo estructurar la operación en paralelo, qué medir, cuál es el esfuerzo de ingeniería esperado y cómo migrar la base de rostros al nuevo proveedor.

¿Cuándo la dependencia de un proveedor único se convierte en riesgo operacional?

La dependencia se convierte en riesgo cuando no hay datos independientes para cuestionar lo que reporta el proveedor. El riesgo rara vez aparece como un incidente grave. Aparece en ajustes silenciosos: una versión del SDK (kit de desarrollo del proveedor) que cambia el comportamiento del liveness (detección de vivacidad biométrica) sin aviso con suficiente antelación; un aumento de precio en la renovación porque no hay ninguna alternativa probada en marcha; una degradación de la API que reduce la tasa de éxito durante horas con un SLA (acuerdo de nivel de servicio) vago.

Cada uno de estos eventos es manejable por separado. El problema es que, sin datos de referencia de un segundo proveedor procesando el mismo tráfico, ninguno puede evaluarse con precisión.

Los gestores de fraude y los equipos de producto enfrentan versiones distintas de este problema. Para fraude: ante una nueva técnica de ataque, ¿cómo evaluar si la protección del proveedor actual es suficiente o si otro proveedor responde mejor? Para producto: si la tasa de rechazo sube dos puntos porcentuales después de una actualización, ¿cómo saber si la causa fue el proveedor o un cambio en el flujo?

Sin operación en paralelo, ambas preguntas dependen de datos proporcionados por el propio proveedor que está siendo evaluado.

¿Qué genera un segundo proveedor activo que la redundancia pura no genera?

La distinción importa para quien aprueba el presupuesto. La redundancia pasiva —un proveedor inactivo esperando a que el primero falle— es difícil de justificar porque no genera retorno mientras el sistema funciona. Un segundo proveedor activo, incluso recibiendo una fracción del tráfico, genera lo que la redundancia no genera: datos de comparación en condiciones reales de producción.

Con tráfico en paralelo es posible responder preguntas que hoy dependen de benchmarks de laboratorio o del boca a boca del mercado: ¿cuál es la diferencia en la tasa de rechazo entre los dos proveedores en mi flujo, con mi público? ¿Cuál responde mejor a los cambios de iluminación o de dispositivo? ¿Cuál tiene un tiempo de respuesta más estable en los últimos 60 días?

Ese dato cambia la conversación sobre la renovación del contrato. Y cambia la conversación interna sobre dónde conviene invertir en la optimización del flujo.

¿Cómo estructurar la división del tráfico?

Existen tres modelos. La elección depende del objetivo inmediato.

01

División porcentual fija: una parte del tráfico (10 %, 20 %, 30 %) va al segundo proveedor; el resto permanece en el primero. Es el modelo más simple de implementar y el más comparable, porque ambos grupos pasan por la misma jornada. Para que la comparación sea válida, la división debe aleatorizarse a nivel de cada solicitud: sin aleatorización, las diferencias de perfil entre los grupos contaminan el dato.

02

Segmentación por producto o flujo: el segundo proveedor atiende una línea de producto, una vertical o un flujo específico. Un banco que usa biometría en el onboarding y en la autenticación posterior al registro puede probar al segundo proveedor solo en la autenticación. Esto reduce el impacto en el onboarding y genera datos en un flujo de alto volumen con un comportamiento distinto al del registro.

03

Fallback secuencial: el primer proveedor es el principal; el segundo solo recibe la solicitud si el primero devuelve un error o no responde dentro del tiempo límite configurado. Este modelo resuelve el riesgo de disponibilidad, pero no genera datos de comparación de calidad: las solicitudes que llegan al segundo proveedor son, por definición, las que el primero no logró procesar. El perfil de la transacción es distinto y la comparación queda comprometida.

Para quien busca datos de comparación, la división porcentual fija con aleatorización a nivel de solicitud es el punto de partida más limpio. Para quien quiere resolver la disponibilidad antes que cualquier otra cosa, el fallback es más rápido de implementar.

¿Qué medir durante la operación en paralelo?

El objetivo del período con dos proveedores es generar datos suficientes para tomar una decisión antes de que se renueve el contrato del proveedor actual. Las métricas que importan en este contexto:

Tasa de éxito en el primer intento (first attempt success rate): cuántas transacciones llegan a un resultado concluyente sin necesidad de reintento. Este número es más revelador que la tasa de aprobación final, que puede quedar enmascarada por reintentos que el usuario abandona antes de completar.

Tasa de rechazo: cuántas transacciones no llegan a un resultado concluyente. En producción, esto debe medirse por segmento, porque el promedio agrupa comportamientos muy diferentes. Una tasa de rechazo del 4 % puede esconder un 12 % entre usuarios mayores de 60 años con dispositivos de gama baja.

Tiempo de respuesta en P90 y P99: el P50 es engañoso. Lo que importa es lo que ocurre en las transacciones más lentas, donde el abandono es más probable. Proveedores con un P50 parecido pueden tener un P99 muy distinto según la infraestructura en los horarios pico.

Disponibilidad y tiempo de recuperación ante incidentes: no se trata solo del uptime promedio, sino de cuánto tiempo tardó el proveedor en comunicar y resolver cada degradación. Ese historial debe estar disponible en el SLA o en una página pública de estado antes de firmar cualquier contrato.

Costo por transacción concluyente: el precio cobrado por solicitud no refleja el costo real de la operación. Las solicitudes inconclusas consumen presupuesto sin generar resultado; el esfuerzo de soporte durante la estabilización rara vez entra en el cálculo inicial.

Con tres meses de operación en paralelo y volumen suficiente por segmento, es posible comparar a los dos proveedores en cada uno de estos ejes con datos reales de producción. Como referencia concreta: el SDK de Fortface registra un 97,9 % de éxito en el primer intento, un tiempo promedio de captura de 4,1 s y un procesamiento de backend de hasta 800 ms.

¿Cuál es el esfuerzo de integración con un segundo proveedor?

La mayoría de los equipos de ingeniería subestima el esfuerzo de agregar un segundo proveedor porque lo tratan como un simple cambio de SDK. No lo es.

El SDK es la parte más rápida. Lo que consume más tiempo está a su alrededor: la lógica de enrutamiento que decide qué proveedor recibe cada solicitud, el sistema de recolección de métricas que registra el resultado de cada transacción por proveedor, los paneles que hacen comparables los datos entre ambos, y los flujos de reintento y fallback que deben funcionar incluso cuando uno de los proveedores tiene latencia elevada.

Para un equipo con experiencia en integración de APIs biométricas, la estimación realista es de cuatro a ocho semanas de ingeniería para poner al segundo proveedor en tráfico paralelo con la instrumentación adecuada. Un SDK bien documentado y con soporte activo durante la integración reduce ese número. La ausencia de una capa de abstracción en el código existente lo aumenta.

El costo continuo después de la integración depende principalmente de cómo el proveedor entrega las actualizaciones del modelo. Los proveedores que actualizan vía configuración o API, sin forzar una nueva versión de la app, reducen el esfuerzo de mantenimiento a lo largo del tiempo. Este punto debe estar en el contrato, no solo en la documentación técnica.

¿Qué hacer con la base de rostros?

La base de rostros no es un obstáculo para adoptar un segundo proveedor. Dos caminos técnicos resuelven la migración sin necesidad de reenrolar manualmente a los usuarios, y casi todos los clientes tienen las imágenes originales almacenadas.

El primer camino es la migración en lote único: las fotos originales almacenadas se usan para generar un nuevo hash biométrico compatible con el nuevo proveedor, en segundo plano, sin impacto en la jornada del usuario.

El segundo es el enrolamiento progresivo vía API: con cada nueva transacción o inicio de sesión, el sistema registra automáticamente al usuario en el nuevo proveedor. La base migra de forma dinámica, sin acción adicional del usuario y sin necesidad de procesamiento por lotes.

La elección entre ambos depende del volumen de usuarios activos y del plazo disponible para la migración. En los dos casos, la portabilidad de las imágenes originales entre proveedores requiere revisión contractual y aprobación del DPO (Data Protection Officer, responsable de protección de datos): la migración técnica es resoluble, pero la base legal debe estar definida antes de cualquier movimiento.

¿Qué preguntar a un segundo proveedor durante la evaluación?

Evaluar a un segundo proveedor es distinto a evaluar al primero. Ya se cuenta con una referencia real en producción, por lo que la comparación deja de ser abstracta.

Sobre el desempeño en producción: ¿cuál es la tasa de rechazo medida en condiciones reales, con qué volumen y con qué perfil de usuario? ¿Qué parte de ese dato está bajo NDA y qué parte es pública?

Sobre la migración de la base de rostros: ¿el proveedor admite migración en lote para generar un nuevo hash biométrico a partir de las imágenes originales? ¿También ofrece enrolamiento progresivo vía API? ¿Cuál es el proceso y cuáles son los requisitos técnicos?

Sobre la actualización del modelo: cuando se actualiza el modelo de liveness, ¿con cuánta antelación se notifica al cliente? ¿La actualización se aplica de forma automática o el cliente controla el momento?

Sobre el historial de incidentes: ¿cuál es el historial de los últimos 12 meses? ¿Cuál fue el tiempo promedio entre la degradación y la comunicación, y entre la comunicación y la resolución? ¿Ese dato está disponible en una página pública de estado o depende de contactar al soporte?

Sobre el soporte en la integración: ¿existe un equipo de ingeniería dedicado para apoyar la fase de integración? ¿Con qué SLA y hasta qué etapa?

Los proveedores que no pueden responder sobre el historial de incidentes de los últimos 12 meses con datos precisos están diciendo algo sobre cómo operan. Ese silencio también es un dato.

Fortface como segundo proveedor

Fortface publica sus datos de producción de forma abierta: 97,9 % de éxito en el primer intento, tiempo promedio de captura de 4,1 s, procesamiento de backend de hasta 800 ms y una puntuación SUS de 95,5 —clasificación A+ en usabilidad—. El liveness es sin fricción, sin desafíos de movimiento, certificado en iBeta Levels 1 y 2 e ISO/IEC 30107-3, con protección contra ataques de presentación e inyección. El SDK está disponible para Android, iOS, Web y Link Seguro, en producción en más de 180 empresas.

Para los equipos que están evaluando un segundo proveedor: solicitar una conversación técnica con el equipo de Fortface.

Para profundizar

  • Soluciones Fortface — cómo Fortface aborda cada etapa del recorrido de identidad

Preguntas frecuentes

¿Cuándo no tiene sentido contar con un segundo proveedor?
Cuando el volumen de transacciones es lo bastante bajo como para que el costo de integración y mantenimiento supere el valor generado por los datos de comparación. Por debajo de cierto volumen mensual —que varía según el producto y el flujo—, el período de operación en paralelo no genera una muestra lo suficientemente grande para una comparación estadísticamente válida. En ese caso, instrumentar mejor al proveedor actual para recolectar métricas detalladas por segmento es más eficiente que agregar un segundo proveedor.
¿Dos proveedores cuestan el doble?
El costo total no se duplica, porque el tráfico se divide, no se repite. Cada proveedor procesa su fracción del volumen, no el volumen completo. El precio por transacción puede variar entre ambos, lo cual entra en el cálculo del costo por transacción concluyente. El costo fijo adicional está en la integración inicial, en el mantenimiento de dos SDK y en la capa de enrutamiento. Ese costo debe compararse con el valor que genera: palanca de negociación en la renovación del contrato del proveedor actual, datos para la decisión de migración y reducción del riesgo de disponibilidad.
¿El segundo proveedor necesita las mismas certificaciones que el actual?
Depende del requisito regulatorio de la operación. La IN ITI 36/2026 exige liveness con detección de imágenes y videos manipulados para la Autoridad de Registro Electrónica (AR Eletrônica). Si la operación está regulada, ambos proveedores deben cumplir el mismo requisito para que el tráfico en paralelo sea válido en ese flujo. Para flujos sin una exigencia regulatoria específica, las certificaciones se convierten en un criterio de evaluación, no en un requisito de elegibilidad.
¿Cuánto tiempo se necesita para tener datos confiables de la operación en paralelo?
Depende del volumen. Con al menos 10.000 transacciones mensuales por proveedor, tres meses son suficientes para una comparación razonablemente confiable de la tasa de rechazo y la tasa de éxito. Con un volumen menor, el período debe extenderse o el alcance de la comparación debe limitarse a segmentos con un comportamiento más homogéneo.
¿Qué sucede con los datos biométricos durante la migración?
La migración técnica es resoluble: las fotos originales almacenadas se usan para generar un nuevo hash biométrico compatible con el nuevo proveedor. Lo que debe definirse antes de cualquier movimiento es la base legal. Los datos biométricos son datos personales sensibles bajo la LGPD (la ley general de protección de datos de Brasil). Portar las imágenes requiere una cláusula contractual específica con ambos proveedores y la aprobación del DPO. El orden correcto es: primero lo legal, después lo técnico.