Sentinela: caso técnico de un monitor de las normas del ONS

Sentinela es una aplicación de escritorio que acompaña las revisiones de los Procedimientos de Red y del Manual de Procedimientos de la Operación (MPO), las normas que publica el Operador Nacional del Sistema Eléctrico (ONS) y que un centro de operación de la transmisión necesita seguir. Recoge los documentos que importan, compara las versiones, prepara la minuta del informe interno y registra el enterado de cada operador. La publicación del informe es siempre de una persona: la automatización nunca publica sola.

Este caso técnico muestra cómo funciona el sistema, las decisiones que lo moldearon y las fallas reales que se volvieron regla. Los números se verificaron en el código, en la versión del 28/10/2026.

Transparencia: Sentinela fue diseñado y lo desarrolla Jeremias Cardoso, autor de este blog, para el centro de operación en el que trabaja. El texto no cita la empresa, personas, estaciones ni rutas de red, y deja fuera detalles de seguridad de la infraestructura.

Nota de actualización (30/10/2026): este post se reescribió como caso técnico. La versión del 19/07/2026 describía el patrón general de un robot que monitorea sitios oficiales; el patrón sigue aquí, ahora con los números, las decisiones y los incidentes del sistema real.

El problema: seis pasos hechos a mano

Antes de Sentinela, acompañar las normas era un proceso manual de seis pasos:

1. consultar el sitio del ONS;
2. identificar las normas que involucran a la empresa;
3. descargar el PDF;
4. evaluar qué cambió respecto de la versión anterior;
5. escribir un informe interno sobre el cambio;
6. recoger el enterado de todo el equipo.

El sistema automatiza los cinco primeros y digitaliza el sexto, con traza de auditoría. El centro de operación funciona 24 horas, y el sistema se diseñó para cerca de 15 operadores en turnos, con 2 a 4 usando al mismo tiempo. Cuando el seguimiento falla, el equipo opera con una norma desactualizada sin saberlo, y es justamente ese tipo de falla silenciosa el que el proyecto entero intenta evitar.

El sistema en números

Números de octubre de 2026, con la fecha de cada medida entre paréntesis.

El conteo de líneas considera solo los archivos versionados y excluye líneas en blanco y comentarios: son 29,5 mil líneas de Java, 932 de estilos y 139 de migraciones de base. Con blancos y comentarios, la aplicación pasa de 42 mil líneas físicas. La interfaz está escrita directo en Java, sin archivos de pantalla separados.

Cómo funciona el monitor

Todo monitor de fuente oficial es la misma máquina de cuatro etapas: barrer, detectar novedad, comparar y avisar. Lo que cambia es el cuidado en cada etapa.

Barrido: dato, no diseño

Las páginas del ONS se arman con JavaScript en el navegador, y el HTML que llega al robot no trae la lista de documentos. Por eso el recolector lee los datos que alimentan las páginas, en formato JSON, y no lo visual. Cuanto más cerca del dato y más lejos del diseño, menos alarma falsa; depender del diseño es el punto frágil del RPA tradicional.

La recolección corre en la pantalla, a pedido, o como tarea programada de Windows, sin interfaz. El patrón es martes y jueves a las 6 h, con un mínimo de dos veces por semana, y la tarea programada no recolecta dos veces el mismo día, a menos que alguien lo fuerce.

Detección: tres señales, no una

Para cada documento de la lista, el recolector descarga el PDF a un área de verificación y calcula el SHA-256, una huella digital del archivo. El documento solo se considera “sin novedad” cuando coinciden tres señales: el número de la revisión, la fecha de vigencia y el hash. Si la fuente publica un archivo distinto con el mismo número de revisión, el sistema no sobrescribe nada: falla cerrado, mantiene lo que ya tenía y guarda aparte la copia recibida, para que alguien investigue.

Comparación: qué cambió, página por página

El producto de un monitor no es el aviso, es la diferencia. Sentinela extrae el texto de cada página de las dos versiones y compara una con la otra. También lee el cuadro de control de revisiones que trae la propia norma, que suele decir qué alteró el ONS. Esos dos pasos son deterministas: no dependen de IA.

