Los 14 agentes IA de Calut: qué hace cada uno y cuándo actúa

La diferencia entre un agente y un módulo

Un módulo es una pantalla donde puedes hacer algo. Un agente es un proceso que trabaja sin que lo llames: observa un estado, detecta un cambio, ejecuta una acción y registra evidencia.

En Calut coexisten los dos. Hay módulos donde tú decides — el registro de riesgos, el SoA, las auditorías. Y hay agentes que actúan solos según reglas configurables, notifican cuando algo requiere atención y generan la evidencia que el auditor necesita.

Actualmente Calut tiene 14 agentes IA: 13 agentes autónomos que trabajan en segundo plano, más Auror, el CISO IA con el que puedes conversar. Cada uno tiene un dominio específico, un conjunto de disparadores y outputs concretos.

Los 13 agentes autónomos

Voyager — Seguridad técnica de endpoints

Qué monitoriza: los equipos Windows con el agente instalado. Hardware, software, parches pendientes, antivirus, puertos TCP en escucha, política de contraseñas, auditoría de eventos, sincronización NTP.

Cuándo actúa: cuando detecta un equipo offline, una CVE crítica o importante en un endpoint, parches críticos sin aplicar o puertos expuestos. Crea tareas de remediación automáticamente.

Qué genera: vulnerabilidades AGT con código trazable, evidencia técnica vinculada a ISO 27001 A.8.3 (gestión de activos), A.8.7 (antivirus), A.8.8 (vulnerabilidades técnicas) y A.8.20 (seguridad de redes). Auto-cierra vulnerabilidades cuando el equipo vuelve a reportar en buen estado. El Calut Score se recalcula en tiempo real con cada hallazgo.

Vulcan — Ciclo de vida de vulnerabilidades

Qué monitoriza: el inventario completo de vulnerabilidades abiertas en todos los activos, su criticidad y antigüedad (ISO 27001 A.8.8).

Cuándo actúa: cuando hay vulnerabilidades abiertas sin priorizar o sin plan de remediación.

Qué genera: priorización por criticidad y recomendaciones de remediación accionables. Donde Voyager detecta el hallazgo técnico en el endpoint, Vulcan gestiona el ciclo de vida completo de la vulnerabilidad hasta su cierre, con evidencia para A.8.8.

Sentinel — Detección de eventos SIEM

Qué monitoriza: el correlador SIEM en tiempo real. Intentos de login fallidos (ID 4625), uso de credenciales explícitas (4648), asignación de privilegios especiales (4672), creación de usuarios (4720), adición a grupos privilegiados (4732).

Cuándo actúa: cada 15 minutos. Es el agente con mayor frecuencia de ejecución porque los eventos SIEM tienen ventanas de respuesta cortas. Cuando identifica una alerta de severidad alta o crítica, genera con IA un análisis de respuesta inmediata con pasos accionables y controles ISO 27001 aplicables.

Qué genera: análisis de eventos con taxonomía de severidad, escalamiento automático al módulo de incidentes, notificación al administrador del tenant. Evidencia para A.8.15 (registro de actividades) y A.6.8 (reporte de eventos de seguridad).

Altair — Gestión de incidentes

Qué monitoriza: el ciclo de vida de los incidentes de ciberseguridad — incidentes sin categorizar, SLA de respuesta y pre-incidentes que ingresan desde el portal público.

Cuándo actúa: cuando hay incidentes sin clasificar, cuando se supera un SLA de respuesta, o cuando entra un pre-incidente desde el portal público.

Qué genera: clasificación automática con IA según las categorías ANCI / Ley 21.663, alertas cuando vencen los SLA, y una evaluación de cada pre-incidente con la recomendación de escalar, monitorear o descartar. Evidencia para la gestión de incidentes (A.5.24–A.5.27) y la notificación obligatoria bajo Ley 21.663.

Rigel — Registro de riesgos

Qué monitoriza: el mapa de calor de riesgos y el Plan de Tratamiento de Riesgos (PTR). Planes sin asignar, riesgos críticos o altos sin plan de acción, fechas de tratamiento vencidas.

Cuándo actúa: cuando un riesgo requiere atención urgente por su nivel de criticidad o por haber superado su fecha de tratamiento.

Qué genera: re-priorización de PTRs por fecha límite e impacto regulatorio, alertas al propietario del riesgo, evidencia de gestión activa para ISO 27001 cláusula 6.1 y A.5.7 (inteligencia de amenazas).

Clio — Auditorías internas

Qué monitoriza: las auditorías programadas próximas, las no conformidades (NC) abiertas y los controles sin implementar en la SoA (ISO 27001 cláusula 9.2).

Cuándo actúa: cuando se acerca una auditoría programada, cuando una NC lleva tiempo sin plan de acción, o cuando un framework regulatorio cae por debajo del umbral de cumplimiento.

Qué genera: checklists de preparación, tareas correctivas con responsable y plazo, y alertas sobre frameworks con bajo cumplimiento (ISO 27001, NIST CSF, Ley 21.663, Ley 21.719). Evidencia trazable para la cláusula 9.2 (auditoría interna) y 10.1 (no conformidad y acción correctiva). El ciclo PDCA queda documentado automáticamente.

Lyra — Documentación del SGSI

Qué monitoriza: el ciclo de vida de todos los documentos del sistema de gestión: políticas, procedimientos, fichas de riesgo. Fecha de revisión, documentos sin aprobar y brechas en la cobertura documental requerida por ISO 27001.

Cuándo actúa: cuando un documento está vencido o expira en los próximos 30 días, o cuando falta documentación obligatoria para un control.

Qué genera: alertas de vencimiento, asignación de revisiones al responsable, evidencia continua para A.7.5 (información documentada). El auditor llega y todos los documentos tienen fecha de revisión vigente y responsable asignado.

