← Sebastián Allende

SAC Next: una plataforma de alarma comunitaria

Los vecinos levantan una alerta de seguridad, incendio o emergencia médica desde una app, un control remoto por radio, una llamada o un SMS. La alerta hace sonar las sirenas de las centrales cercanas y aparece en vivo en la consola de la central de operaciones. La construí como consultoría para un programa municipal. Está en desarrollo: solo ha corrido contra centrales simuladas y no está desplegada.

  1. Equipos
    • Centrales con sirena en la calle
    • Controles remotos por radio
    • Llamadas y SMS
  2. Servidor
    • Broker MQTT
    • API en Fastify
    • PostgreSQL con PostGIS
  3. Personas
    • Consola en vivo de la central
    • App móvil
    • Avisos push y por SMS

De un botón a una sirena

  1. Control, app, llamada o SMS
  2. Se revisa y se registra
  3. Suenan las sirenas cercanas
  4. Se ve en vivo
  • Cada mensaje se revisa. Las centrales hablan con el servidor por MQTT, y cada mensaje se valida contra un esquema antes de llegar a la base. Varias pulsaciones del mismo control quedan como un solo incidente.
  • Las centrales más cercanas, por distancia. Una consulta en PostGIS elige las centrales cerca de la alerta, y ellas reciben la orden de sirena.
  • Las órdenes van firmadas y vencen. Cada orden lleva una firma, un valor de un solo uso y un vencimiento, así que una orden repetida o falsificada se rechaza. Los controles usan código rotativo.
  • El silencio se informa, no se esconde. Una orden que ninguna central confirma queda vencida, se anota en el incidente y abre un ticket de mantención, para que el operador sepa qué sirena no sonó.

Un asistente que conoce sus límites

  • Las emergencias van primero. La detección de emergencias corre antes que todo, y una emergencia recibe una respuesta fija con botones para llamar. Nunca llega al modelo de lenguaje.
  • Preguntas conocidas, respuestas conocidas. Las preguntas comunes se responden desde una lista fija de temas. Solo el resto va al modelo, que tiene la instrucción de responder únicamente con la base de conocimiento del programa.
  • Los datos personales no salen. Correos, RUN y teléfonos se quitan antes de que el texto salga del servidor, y si el modelo falla el asistente vuelve a sus propias respuestas.

Un despliegue por cliente y datos personales protegidos

  • Cada cliente tiene su propio stack. Base, broker, API y consola corren como un proyecto de Docker Compose en una red interna, y solo el proxy queda expuesto. El broker rechaza conexiones anónimas, y cada central solo puede leer sus propias órdenes.
  • Los campos personales van cifrados. Un índice con clave permite buscar por valor exacto sin guardarlo en claro.
  • La auditoría va encadenada. Cada registro lleva el hash del anterior, así que se puede detectar uno editado o borrado.
  • Los respaldos se cifran mientras se escriben, así que un volcado en claro nunca toca el disco, y un script prueba restaurar uno.
  • El código no conoce a su cliente. Una prueba falla si algún archivo nombra al cliente o trae sus coordenadas, así que el mismo código puede servir a otra municipalidad.

Pruebas

14 archivos de Vitest con 136 pruebas unitarias, y tres suites con script: una de punta a punta por la API, MQTT y centrales simuladas, y dos que manejan la app web y la consola en Chrome. La suite de punta a punta importa 1.100 hogares y 1.100 controles y revisa que importar dos veces no cree duplicados. Unos scripts de shell prueban restaurar un respaldo y actualizar con vuelta atrás. Todavía no hay integración continua ni prueba de carga, y nada ha corrido en hardware real ni con usuarios. El código es del proyecto de consultoría y es privado, y con gusto lo recorro en una entrevista.