Inferencia sin nube: qué ocurre cuando se cae la conexión

La planta tiene cuarenta terminales repartidos entre tres naves y un acceso de carga. Cada vez que se reinicia el enlace satelital, el servidor central desaparece entre veinte minutos y cuatro horas. Hasta hace un año, eso significaba colas en la puerta y personal con listas impresas. Ahora no. El terminal sigue verificando, sigue decidiendo y sigue registrando. Lo único que cambia es cuándo se entera el servidor.

El artículo no trata sobre protocolos de red ni sobre teoría de tolerancia a fallos. Trata sobre lo que hay que construir dentro del dispositivo para que la operación no dependa de un enlace que se cae. Eso implica tres piezas concretas: una caché local de plantillas, una política de decisión que funcione sin árbitro remoto y un mecanismo de sincronización diferida que no genere duplicados ni estados contradictorios.

Caché de plantillas cifrada en el propio terminal

El terminal necesita reconocer a las personas que pasan por su puerta sin consultar al servidor. Eso obliga a mantener una copia local de las plantillas biométricas de quienes tienen permiso de acceso a esa zona. En la planta, cada terminal guarda entre 900 y 1.400 plantillas, según la nave. Son plantillas ya transformadas, no embeddings crudos, y viajan cifradas con una clave derivada del identificador del dispositivo.

El tamaño importa. Con plantillas de 512 bytes, mil registros ocupan medio megabyte. Suena poco hasta que se suma el índice de búsqueda, el registro de eventos pendientes y el espacio reservado para la siguiente sincronización. En un módulo con 4 GB de almacenamiento hay margen, pero en los terminales antiguos con 512 MB el presupuesto se agota rápido. La decisión que tomamos fue limitar la caché por zona y no por planta completa: cada terminal solo necesita a quienes pueden cruzar su puerta.

Decisión local y sus compromisos

Cuando el enlace está caído, el terminal decide solo. Acepta o rechaza según la plantilla que tiene en caché y el umbral configurado. El problema no es técnico, es de política. Una plantilla revocada hace tres días sigue en la caché local y el terminal no lo sabe. Si esa persona se presenta, el sistema la deja pasar.

Hay tres formas de convivir con eso. La primera es aceptar el riesgo y registrar el evento para revisión posterior. La segunda es degradar el umbral de similitud cuando el enlace lleva mucho tiempo caído, exigiendo una coincidencia más estricta. La tercera es marcar ciertas plantillas como sensibles y exigir verificación secundaria, como un PIN, cuando el terminal no puede confirmar su vigencia con el servidor. En la planta se combinaron las tres: umbral más estricto tras seis horas sin conexión, verificación secundaria para perfiles con acceso a zonas restringidas y registro completo de cada decisión tomada en modo aislado.

Frescura de datos frente a disponibilidad

La caché tiene fecha. Cada plantilla lleva una marca de la última vez que el servidor confirmó su estado. Cuando el terminal recupera el enlace, compara esa marca con la versión remota. Si la plantilla fue revocada durante el corte, se elimina. Si fue actualizada, se reemplaza. Si no hay cambios, se conserva.

El compromiso real está entre mantener la caché fresca y mantenerla disponible. Una caché que se vacía cada pocas horas obliga a sincronizaciones frecuentes y deja al terminal ciego si el enlace no vuelve. Una caché que nunca caduca acumula plantillas obsoletas. En la práctica, un vencimiento de setenta y dos horas con renovación por lotes funciona bien en plantas con cortes previsibles. En enlaces satelitales intermitentes, conviene ampliar ese margen y compensar con umbrales más estrictos.

Sincronización diferida por lotes

Durante el corte, el terminal acumula eventos: accesos concedidos, accesos denegados, intentos fallidos, plantillas que no pudo verificar. Cada evento se firma localmente y se guarda en una cola ordenada por marca de tiempo. Cuando vuelve el enlace, la cola se envía por lotes, no evento a evento. Eso reduce el consumo de ancho de banda y evita que una reconexión breve se sature con miles de peticiones.

La cola tiene un límite. Si el corte dura más de lo previsto, el terminal empieza a descartar eventos antiguos o a comprimirlos. En la planta, el límite está en 50.000 eventos por terminal, lo que cubre aproximadamente dos semanas de operación normal. Pasado ese punto, se prioriza conservar los accesos concedidos y se descartan los intentos fallidos repetidos del mismo identificador.

Reconciliación al recuperar la conexión

El momento delicado no es el corte, es la vuelta. El servidor recibe un lote de eventos que ocurrieron en el pasado y tiene que integrarlos sin duplicar registros ni sobrescribir estados más recientes. La regla que adoptamos fue simple: el servidor nunca rechaza un evento local, pero tampoco lo aplica a ciegas. Cada evento lleva un identificador único generado en el terminal y una marca de tiempo monotónica. Si el servidor detecta un conflicto con un evento posterior, conserva ambos y marca el registro para revisión.

Las plantillas siguen un camino distinto. Al reconectar, el terminal descarga la lista de revocaciones ocurridas durante el corte y la aplica antes de aceptar cualquier nueva verificación. Si una plantilla fue revocada y el terminal ya había concedido accesos con ella, esos eventos se marcan como pendientes de auditoría. No se borran, no se ocultan. Se dejan visibles para que alguien decida qué hacer con ellos.

Lo que no resuelve el diseño local

Un pipeline tolerante a cortes no elimina el problema, lo desplaza. El terminal sigue operando, pero la política de acceso queda en manos de una caché que puede estar desactualizada. La decisión de cuánta obsolescencia es aceptable no es técnica, es operativa. En una planta industrial con turnos definidos, seis horas de desfase pueden ser aceptables. En un edificio con visitantes y personal rotativo, no lo son.

Lo que sí cambia es la naturaleza del fallo. Sin diseño local, un corte de red detiene la operación. Con diseño local, un corte de red genera un conjunto de decisiones que habrá que revisar después. La diferencia entre esos dos escenarios es la diferencia entre una planta que para y una planta que sigue funcionando con una deuda de auditoría pendiente.