Por qué llevamos la biometría al borde y no a la nube

Nuestro trabajo parte de una idea sencilla: un rostro o una huella no deberían viajar por la red para ser verificados. Diseñamos micromodelos de inferencia que caben en el propio terminal, con memoria limitada y sin enlace permanente. Esta página cuenta de dónde viene esa decisión, quién la sostiene y qué principios no estamos dispuestos a negociar cuando un sensor tiene que decidir en milisegundos.

De un prototipo de laboratorio a terminales desplegados en planta

La historia del proyecto se entiende mejor por etapas que por fechas. Cada salto vino de un problema concreto que apareció al llevar la inferencia biométrica fuera del servidor central.

  1. Primera etapa

    Verificación facial en un solo SoC

    El punto de partida fue un terminal de control de acceso con 512 MB de RAM y un NPU modesto. La pregunta inicial no era de precisión sino de viabilidad: qué red cabía realmente en ese presupuesto de memoria sin degradar la tasa de verificación en condiciones de luz variable. La respuesta llegó tras podar capas redundantes y aplicar cuantización int8 sobre los pesos.

  2. Segunda etapa

    Plantillas que no salen del dispositivo

    Con la inferencia resuelta, el siguiente cuello de botella fue el almacenamiento. Guardar el embedding en claro era un riesgo legal y técnico. Se adoptó una proyección unidireccional que genera plantillas cancelables: si un terminal se pierde, la plantilla se revoca sin afectar al resto del parque. El coste de cómputo adicional en el MCU resultó aceptable.

  3. Tercera etapa

    Operación con red intermitente

    El despliegue en una planta con 40 terminales y enlace satelital inestable obligó a rediseñar el pipeline. Se añadió caché cifrada de plantillas, política de decisión local y sincronización diferida por lotes. La reconciliación al recuperar la conexión fue la parte más delicada: había que evitar duplicados y conflictos de estado sin bloquear la operación.

  4. Cuarta etapa

    Micromodelos por debajo de 2 MB

    La comparación entre un modelo de 6 MB y otro de 1.8 MB mostró algo contraintuitivo: en capturas con movimiento, el más pequeño ganaba en latencia por fotograma sin perder precisión útil. Ese hallazgo reorientó la línea de trabajo hacia el destilado agresivo y la medición de consumo energético en el propio dispositivo, no en banco de pruebas.

Cada etapa dejó documentación técnica abierta: decisiones de poda, parámetros de cuantización, esquemas de protección de plantillas y compromisos entre frescura de datos y tamaño de caché. Esa documentación es la base sobre la que se sigue trabajando hoy.

Quiénes sostienen EdgeBio y por qué trabajamos así

Somos un equipo pequeño de ingeniería embebida y visión por computador que lleva años metiendo modelos de IA dentro de hardware que no puede permitirse una conexión estable. No vendemos plataformas en la nube disfrazadas de local: escribimos kernels, medimos consumo por fotograma y depuramos sensores en plantas donde el enlace se cae cada tarde. Nuestra identidad se construye sobre esa restricción, no a pesar de ella.

Trabajamos con integradores de control de acceso, fabricantes de terminales y equipos de cumplimiento que necesitan demostrar que un dato biométrico nunca salió del dispositivo. Si tu proyecto depende de que la inferencia ocurra en el borde, aquí vas a encontrar cómo lo hacemos y con qué límites.

01

Privacidad como decisión de arquitectura

La plantilla biométrica se genera, se protege y se compara dentro del propio terminal. El vector de rasgos no viaja a un servidor central porque no lo necesitamos: si el dato no sale, no hay nada que filtrar ni que auditar fuera del dispositivo.

02

Micromodelos, no modelos recortados

Diseñamos redes desde el presupuesto de cómputo disponible, no adaptamos un modelo grande hasta que quepa. Poda, cuantización int8 y destilado se deciden en función del NPU real, la memoria disponible y la latencia aceptable en verificación en movimiento.

03

Operación sin red garantizada

Asumimos que el enlace se cae. Caché cifrada de plantillas, política de decisión local y sincronización diferida por lotes forman parte del diseño base, no de un plan de contingencia que se activa cuando el cliente llama preocupado.

04

Medimos en el dispositivo, no en el portátil

Cada decisión de compresión se valida con métricas tomadas sobre el propio SoC: latencia por fotograma, vatios consumidos, tasa de verificación con iluminación variable. Un resultado bonito en un benchmark de escritorio no nos dice nada útil.

05

Documentamos los compromisos

Preferimos explicar qué se pierde al comprimir un modelo antes que prometer precisión perfecta. Los equipos de cumplimiento y los integradores necesitan entender los límites reales para tomar decisiones defendibles ante una auditoría.

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.