Cuando diseñamos el sistema biométrico para nuestros comedores institucionales clientes, la primera pregunta fue: ¿webapp o desktop? La respuesta correcta depende del contexto real de despliegue, no de las preferencias tecnológicas del desarrollador.

El contexto real

Un comedor institucional regional no tiene fibra óptica garantizada. La conectividad es compartida con el resto del establecimiento. En hora pico de almuerzo (12:00-13:00) hay cientos de personas pasando por el control de acceso en menos de una hora. Cada segundo de latencia importa.

Una webapp con autenticación biométrica cloud-first significa: captura de huella, API call, respuesta, mostrar resultado. Con latencia de red de 200-500ms en condiciones normales, o 3-5 segundos cuando la conectividad celular institucional se satura, eso es inaceptable. Con WinForms offline-first: captura, match local contra base SQLite, resultado en menos de 800ms garantizados, sin importar el estado de la red.

Por qué C# WinForms sobre Electron o Tauri

Electron añade aproximadamente 150MB de runtime. Tauri es mejor, pero sigue requiriendo WebView. C# WinForms .NET 4.8 usa un runtime que el 99% de los equipos Windows empresariales ya tienen instalado. El instalador de nuestra aplicación pesa 8.5MB incluyendo el SDK de DigitalPersona.

El argumento técnico principal: el SDK de DigitalPersona U.are.U (lector modelo 4500) tiene bindings nativos para C#. Usarlo desde JavaScript requiere un proceso puente con IPC o COM interop, lo cual añade latencia y puntos de fallo. En C# la captura de huella, la extracción de features y la verificación son llamadas directas al SDK, sin capas adicionales.

Base de datos local: SQLite con cifrado

Los templates biométricos se almacenan en SQLite local. Los datos biométricos son datos sensibles bajo la Ley 1581/2012 de Colombia y la Directiva 2016/680 como referencia internacional — no pueden estar en texto plano en disco. Implementamos cifrado AES-256 sobre cada template antes de guardarlo en SQLite (hallazgo crítico C-02 de la auditoría de seguridad de abril 2026, ya resuelto).

El match biométrico ocurre localmente: se cargan todos los templates activos del tenant, se extrae el feature set de la huella capturada y se compara contra cada template almacenado usando el motor de verificación del SDK de DigitalPersona. Con bases de pocos cientos de empleados registrados por sede, el tiempo de match es menor a 400ms.

Heartbeat telemetría hacia el servidor

Cada instalación reporta estado cada 5 minutos hacia nuestra API FastAPI en el VPS. El payload incluye: license_key, versión de la aplicación, timestamp, registros del día, tamaño de la base de datos y versión del SO.

El handler en el cliente falla silenciosamente si no hay red — esto es intencional. Un error de red no debe interrumpir las operaciones biométricas offline. Pero desde el lado del servidor, si un heartbeat deja de llegar, el sistema de monitoreo nos notifica por Telegram antes de que el cliente llame.

Cada sede activa genera entre 150 y 200+ heartbeats por semana hacia el servidor. Esos números son evidencia de SLA cumplido ante el cliente.

Sistema de licencias RSA

Las licencias son archivos JSON con dos partes: un payload (tenant_id, machine_id, expires_at, features habilitadas) y una firma digital RSA-2048. La aplicación verifica la firma con la clave pública hardcoded antes de iniciar. Si la firma no es válida, la aplicación no arranca.

El machine_id se calcula combinando CPU ID y board serial mediante SHA-256, truncado a 16 caracteres. Esto vincula la licencia a un equipo específico. Si el cliente intenta instalar la misma licencia en un segundo PC, el machine_id no coincide y la licencia es inválida.

Update automático sin visita presencial

El sistema verifica en cada inicio si hay una versión nueva disponible en nuestra API. Si hay nueva versión, descarga el instalador en background y notifica al usuario que hay una actualización disponible. El usuario puede instalar con un clic, sin que nuestro equipo tenga que viajar físicamente a sitio.

La versión en producción actualmente es v1.7.1.0. La v2.0.0.0 ya está disponible en el servidor. La v1.8.0.0 (con PIN SHA-256, TLS 1.2 forzado y telemetría mejorada) está pendiente de compilación en Windows con Visual Studio 2022.

Lo que aprendimos en producción

El error más costoso: no cifrar los templates desde el inicio. La auditoría de seguridad lo marcó como crítico (C-02). La corrección requirió migrar todas las bases de datos en las sedes, lo cual hicimos de forma remota aprovechando el sistema de update automático.

El segundo aprendizaje: el sistema de heartbeat es más valioso que cualquier dashboard. Antes de implementarlo, no teníamos visibilidad de si los equipos estaban funcionando sin necesidad de que el cliente llamara. Hoy, un silencio de 15 minutos en los heartbeats activa una alerta automática.