EdgeBiometría

Who We Are

Diez años de decisiones que llevaron la verificación al chip

Desde una primera prueba con lectores externos hasta los modelos cuantizados que hoy corren en la NPU de un teléfono de gama media. Lo que sigue no es una lista de hitos decorativos: son los momentos en los que cambiamos de enfoque, de hardware o de criterio de validación, y lo que cada uno dejó pendiente.

  1. Primeras pruebas con lectores externos

    Empezamos validando huella con periféricos conectados por USB a tablets de escritorio en mesas de operaciones. El reconocimiento funcionaba, pero dependía de un cable, de un driver y de que nadie moviera el dispositivo. Ahí quedó claro que el cuello de botella no era el algoritmo sino el trayecto del dato hacia el servidor.

  2. El giro hacia la inferencia local

    Reescribimos el flujo para que la comparación de plantillas ocurriera en el propio dispositivo. La latencia bajó de forma medible en redes móviles congestionadas, aunque el modelo inicial consumía demasiada memoria y competía con la app de gráficos. Ese año aprendimos a presupuestar cómputo antes de presupuestar funciones.

  3. Cuantización y modelos que caben

    Adoptamos cuantización agresiva y una jerarquía de modelos según el tipo de operación: consulta de saldo, confirmación de orden o autorización de transferencia. No todas necesitan el mismo nivel de exigencia biométrica. Separar esos umbrales fue lo que permitió sostener la precisión sin sacrificar la respuesta táctil de la interfaz.

  4. Cumplimiento sin salir del dispositivo

    Trabajamos con equipos de cumplimiento para documentar consentimiento y evidencia de verificación cuando el dato biométrico no viaja al servidor. El reto no fue técnico sino de trazabilidad: cómo auditar después algo que ocurrió en local. La respuesta fue anclar la evidencia en el dispositivo y compartir solo lo estrictamente necesario.

  5. Lo que sigue abierto

    Hoy el foco está en el presupuesto térmico de los SoC recientes y en la convivencia con otras tareas en segundo plano. También en calibrar umbrales de confianza por hardware concreto, porque un mismo modelo no rinde igual en todos los chips. Esa calibración fina es, ahora mismo, la parte menos resuelta del trabajo.

Si quieres el detalle técnico de alguna de estas etapas, en el análisis sobre NPU y validación local están las cifras de latencia y consumo que fuimos midiendo en cada salto.

De un cuaderno de pruebas a un método de trabajo

La historia de EdgeBiometría no empieza con una ronda de inversión ni con un manifiesto. Empieza con una libreta donde anotábamos cuánto tardaba un teléfono de gama media en confirmar una orden cuando la verificación biométrica dependía de un servidor lejano. Esas primeras mediciones marcaron el rumbo del proyecto y explican por qué hoy trabajamos como trabajamos.

  1. Primeras pruebas

    Medir antes de prometer

    Antes de hablar de inferencia local, pasamos meses midiendo latencias reales en operaciones de compra y venta: conexiones móviles inestables, dispositivos con poca memoria libre y modelos que no cabían sin degradar la experiencia. De ahí salió una regla que sigue vigente: ningún modelo se publica sin haber corrido antes en el hardware donde va a vivir. Esa disciplina nos obligó a descartar arquitecturas que en papel parecían razonables y a reescribir el pipeline de verificación desde cero.

  2. Consolidación

    Un equipo que mezcla perfiles que no suelen coincidir

    Con el tiempo se sumaron especialistas en visión por computador, en cumplimiento normativo y en experiencia de uso para operadores de mercado. Natalia Torres Flores coordina la parte de modelos ligeros; Emilio Rojas Rodriguez se ocupa de la integración con los flujos de confirmación de órdenes; Maria Rivera Martinez trabaja el lado de trazabilidad y consentimiento. Esa mezcla poco habitual es la que nos permite discutir un umbral de confianza sin perder de vista qué exige un auditor.

  3. Decisiones

    Qué dejamos fuera y por qué

    Hubo tentaciones claras: modelos más grandes, verificación en la nube como respaldo permanente, integraciones con plataformas que prometían volumen. Rechazamos varias. La verificación biométrica local pierde sentido si el dato acaba saliendo del dispositivo por comodidad. También descartamos enfoques que dependían de hardware de gama alta, porque el objetivo siempre fue que un trader con un teléfono de tres años pudiera operar sin esperas perceptibles. Cada una de esas renuncias dejó huella en la arquitectura actual.

  4. Resultados

    Lo que hoy sostiene el proyecto

    Hoy tenemos un conjunto de modelos calibrados por familia de dispositivo, un esquema de evidencia que se ancla en el propio terminal y un flujo de consentimiento que no depende de servidores intermedios. Sergio Hernandez Herrera y Alberto Herrera Rojas mantienen la relación con equipos de cumplimiento que revisan periódicamente cómo se registra cada verificación. No es un resultado cerrado: cada nueva generación de NPU obliga a recalibrar, y eso forma parte del trabajo cotidiano.

Por qué los equipos de trading confían en la verificación local

