Por qué nació

El punto de partida era reducir el tiempo empleado en consultar incidencias de soporte, reconstruir su histórico y preparar resúmenes útiles para los equipos. La dificultad no estaba únicamente en mostrar tickets: había que integrar un sistema corporativo de soporte, ejecutar análisis asistidos por IA, respetar sesiones personales y mantener cualquier operación sensible bajo control humano.

Primera arquitectura

Las primeras versiones combinaron una API central, una interfaz web y un componente instalado en el equipo de cada usuario. Ese componente acercaba al navegador las sesiones corporativas y el agente de IA, pero también añadía instalación, actualización, diagnóstico y diferencias entre portátiles.

La cadena de entrega se diseñó desde el principio para ser comprobable: pruebas antes de construir, imágenes identificadas por digest, firma con Cosign y verificación del artefacto publicado. Una versión anterior alcanzó 166 pruebas y permitió comprobar que API, web y descarga pública correspondían exactamente con lo generado localmente.

Por qué se cambió a una solución exclusivamente web

La evolución más importante fue retirar el componente de los portátiles. La versión actualmente operativa utiliza autenticación central con contraseñas protegidas mediante Argon2, una API y web públicas y servicios Windows centrales para las integraciones que no pueden ejecutarse dentro del servidor web.

Esta decisión redujo el soporte en puestos de usuario, eliminó actualizadores y protocolos locales y permitió controlar mejor versiones y observabilidad. Las sesiones del sistema de soporte permanecen separadas por usuario: credenciales, perfil de navegador, cookies y MFA no se comparten entre personas.

Separar las responsabilidades

La arquitectura quedó dividida en fronteras claras:

  • La web presenta incidencias, histórico, estados y acciones permitidas.
  • La API central gestiona identidad, roles, configuración, auditoría y resúmenes mínimos.
  • Los workers de IA ejecutan trabajos fuera del servidor web y devuelven resultados controlados.
  • Las sesiones del sistema de soporte se mantienen en procesos centrales aislados por usuario.
  • PostgreSQL conserva usuarios, roles, auditoría y resúmenes; no almacena el cuerpo completo de los tickets ni los mensajes del sistema externo.

Escrituras limitadas y controladas

La automatización permanece desactivada. La operación normal es de consulta y existe una única excepción manual para determinados responsables: preparar una asignación de incidencia, confirmarla expresamente, ejecutar una sola modificación y releer después el registro para comprobar el resultado.

El resto de operaciones de escritura continúa bloqueado. Esta frontera evita que una función de ayuda termine convirtiéndose accidentalmente en un motor autónomo de cambios sobre el sistema corporativo.

Mejoras que siguen en desarrollo

Sobre la versión web operativa se está preparando una evolución local con varios workers de IA concurrentes. Cada conexión tiene identidad, heartbeat, capacidad y estado libre u ocupado; un sistema de leases reparte los trabajos sin enviar dos veces la misma tarea.

También se ha añadido configuración adaptada al rol y un primer acceso obligatorio para cuentas nuevas. Antes de operar, cada persona debe completar las integraciones que necesita, elegir su proyecto de IA y seleccionar un modelo compatible. Una migración preserva las cuentas existentes para evitar que la mejora interrumpa a los usuarios actuales.

Este candidato local ha superado 178 pruebas, la construcción de las imágenes y la validación del flujo de primer acceso. Todavía no se ha desplegado y durante esas pruebas no se realizaron llamadas reales a los sistemas corporativos ni escrituras sobre incidencias.

Resultado actual

La versión web central está operativa y la automatización sigue deshabilitada. El siguiente paso no consiste en añadir funciones sin límite, sino en validar el pool concurrente, la experiencia de configuración personal y el comportamiento con sesiones reales antes de plantear una nueva publicación.

Lo que aprendí

  • El alcance de un despliegue también es una medida de seguridad.
  • Centralizar simplifica el puesto de usuario, pero obliga a aislar correctamente identidad y sesiones.
  • Una firma o un digest demuestran qué se ha desplegado; las pruebas demuestran cómo debería comportarse.
  • Las integraciones con capacidad de escritura necesitan confirmación, auditoría y lectura posterior.
  • El estado «en desarrollo» debe permanecer visible aunque una versión anterior ya esté operativa.