Un equipo que trabaja con terminales reales: sensores de acceso, cámaras de proximidad y controladores con recursos ajustados. Nos interesa cómo se comporta un micromodelo cuando la red se cae, cuando el rostro llega en movimiento o cuando el NPU se queda sin margen térmico. Esa experiencia práctica es la que define lo que publicamos y lo que descartamos.
Un proyecto que nació de una pregunta incómoda: si el rostro de una persona es un dato, ¿por qué tiene que viajar hasta un servidor lejano para confirmar quién es?
Diseñamos cada pipeline asumiendo que la red puede fallar, caer o simplemente no existir. La verificación se resuelve en el propio dispositivo con micromodelos que caben en memoria reducida, y el enlace con el servidor central queda como tarea de sincronización, no como requisito para operar. Si el enlace se corta durante horas, el control de acceso sigue funcionando.
Lo que se almacena es una representación irreversible, no la captura original. Trabajamos con esquemas de protección que permiten revocar una plantilla sin volver a enrolar a la persona y sin exponer el vector de rasgos. Es una decisión de arquitectura antes que una función: si el dato no viaja, no hay nada que interceptar en tránsito.
Un micromodelo de pocos megabytes no es una versión recortada de uno grande: es un diseño distinto. Poda, cuantización y destilado se eligen según el hardware real del terminal, la iluminación del sitio y el tipo de captura. Preferimos decir qué precisión se pierde y en qué condiciones antes que prometer una exactitud que no se sostiene en campo.
El cumplimiento no se resuelve con una cláusula: se resuelve con lo que el sistema es capaz de hacer. Si el terminal no necesita enviar datos personales para autenticar, el riesgo legal y operativo baja sin depender de la buena voluntad de quien administra el servidor. Ese es el punto de partida de cada despliegue que acompañamos.
Lo que buscamos en cada instalación es concreto: latencia baja en la verificación, continuidad operativa cuando la conexión falla, y un perímetro de datos personales que se reduce al propio dispositivo. No es una promesa de marca, es una consecuencia de dónde se ejecuta la inferencia.
Historia del proyecto
Cada etapa de EdgeBio nació de una limitación concreta: ancho de banda escaso, sensores baratos, normativa de datos personales que no admite enviar rostros fuera del edificio. Lo que sigue no es una cronología de marketing, sino las decisiones técnicas que fuimos tomando y lo que quedó funcionando en campo.
Montamos un lector de acceso con una placa de desarrollo y una cámara de 2 MP. El objetivo era simple: verificar un rostro en menos de 400 ms sin llamar a ningún servidor. La primera versión guardaba el embedding en claro y consumía 3 W en reposo. Aprendimos rápido que la privacidad no se resuelve después, se diseña desde el primer commit.
Reescribimos el pipeline de inferencia con poda estructurada y cuantización int8. El modelo pasó de 6 MB a 1.8 MB y la tasa de verificación en condiciones de contraluz mejoró, no empeoró. Ese resultado nos convenció de que el tamaño no era el enemigo: lo era el entrenamiento descuidado.
Adoptamos plantillas cancelables con proyección unidireccional. El sensor ya no almacena el vector de rasgos, sino un hash protegido que se puede revocar si un terminal se pierde. Fue el cambio más costoso en cómputo y el que más consultas legales nos ahorró.
Una planta con 40 terminales y enlace satelital inestable nos obligó a diseñar caché cifrada local y sincronización diferida por lotes. Los equipos siguen verificando durante cortes de horas y reconcilian estado al volver la conexión, sin duplicar registros ni aceptar plantillas revocadas.
Llevamos parte del pipeline a microcontroladores de bajo consumo para lectores de huella. Extracción de minucias, comparación y decisión caben en un MCU sin sistema operativo. El consumo bajó a milivatios y abrió la puerta a terminales alimentados por batería en accesos remotos.
Latencia por fotograma, consumo real en el dispositivo y tasa de falsos rechazos con iluminación variable. Publicamos los resultados en el blog técnico y los usamos para decidir qué capa podar en la siguiente iteración. La hoja de ruta la marcan los datos de campo, no las presentaciones.