Llevamos tres años midiendo lo mismo en cada despliegue: cuánto tarda una firma biométrica en confirmarse y qué ocurre cuando la red falla. Esa obsesión por el detalle operativo es lo que separa un esquema on-device que funciona del que solo suena bien en una presentación.

La inferencia no sale del dispositivo

El modelo corre en la NPU del teléfono o la tableta. No hay viaje a un centro de datos, no hay cola de espera y no hay dependencia de la cobertura del operador en el momento exacto de confirmar una orden. Cuando la red cae, la validación sigue respondiendo.

Modelos ajustados al hardware real

No reutilizamos arquitecturas de servidor recortadas. Partimos del presupuesto térmico y de memoria del SoC concreto, cuantizamos en consecuencia y calibramos el umbral de confianza para ese chip. Un modelo que no cabe no se fuerza: se rediseña.

Evidencia auditable sin exponer el dato

El cumplimiento no se resuelve ignorando al regulador. Registramos la verificación en el propio dispositivo y compartimos solo la prueba necesaria con el servidor. El dato biométrico no viaja; la trazabilidad sí.

Comparación honesta con la alternativa remota

Hay operaciones donde el servidor sigue teniendo sentido: consultas de bajo riesgo, dispositivos sin NPU utilizable, flujos heredados. Lo decimos en cada evaluación. La elección no es ideológica, es de latencia, coste de red y exposición de datos.

Documentación antes que promesa

Publicamos cifras de consumo, límites de tamaño de modelo y jerarquías por tipo de operación. Si un número no lo hemos medido en un dispositivo real, no lo escribimos. Preferimos un dato incómodo a una estimación cómoda.

Continuidad entre iteraciones

Cada generación de SoC cambia el reparto entre CPU, GPU y NPU. Mantenemos un historial de decisiones para que un modelo calibrado hoy siga siendo defendible cuando el hardware se renueve. La memoria del proyecto importa tanto como el código.

Si quieres ver cómo aplicamos este criterio en casos concretos, revisa los recursos publicados o escríbenos directamente desde contacto.

Un equipo pequeño que decidió mirar dentro del teléfono

EdgeBiometría nació de una incomodidad concreta: cada vez que alguien confirma una orden desde el móvil, sus datos biométricos viajan a un servidor que no controla. Empezamos a preguntarnos qué pasaría si esa verificación ocurriera en la NPU del propio dispositivo, sin salir de él. Llevamos desde entonces documentando ese desplazamiento, con sus límites y sus consecuencias prácticas.

01

De dónde venimos

El proyecto arrancó como un cuaderno de notas técnicas sobre latencia en operaciones de trading móvil. Al principio eran comparativas entre inferencia remota y local, medidas con cronómetro en mano sobre dispositivos de gama media. Con el tiempo esas notas se convirtieron en un archivo abierto sobre biometría financiera on-device: qué modelos caben, qué consume cada inferencia y cuándo conviene seguir delegando en el servidor.

02

Para quién escribimos

Nos leen ingenieros de producto que diseñan flujos de confirmación de órdenes, equipos de cumplimiento que necesitan entender qué evidencia queda en el dispositivo, y responsables técnicos que evalúan si su parque de terminales soporta un modelo cuantizado. No escribimos para un público genérico: cada texto asume que quien lo lee tiene que tomar una decisión de arquitectura o justificar una ante un auditor.

03

Cómo trabajamos

Preferimos las cifras incómodas a las promesas redondas. Cuando publicamos un análisis, indicamos en qué SoC se midió, con qué versión del runtime y bajo qué condiciones térmicas. Si un modelo no cabe en un dispositivo de gama media sin degradar la experiencia, lo decimos. Esa honestidad sobre los límites es, en la práctica, la única forma de que el contenido siga siendo útil dentro de dos generaciones de hardware.

04

Qué nos interesa discutir

Nos interesa el punto donde la verificación biométrica deja de ser un trámite y se convierte en parte del flujo de decisión del trader. También el momento en que el cumplimiento regulatorio y la privacidad del usuario empujan en direcciones distintas, y hay que encontrar un equilibrio documentable. Sobre esos temas volvemos una y otra vez, porque no tienen una respuesta cerrada.

Si trabajas en identificación financiera y quieres contrastar criterios, escríbenos a info@ubranium.com. Respondemos con la misma franqueza con la que publicamos: sin promesas de rendimiento que no hayamos medido antes.

Seguimos la pista a la verificación que ocurre dentro del teléfono

Quienes formamos EdgeBiometría llevamos años entre modelos de reconocimiento y terminales de bolsillo. Este espacio recoge lo que aprendemos al probar hardware real: qué modelos caben, dónde falla la latencia y qué exige cumplimiento cuando el dato biométrico no abandona el dispositivo.

Si trabajas en un bróker, en un equipo de riesgo o simplemente operas desde el móvil, escríbenos. Contamos qué estamos midiendo esta semana y respondemos con detalle técnico, sin promesas de folleto.

Configuracion de cookies Usamos cookies para mantener el sitio estable, recordar opciones basicas y entender que paginas resultan utiles. Puedes aceptar, rechazar o revisar la configuracion antes de continuar.