El orden de trabajo que seguimos cuando un sensor debe verificar identidad sin depender de la nube: qué se decide antes de tocar el hardware, qué se prueba en banco y qué queda documentado para quien hereda el sistema.
En la página de implementación conviene mirar el efecto práctico de mover la inferencia al borde: menos tráfico, decisiones en milisegundos y plantillas que no abandonan el equipo. Estos son los puntos que suelen inclinar la balanza durante un despliegue real.
El terminal compara la captura contra la plantilla almacenada en su propia memoria. Si el enlace con el servidor central cae durante un turno completo, el control de acceso sigue resolviendo. La sincronización de altas, bajas y revocaciones queda para cuando vuelve la conexión.
Lo que se guarda es una representación irreversible, no la imagen ni el vector de rasgos en claro. Al no enviarse a un servicio externo, se reduce la superficie de exposición y se simplifica el cumplimiento de las exigencias de protección de datos biométricos.
Un micromodelo cuantizado a int8 sobre un NPU modesto resuelve la comparación en decenas de milisegundos. Esa cifra importa en tornos, molinetes y puertas de paso rápido, donde una espera de dos segundos cambia por completo la experiencia de quien entra.
Una flota de decenas de lectores que solo intercambia eventos y estados consume una fracción del tráfico que exigiría enviar cada captura. En sedes con enlace satelital o móvil, esa diferencia se nota tanto en la factura como en la estabilidad del servicio.
Los pesos del modelo se distribuyen como un paquete firmado y se aplican en la siguiente ventana de mantenimiento. Un sensor que ya está instalado puede mejorar su tasa de verificación con iluminación difícil sin que nadie suba a desmontarlo.
Cuando la caché local se llena o una plantilla queda obsoleta, el terminal aplica una política de decisión explícita en lugar de fallar en silencio. Ese comportamiento se define antes del despliegue y se documenta para el equipo que atiende incidencias.
Para ver cómo encajan estas piezas en un plan por etapas, revisa el flujo de trabajo o consulta el soporte durante la puesta en marcha.
El orden de trabajo no es negociable: primero se fija el modelo, después la plantilla, después la política de decisión local. Cada etapa deja un artefacto verificable antes de pasar a la siguiente.
Se mide RAM disponible, TOPS del NPU, resolución real del sensor y temperatura de operación sostenida. Sin estos números cualquier decisión de arquitectura es una suposición.
Entregable: ficha técnica del terminal firmada por el integrador.
Poda de capas, cuantización int8 y destilado sobre el modelo base. Se comparan al menos dos variantes y se elige la que sostiene la tasa de verificación con iluminación variable.
Entregable: binario del modelo con métricas de latencia por fotograma.
La captura se transforma en un vector protegido mediante función unidireccional. El embedding en claro nunca se escribe en disco ni se transmite fuera del dispositivo.
Entregable: esquema de plantilla cancelable y política de revocación.
Caché cifrada de plantillas, decisión local y sincronización diferida por lotes. Se define cuántas horas puede operar el terminal sin enlace antes de degradar el servicio.
Entregable: matriz de compromisos entre frescura de datos y disponibilidad.
Despliegue en un subconjunto de accesos durante varias semanas. Al recuperar conexión se reconcilian estados y se evitan duplicados o plantillas revocadas en uso.
Entregable: informe de incidencias y ajustes sobre el modelo en producción.
Los plazos dependen del número de terminales y de la calidad del enlace disponible. La etapa de piloto suele ser la más larga porque es donde aparecen los casos que ningún laboratorio reproduce.