Aviso: minuta automática, publicación humana

Con el cambio detectado, el sistema genera la minuta del informe. Solo quien tiene el perfil de supervisor puede editar, aprobar y publicar. Después de la publicación, cada operador registra el enterado, y ese registro solo crece: el contrato de la aplicación no borra ni altera un enterado. Dos supervisores editando el mismo informe en estaciones distintas no se atropellan: cada alteración verifica la versión que la persona estaba viendo, y quien llegó después recibe un aviso de conflicto en lugar de un “guardado” falso.

Un panel llamado Vigia muestra cuándo fue la última recolección completa. Pasadas 24 horas sin recolección, ofrece la recuperación; pasadas 48 horas, muestra una alerta roja para todos.

La lista que redujo 1.657 normas a 121

La primera recolección completa trajo 1.657 normas, 1.207 de ellas instrucciones de operación. Era demasiado ruido para el centro de operación. Filtrar automáticamente por el nombre de la empresa tampoco funcionaba: el nombre no aparece en ningún metadato de la fuente.

La salida, decidida el 17/06/2026, fue una lista curada: el centro de operación registra los documentos que importan, partiendo del plan de contingencia que el equipo ya mantenía. El recolector lee los metadatos de todo, que es barato, pero solo descarga y compara lo que está en la lista. Hoy son 121 documentos. Las 1.657 normas ya descargadas siguieron en el portal como historial consultable.

La lección vale para cualquier monitor: quien define qué es relevante es quien usa la información, no el volumen que publica la fuente.

Dónde vive la base: de Access a la nube y de vuelta

Sentinela nació sin servidor, con una base Microsoft Access en una carpeta de red, para hacer viable el piloto. El 20/06/2026, la base fue a un SQL en la nube. El 24/06, por costo, fue a otra base en la nube. El 19/07, volvió a Access: la red corporativa del centro de operación no permitía la conexión de las estaciones con la base remota. El desarrollo ocurría fuera de esa red, y la validación en ella había quedado para después; fue un mes de migraciones deshecho por eso.

La vuelta trajo de nuevo la limitación conocida de Access: no organiza la escritura entre procesos de máquinas distintas. El 01/08/2026, el proyecto midió eso con tres procesos grabando en el mismo archivo, en el mismo milisegundo:

• en cerca de 7 de 24 rondas, dos procesos consiguieron insertar el mismo registro;
• en 5 de 5 rondas de escritura simultánea, el archivo quedó con cero líneas legibles en la tabla;
• una actualización condicionada, que debía dejar pasar solo uno, informó éxito en los tres procesos en 4 de 4 rondas.

La respuesta fue poner el árbitro fuera del archivo de datos. Desde el 30/09, la recolección adquiere un bloqueo de archivo del sistema operativo, al lado de la base, antes de cualquier otra cosa, y la tarea programada corre entera bajo ese bloqueo. La estación que pierde la disputa sale sin escribir nada. Antes de eso, la perdedora seguía a las etapas siguientes, grababa en la base sin bloqueo y además salía con código de éxito.

El sistema hermano, SIGCOT, resolvió el mismo problema cambiando Access por un SQL Server corporativo. Sentinela, cuya escritura pesada se concentra en la recolección, se quedó en Access y pasó a controlar quién escribe y cuándo.

El análisis de relevancia: IA solo con lo que es público

Saber qué cambió no basta: alguien tiene que decir si el cambio importa para la operación. Para eso Sentinela prepara un paquete con la diferencia entre las versiones, el cuadro de control de revisiones y un guion de preguntas. La respuesta esperada tiene formato fijo: resumen, relevancia (alta, media o baja), justificación y los fragmentos afectados con el número de página. El guion prohíbe inventar: sin evidencia en el material, la respuesta es “no encontrado”.

El modo predeterminado es el asistido: una persona lleva el paquete a un asistente de IA externo y pega la respuesta de vuelta en el sistema. Existe un modo automático opcional, con un proveedor en la nube o un modelo local, que recibe el mismo paquete y devuelve el trabajo a la vía asistida cuando falla. En la red del centro de operación, los proveedores externos de IA están bloqueados, así que el modo asistido es el que vale, y el análisis automático quedó como recurso aplazado.

