Una empresa de seguridad en Bogotá nos llamó después de seis meses operando con un proveedor "líder regional" que prometía modo offline. La queja: en la sede industrial de Mosquera el sistema perdía entre el 15% y el 20% de los escaneos por turno. El cliente final estaba a punto de cancelar el contrato. La auditoría reveló que el proveedor no tenía modo offline real — tenía un cache de visualización. Cuando el vigilante escaneaba sin señal, la app mostraba feedback al usuario, pero el evento no llegaba a quedar persistido en una cola. Cuando la app se cerraba o el vigilante reiniciaba el dispositivo antes de volver a cobertura, el evento se perdía silenciosamente.
Este post explica la diferencia entre offline parcial (lo que la mayoría de plataformas LATAM ofrecen) y offline 100% end-to-end (lo que necesitas si tu operación incluye polígonos, sótanos, edificios antiguos o subestaciones rurales). También explica cómo validar al proveedor antes de firmar contrato.
Qué significa "offline" para diferentes plataformas
La especificación importa. Cuando un proveedor dice "soporta modo offline", tienes que pedir las cuatro respuestas:
1. ¿Dónde se persisten los eventos cuando no hay señal? Cache en memoria (RAM): se pierde al cerrar app. SQLite local: persiste a través de reinicios. La diferencia no es trivial.
2. ¿Hasta cuántos eventos / días aguanta la cola sin perder datos? Plataformas serias documentan límites explícitos (típicamente 7 días o 5,000 eventos). Plataformas no serias dicen "ilimitado" porque nunca lo probaron.
3. ¿Cómo se reanuda la sincronización? Manual (el vigilante toca un botón "sincronizar") o automática en background. Manual es problemático: si el vigilante olvida tocar el botón antes de cerrar el turno, los eventos se quedan en el dispositivo y no llegan al sistema central.
4. ¿Hay deduplicación si el mismo evento se sincroniza dos veces? Race conditions con red intermitente generan duplicados. Plataformas serias tienen IDs idempotentes; las no serias generan eventos duplicados que ensucian las auditorías.
Lo que pasa en LATAM con cobertura inestable
Estos son datos consolidados de 8 deployments en México, Colombia, Argentina y Perú durante 2024-2025. La cifra clave: en operaciones industriales y logísticas LATAM, entre el 70% y el 95% del turno puede transcurrir en zonas sin cobertura confiable. Un sistema que pierde el 15% de eventos en esas zonas no es operativo.
Sótanos de edificios corporativos en CDMX y Bogotá: estructuras de concreto pre-1990 con cero penetración de señal celular. Operadores típicamente cubren 45% del turno offline.
Polígonos industriales nocturnos (Toluca, Querétaro, Lima Sur): torres celulares apagadas o congestionadas en horario nocturno. Tasas reales de offline 70-80% del turno.
Almacenes logísticos interiores: estructuras metálicas que actúan como Faraday parcial. Offline típico 60-75%.
Subestaciones eléctricas rurales: áreas con cobertura diseñada para voz pero insuficiente para datos. Offline >90%.
En todos estos escenarios, el modo offline parcial pierde datos. El modo offline 100% end-to-end no.
Anatomía del modo offline 100% end-to-end
Cuatro componentes que tienen que estar todos:
1. Persistencia local en SQLite con encriptación AES-256. Cada evento (escaneo, foto, incidente, deadman ping) se inserta inmediatamente en una tabla local antes de cualquier intento de envío al servidor. El usuario nunca ve un mensaje de error de red.
2. Cola FIFO con reintentos exponenciales. Cuando hay señal intermitente, el cliente intenta enviar, espera 2s, 4s, 8s, 16s antes del siguiente intento. La cola se procesa hasta vaciarse o hasta que la red caiga otra vez.
3. IDs idempotentes generados client-side. Cada evento lleva un UUID generado en el dispositivo antes de cualquier intento de envío. El servidor descarta duplicados por UUID. Si el cliente envía un evento, no recibe ACK por timeout, y reenvía, el servidor lo procesa una sola vez.
4. Sincronización en background sin intervención del usuario. El service worker (web) o el WorkManager (Android) ejecutan sincronización cuando hay señal disponible, aunque la app esté cerrada. El vigilante nunca tiene que recordar "sincronizar".
Si una de las cuatro componentes falla, el sistema no es offline 100%. Es offline parcial con marketing.
Cómo validar al proveedor antes de firmar
Cinco pruebas que hacemos en demo con cualquier proveedor que asegure modo offline:
1. Escanear con avión activado durante 30 minutos. Hacer 50 escaneos seguidos. Cerrar la app. Reabrir. Activar wifi. Contar cuántos eventos llegaron al backend.
2. Apagar el dispositivo a media operación. Hacer 10 escaneos sin red, apagar el dispositivo. Encender 10 minutos después con red. Verificar que los 10 eventos quedaron en backend.
3. Forzar duplicados. Hacer un escaneo sin red. Cerrar la app antes de que sincronice. Reabrir y forzar nueva sincronización manual. Backend debe mostrar 1 evento, no 2.
4. Test de cola larga. Operar el vigilante 8 horas sin red, escaneando cada 15 minutos. Volver a cobertura. Cronometrar cuánto tarda en sincronizar 32 eventos. Si tarda más de 5 minutos, hay un problema.
5. Pedir documentación de la arquitectura offline. Plataformas serias tienen un documento técnico que describe cola, persistencia y deduplicación. Si el proveedor no puede entregarlo en 48 horas, no tiene la arquitectura.
Errores que vemos repetidamente en LATAM
"La app dice escaneado, pero no llegó al backend". Cache de visualización sin persistencia. La app respondió OK al usuario pero el evento nunca se grabó.
"Sincroniza solo si el vigilante abre la app". Sin background sync, los eventos se quedan parados. Aún peor: si el vigilante elimina la app por falta de espacio, todos los eventos pendientes se pierden.
"Reportes de turno duplicados". Reintentos sin IDs idempotentes generan duplicados. La auditoría se vuelve imposible.
"App lenta cuando hay muchos eventos pendientes". Sin cola FIFO con throttling, la app intenta enviar todos los eventos a la vez al recuperar señal, satura la red y bloquea al usuario.
Lo que ofrece rondinesdigitales.com
La plataforma implementa los cuatro componentes de offline 100%: SQLite encriptado AES-256, cola con reintentos exponenciales hasta 7 días, UUIDs idempotentes generados client-side, sincronización en background vía Android WorkManager / iOS BackgroundTasks. Cero pérdida documentada en 8 deployments con tasas de offline >70% del turno. Plan gratis hasta 10 controladores con modo offline completo (no degradado).
Para profundizar
- /blog/checkpoints-doble-factor-nfc-gps-rondines — la otra capa que no funciona sin offline real.
- /blog/lectores-fisicos-vs-celular — el hardware tiene que aguantar el offline también.
- /blog/ia-vs-geofencing-rondas — IA y geofencing necesitan datos completos para funcionar.