Cronología del programa
Antes de tocar una línea de código revisamos qué teléfonos y tabletas usan realmente los operadores. No sirve el listado teórico del fabricante: importan la versión de firmware, la NPU disponible, la memoria libre en el momento de operar y el comportamiento térmico bajo carga sostenida. De ahí sale un inventario por perfiles y una lista de modelos que quedan fuera del alcance inicial.
Con el inventario cerrado, se elige qué modelo de huella o rostro cabe en cada perfil. La cuantización a enteros de 8 bits es el punto de partida habitual, pero el umbral de confianza se calibra dispositivo a dispositivo: un mismo modelo da tasas de acierto distintas según el SoC. Documentamos esa calibración porque condiciona todo lo que viene después.
La verificación local se inserta entre la intención de operar y el envío al mercado. Aquí aparecen las decisiones incómodas: qué ocurre si la inferencia tarda más de lo previsto, cómo se degrada el flujo cuando el dispositivo está caliente y qué operaciones exigen confirmación adicional. Nada de esto se resuelve en una demo; se resuelve con sesiones de prueba sobre cuentas reales y volúmenes controlados.
El dato biométrico no sale del dispositivo, pero la obligación de demostrar que la verificación ocurrió sí permanece. Diseñamos el registro de evidencia: qué se ancla localmente, qué se comparte de forma selectiva con el servidor y durante cuánto tiempo se conserva. Los equipos de cumplimiento suelen pedir aquí más de lo que la arquitectura necesita, y conviene negociarlo antes del despliegue, no después.
La puesta en producción se hace por grupos reducidos, empezando por los perfiles de hardware más homogéneos. Cada oleada deja métricas de latencia, tasa de rechazo y consumo de batería que alimentan la siguiente. El soporte durante las primeras semanas es intensivo: la mayoría de incidencias no son fallos del modelo, sino expectativas mal calibradas sobre lo que el dispositivo puede hacer.
En un flujo de trading móvil, cada paso intermedio entre la intención y la orden confirmada se paga en tiempo y en fricción. Estas son las ventajas concretas que aparecen cuando la validación biométrica y parte del análisis financiero se ejecutan en la NPU del teléfono o la tableta de operaciones, en lugar de depender de un servidor remoto.
La inferencia local elimina el viaje de ida y vuelta al centro de datos. En la práctica, la orden pasa de un tiempo de confirmación que el usuario nota a uno que no llega a interrumpir la lectura del gráfico. Importa sobre todo en momentos de volatilidad, cuando la ventana entre ver y actuar se estrecha.
El vector facial o de huella se compara contra el patrón almacenado en el propio chip seguro. No se transmite, no se replica en un servidor y no queda expuesto si la red se compromete. Para el equipo de cumplimiento, esto simplifica la conversación sobre retención y minimización de datos.
En trenes, plantas industriales o zonas con cobertura intermitente, la verificación remota falla o se degrada. Con el modelo en local, la autorización de una transferencia o el desbloqueo de la cartera siguen funcionando aunque la conexión se caiga a mitad del proceso. La sincronización con el servidor se resuelve después, no bloquea la operación.
Cada verificación que se resuelve en el dispositivo deja de consumir ciclos en el backend. En volúmenes altos de usuarios activos, eso se traduce en menos instancias dedicadas a inferencia y en una factura de infraestructura más predecible, sin picos asociados a horas punta de mercado.
Un modelo ligero, cuantizado y calibrado para la NPU concreta rinde mejor que uno grande mal adaptado. El resultado es una latencia estable entre dispositivos de gama media y alta, sin que el usuario de un equipo más modesto quede fuera del flujo de validación reforzada.
El dispositivo puede registrar un sello de verificación, la versión del modelo y el resultado de la comparación, y compartir solo ese resumen con el servidor. Se mantiene la trazabilidad exigida por los procesos de identificación reforzada sin mover la muestra biométrica original.
Estas ventajas no aparecen de forma automática: dependen de decisiones de arquitectura, del presupuesto térmico del equipo y de cómo se define el umbral de confianza. En la sección de recursos se detallan los criterios que usamos para evaluar cada caso antes de proponer un despliegue on-device.