La regla es que solo contenido público del ONS entra en el paquete, nunca un informe interno o un dato personal. La búsqueda del portal y el asistente de dudas del manual no usan IA: el asistente, cuando no sabe la respuesta, dice que no sabe. Es la misma división que funciona fuera del laboratorio: la automatización hace el trabajo repetitivo, y el juicio queda con la persona.

Incidentes que se volvieron regla

22/07/2026: el respaldo que nacía y moría en el mismo ciclo. El respaldo diario copiaba la base a un archivo con la fecha en el nombre. En Windows, la copia hereda la fecha de modificación del archivo original, y la rutina que borra respaldos de más de 30 días juzgaba la edad por esa fecha. En una base sin escritura desde hacía más de 30 días, el respaldo del día se creaba y se borraba en el mismo ciclo, y la estación quedaba sin ningún respaldo, en silencio. La rotación pasó a usar la fecha del nombre del archivo.

22/07/2026: la prueba que cayó en la base de producción. En la misma verificación, un archivo de configuración de prueba se grabó con un carácter invisible al inicio, el BOM, que algunas herramientas de Windows añaden. La primera clave del archivo dejó de reconocerse, y el sistema cayó en la carpeta predeterminada, que era la base real. El ciclo consultó dos documentos en el sitio del ONS y grabó un registro de recolección. No se perdió nada, y la verificación mostró la base real con el mismo tamaño de antes. El informe registró la causa y la orientación: un archivo de configuración de prueba no se graba con esa herramienta, o se verifican los primeros bytes antes de correr.

27/07/2026: “perdí todos los datos”. Al abrir el paquete en una estación del centro de operación, el autor vio una instalación nueva: sin documentos, sin usuarios, pidiendo el cambio de la contraseña inicial. Los datos no habían desaparecido. La carpeta predeterminada de Sentinela, usada cuando ninguna estaba configurada, apuntaba a la carpeta de datos de otro sistema, que existe en todas las estaciones. La prueba de acceso pasó, y Sentinela creó ahí una base vacía sin que fallara ningún paso.

La corrección se volvió regla inviolable: el sistema nunca crea una base sin consentimiento explícito, frente a la ruta completa, y la tarea programada nunca crea una base. El patrón de último recurso cambió a una carpeta que no existe por accidente. Once pruebas traban esa decisión.

02/08/2026: el botón de detener que borraría la alarma. La primera versión del comando “detener después de este documento” grababa un registro de recolección interrumpida. Una guarda automática reprobó la compilación: cualquier registro nuevo de recolección ponía en cero el reloj de Vigia. Una recolección detenida en el tercero de 121 documentos diría “recolectó ahora” y escondería el atraso de los otros 118. La interrupción pasó a registrarse fuera del historial de recolecciones.

01/10/2026: la contraseña correcta en la base equivocada. La dirección de la base quedaba guardada en el perfil de Windows de cada operador. Un operador grabó una ruta sin base y dejó de poder entrar. Redefinir la contraseña no sirvió, porque la contraseña estaba en la base verdadera y la estación miraba a otro lugar. La dirección pasó a venir de un vínculo central, al lado del ejecutable.

23/10/2026: el paquete que no salió del commit. La verificación de la versión 1.1.10 mostró que el paquete de instalación se había generado ocho minutos antes del commit, a partir de la carpeta de trabajo. El contenido era el mismo, pero no había cómo probarlo. El paquete se rehízo el 27/10 a partir del commit limpio, y solo entonces la versión ganó la etiqueta.

28/10/2026: reprobado en la prueba presencial. El autor probó en la estación el aviso por correo de la versión 1.2.0 y lo reprobó por tres motivos: los destinatarios salían separados por coma, que Outlook no acepta en el campo Para; la ventana se abría y no enviaba, cuando el pedido era envío automático; y el cuerpo traía una frase fija en lugar de las alteraciones. La 1.2.0 se congeló sin publicación, y la 1.3.0 rehizo el aviso con envío automático y una tarjeta con las alteraciones.

