LogicMonitor Edwin AI y Ansible unen diagnóstico y remediación gobernada

Red Hat y LogicMonitor han publicado una integración entre Ansible Automation Platform y Edwin AI, el motor de análisis de incidentes de la segunda. La idea es que la IA que diagnostica el problema sea también la que proponga la remediación, pero ejecutada bajo los controles que ya tiene la plataforma de automatización. Quien decide sigue siendo la organización: la IA no se salta el RBAC ni las aprobaciones.

Qué aporta cada pieza

Edwin AI hace la parte de investigación: deduplica eventos, correlaciona alertas relacionadas, enriquece el incidente con la topología de servicios y señala la causa raíz probable. Con ese contexto montado se conecta a Ansible Automation Platform a través de su API y busca playbooks que encajen con la situación. Del otro lado, la plataforma de Red Hat pone la capa de ejecución sobre infraestructura híbrida.

Muchos incidentes se repiten: un certificado caducado, una deriva de configuración, un servicio que falla siempre igual. Son candidatos naturales a un playbook que ya está escrito. La gracia del flujo conjunto es que nadie tenga que recordar dónde vive ese playbook ni quién lo mantiene. Si no hay ninguno que sirva, el asistente de código de Ansible Automation Platform puede redactar contenido nuevo a partir del contexto que armó Edwin AI, y ese contenido pasa por revisión y aprobación antes de tocar producción.

Event-driven Ansible: el otro camino

Para condiciones predecibles, donde el evento y la respuesta ya están definidos, entra Event-Driven Ansible. LogicMonitor detecta el evento y lanza un webhook. Event-Driven Ansible recibe la alerta y la evalúa contra un rulebook, que decide si corresponde ejecutar una corrección. Si hace falta, la plataforma abre o actualiza un ticket de ITSM por API y lo cierra cuando la automatización termina bien. Luego se lanza el playbook o job template correspondiente y vuelve la monitorización. Los dos caminos no compiten: el determinista cubre lo conocido, la parte de IA cubre lo que necesita interpretación.

El argumento de Red Hat para que esto pase una revisión de seguridad son RBAC, credenciales gestionadas, trazas de auditoría, aplicación de políticas y aprobaciones humanas cuando haga falta. Como las políticas se pueden ajustar al riesgo de cada acción, plantean un arranque por fases: primero enriquecer el contexto sin cambiar nada, después automatizar procedimientos rutinarios con retorno conocido y, al final, auto-reparación gobernada. El proveedor de servicios gestionados Nexon Asia Pacific ya lo usa en entornos de sus clientes, según el propio anuncio.

Lo que no aparece en la nota es justo lo que un responsable de infraestructura querría ver antes de mover ficha: versiones mínimas de ambas plataformas, precio, fecha de disponibilidad general y algún dato de rendimiento que no venga del fabricante. El flujo tiene sentido técnico y encaja con lo que ya se hace con Event-Driven Ansible, pero toda la evidencia es de quien vende la integración.