Hermes — Identidades y accesos

Qué monitoriza: el ciclo de vida de las identidades (ISO 27001 A.5.18, A.8.2, A.8.5). Cuentas sin revisar, accesos con privilegios excesivos y procesos de offboarding incompletos.

Cuándo actúa: cuando una cuenta lleva tiempo sin revisión, cuando detecta privilegios excesivos, o cuando un offboarding queda a medias.

Qué genera: alertas de revisión de accesos y evidencia de gestión de identidades para A.5.18 (derechos de acceso), A.8.2 (accesos privilegiados) y A.8.5 (autenticación segura).

Nexus — Seguridad de proveedores

Qué monitoriza: el programa de seguridad de proveedores (ISO 27001 A.5.19–A.5.22 y Ley 21.663 art. 8). Contratos próximos a vencer, evaluaciones de riesgo pendientes y proveedores sin clasificar.

Cuándo actúa: cuando un contrato vence en los próximos 30 días, cuando una evaluación de riesgo queda pendiente, o cuando un proveedor no tiene clasificación de criticidad.

Qué genera: alertas priorizadas, recordatorios de evaluación y evidencia de gestión para A.5.19–A.5.22 (seguridad en relaciones con proveedores) y el artículo 8 de la Ley 21.663.

Orión — Formación y concienciación

Qué monitoriza: el programa de conciencia y capacitación en ciberseguridad (ISO 27001 cláusulas 7.2/7.3). Colaboradores con cursos vencidos, tasas de completitud, asignaciones pendientes por área o rol.

Cuándo actúa: cuando un colaborador no tiene capacitación activa en su área de responsabilidad o cuando una certificación está por vencer.

Qué genera: asignación de cursos por rol, recordatorios automáticos, y un análisis de brechas del programa con IA. Cubre A.6.3 (concienciación, educación y formación) sin coordinación manual con RRHH.

Atlas — Continuidad de negocio

Qué monitoriza: los planes de continuidad de negocio BCP/DRP (ISO 27001 A.5.29, A.5.30, A.8.13). Planes no probados, pruebas fallidas y análisis BIA desactualizados.

Cuándo actúa: cuando un plan lleva tiempo sin probarse, cuando una prueba falla, o cuando un análisis de impacto al negocio (BIA) queda desactualizado.

Qué genera: alertas de continuidad y evidencia para A.5.29 (continuidad durante una disrupción), A.5.30 (preparación TIC para la continuidad) y A.8.13 (respaldo de información).

Proteo — Privacidad y datos personales

Qué monitoriza: el cumplimiento de la Ley 21.719 de protección de datos personales. Obligaciones del DPO, plazos de respuesta ARCO+, brechas de datos pendientes de notificación y PIAs sin completar.

Cuándo actúa: cuando vence un plazo de respuesta ARCO+, cuando una brecha de datos queda sin notificar, o cuando falta una evaluación de impacto en privacidad (PIA).

Qué genera: alertas de plazos y obligaciones, y evidencia de cumplimiento bajo la Ley 21.719 para el DPO.

Prometheus — Certificados y criptografía

Qué monitoriza: el inventario de certificados digitales y algoritmos criptográficos (ISO 27001 A.8.24).

Cuándo actúa: cuando un certificado está próximo a vencer o ya expiró.

Qué genera: alertas de vencimiento de certificados y evidencia para A.8.24 (uso de criptografía), evitando caídas de servicio por certificados expirados.

Auror — el que conversa

Auror es el agente número catorce, pero no trabaja en segundo plano: es el CISO IA con el que puedes hablar. Conoce el estado real de tu SGSI — cuántos activos tienes con agente, cuántos controles sin evidencia, qué alertas tienen los otros agentes — y responde preguntas concretas sobre tu situación. En modo agéntico, además, puede ejecutar acciones directamente sobre la plataforma.

La diferencia con un chatbot genérico: Auror no responde sobre ISO 27001 en abstracto. Responde sobre tu ISO 27001, con tus datos actuales. "¿Estoy listo para la auditoría?" obtiene una respuesta con tu Calut Score, tus controles críticos sin evidencia y tus vencimientos próximos.

Cómo se relacionan entre sí

Los agentes no son compartimentos estancos. Hay dependencias reales:

• Voyager → Vulcan: Voyager detecta el hallazgo técnico en el endpoint; Vulcan gestiona el ciclo de vida completo de la vulnerabilidad hasta su cierre.
• Voyager → Sentinel: los endpoints con agente Windows son la fuente de eventos que Sentinel analiza. Sin Voyager, Sentinel trabaja solo con logs del correlador SIEM.
• Sentinel → Altair: cuando Sentinel detecta una alerta crítica, escala al módulo de incidentes, donde Altair la clasifica y le aplica las categorías ANCI / Ley 21.663.
• Hermes → Clio: los accesos sin revisar o con privilegios excesivos pueden originar no conformidades que Clio gestiona en el ciclo de auditoría.
• Lyra + Rigel + Clio + Orión → Calut Score: el score agrega el estado de documentación, riesgos, auditorías y formación en un único número que Auror puede explicar.

Lo que los agentes no hacen

Los agentes ejecutan dentro de los límites que el equipo de seguridad define. No toman decisiones estratégicas, no modifican configuraciones de sistemas externos, no envían comunicaciones regulatorias sin confirmación humana. El principio es claro: el agente propone, el humano aprueba.

En el caso de Altair, la clasificación de un incidente y la evaluación de un pre-incidente se generan automáticamente, pero la notificación formal a la ANCI requiere confirmación humana. En el caso de Nexus, los recordatorios a proveedores se envían automáticamente, pero las cláusulas contractuales las redacta el equipo legal.