Desempeño: contar conexiones antes de cronometrar

Con Access en una carpeta de red, abrir una conexión sale caro: en la configuración que mantiene el archivo íntegro entre estaciones, cada apertura relee la base. En lugar de cronometrar pantallas, la auditoría de desempeño de septiembre contó conexiones, medidas en bases de 3 y de 12 documentos:

El ciclo de recolección pasó a hacer 121 relecturas menos. La ganancia en segundos, sin embargo, no se midió: el cronometraje real en el centro de operación depende de implantar la versión con medición automática de apertura e inicio de sesión y de una semana de recolección de datos. El proyecto registra eso como pendiente, no como victoria.

Pruebas y guardas

La suite creció con el sistema: 111 pruebas el 20/06/2026, 631 el 28/07, 968 en la versión 1.1.0, 1.145 el 30/09 y 1.256 el 28/10, sin fallas. Veinte clases son guardas de arquitectura: en lugar de probar una función, leen el código fuente y traban una regla. Una verifica que todo acceso a la base queda en la capa de datos. Otra verifica que ningún resultado parcial, cancelado o con falla aparece como éxito verde. Otra verifica que ningún secreto va dentro del paquete de instalación.

El proyecto tiene 13 reglas inviolables, y la mayoría tiene guarda automática, en el espíritu de las compuertas que prueban. La lectura del código para este texto no encontró guarda automática para cuatro de ellas, que dependen de revisión: el enterado que solo crece, la regla de que la IA solo recibe contenido público, la prohibición de estilo directo en el código de la pantalla y la actualización de los mapas de arquitectura.

El paquete portátil trae Java incorporado, así que la estación no necesita instalarlo. Antes de cada entrega, una prueba de humo hace 24 verificaciones en una carpeta nueva y verifica, por el hash, que el archivo de configuración real de la estación no fue tocado.

Lo que todavía no está resuelto

• La 1.3.0 no está cerrada. La etiqueta espera la aprobación de la prueba presencial, y el envío real del correo todavía no se ejecutó en la estación.
• La aceptación con tres estaciones en la carpeta de red real no se hizo. Depende de TI y está documentada como no ejecutada.
• El cronometraje en el centro de operación nunca ocurrió. La ganancia de desempeño está probada en conexiones, no en segundos.
• El análisis automático por IA está aplazado, porque la red bloquea a los proveedores externos.
• Los mapas de arquitectura se detuvieron en agosto. Las decisiones de octubre todavía no están en ellos, lo que incumple una de las reglas inviolables.
• No hay número de uso. El repositorio no registra cuántos informes se publicaron ni cuántos enterados se dieron. Este texto no afirma ganancia de productividad porque ese número no existe.

Lecciones que valen fuera del sector eléctrico

1. Filtre por la lista de quien usa, no por lo que publica la fuente. De 1.657 normas, 121 importan.
2. Pruebe el camino de red antes de migrar la base. Un mes de migraciones cayó en una conexión que la red no permitía.
3. Una base de archivo compartido necesita un árbitro fuera del archivo. Un índice único y una actualización condicionada no sostuvieron tres procesos; el bloqueo del sistema operativo sí.
4. Un patrón de último recurso no puede existir por accidente. La carpeta predeterminada que ya existía en todas las estaciones transformó “abrí la carpeta equivocada” en “lo perdí todo”.
5. El instrumento de vigilancia no puede borrar lo que vigila. Un registro de más habría puesto en cero el reloj de Vigia.
6. El paquete sale del commit, no de la carpeta de trabajo. Sin eso, la versión instalada no tiene cómo probar de dónde vino.

Fuentes

• Arquitectura, decisiones, incidentes, mediciones, pruebas y conteo de líneas: repositorio de Sentinela en la versión del 28/10/2026, leído por el autor; extracto con los fragmentos, el método del conteo y los límites de la verificación, verificado el 2026-10-30.
• Procedimientos de Red y MPO, las fuentes recolectadas: Operador Nacional del Sistema Eléctrico (ONS), dirección usada por el recolector verificada en el código el 2026-10-30.