Agente de IA para el triaje de fallos de CI y la respuesta a incidentes

Un despliegue que falla en plena noche ya no debería despertar a nadie. Sin embargo, en muchos equipos sigue siendo un ingeniero de guardia quien abre los logs en frío, busca el commit culpable y escribe el mensaje de Slack que avisa a los demás. Un agente de IA autónomo puede encargarse de este primer paso, sin sustituir nunca el criterio humano sobre la causa raíz o la corrección.

El problema

Las cifras sobre la fiabilidad de los pipelines CI/CD no son buenas. Según el informe 2026 State of Software Delivery de CircleCI, la tasa de éxito de los builds en la rama principal ha caído al 70,8 %, el nivel más bajo observado en cinco años y muy por debajo del umbral del 90 % que recomienda el propio proveedor (CircleCI, 2026). En la práctica, unos tres de cada diez intentos de merge fallan antes de llegar siquiera a producción.

En el lado de los incidentes, el informe State of Incident Management de Runframe, publicado a principios de 2026, constata que la parte del tiempo de ingeniería absorbida por el trabajo operativo rutinario (responder alertas, clasificar fallos, escalar información) ha vuelto a subir al 30 %, en aumento por primera vez en cinco años pese a la inversión en IA (Runframe, 2026). El mismo informe apunta que cerca de dos tercios de las alertas generadas cada día se ignorarían por falta de tiempo para clasificarlas correctamente. Es un orden de magnitud que conviene tomar con cautela: el informe agrega varios estudios externos y entrevistas cualitativas, no es una medición directa y única.

El informe DORA 2025 sobre desarrollo de software asistido por IA va en el mismo sentido en un punto de fondo: la IA amplifica lo que ya existe en una organización, no corrige un proceso de triaje deficiente, simplemente lo hace más visible, más rápido (DORA, 2025). Un pipeline mal supervisado sigue estándolo, con o sin IA, mientras nadie observe los fallos de forma continua.

Este último punto cuenta especialmente para los equipos que funcionan con una guardia reducida, donde una sola persona vigila varios servicios a la vez. Un fallo de build que llega a las 3 de la madrugada no suele esperar a que alguien se despierte para ser clasificado: o bien queda ignorado hasta la mañana, o bien despierta a alguien por un problema que, una vez clasificado, resulta menor. Ambos desenlaces salen caros, uno en tiempo de resolución, el otro en fatiga de guardia acumulada con el tiempo.

Qué hace el agente, paso a paso

En Atako, este agente no se activa una vez y se detiene: funciona de forma continua en su propio entorno aislado. Dos mecanismos de entrada lo alimentan, un webhook entrante que el equipo configura para recibir los eventos de CI/CD, y una tarea cron que el propio agente programa para verificar periódicamente el estado de los workflows por si el webhook llegara a perder algún evento.

En cuanto llega un fallo, el agente lee los logs y la stack trace del job para clasificar el tipo de problema (compilación, test, dependencia, despliegue), y luego correlaciona ese fallo con los commits y pull requests recientes para identificar al autor probable y el cambio sospechoso. A continuación publica un resumen estructurado en Slack, en el canal de guardia, con los enlaces directos al job y al commit causante, y abre en paralelo un ticket en Jira vinculado. Si la gravedad supera un umbral definido por el equipo (despliegue bloqueado, varios servicios afectados), se dispara una escalada adicional hacia las personas correctas. Por último, redacta una primera versión del informe de incidente: cronología, servicios afectados, logs pertinentes, causa sospechada, dejada deliberadamente abierta a la revisión humana en lugar de presentarse como una conclusión definitiva.

Las integraciones utilizadas

Cada integración se concede mediante un grant preciso, que limita exactamente lo que el agente puede hacer, nunca un acceso genérico a la herramienta entera.

GitHub y GitLab proporcionan lectura de los pipelines, los jobs y los commits, con escritura opcional para abrir o comentar una issue si el grant cubre ese scope. En GitHub, las acciones concretas en juego son list_workflow_runs y get_job_logs_download_url en lectura, create_issue y add_issue_comment en escritura.

Slack recibe los resúmenes de triaje mediante post_message, en el canal elegido por el equipo, con la posibilidad de programar un recordatorio mediante schedule_message si un incidente permanece abierto demasiado tiempo.

Jira lleva el propio ticket de incidente: create_issue en la apertura, update_issue y transition_issue a lo largo de la resolución, hasta el cierre.

Datadog, cuando el equipo lo ha conectado, permite al agente cruzar las métricas de rendimiento y las trazas de aplicación con el fallo de CI para afinar su hipótesis de causa raíz. PagerDuty todavía no tiene página de integración dedicada en Atako, pero sigue siendo utilizable como destino de alerta mediante un webhook saliente configurado desde Jira o Slack.

Lo que sigue en manos humanas

El agente nunca decide por su cuenta fusionar una corrección, y no es un detalle de diseño, es la forma en que Atako estructura la autonomía. Cada acción que el agente puede ejecutar en GitHub, GitLab, Jira o Slack depende de un grant explícito: qué acciones precisas están autorizadas, con qué alcance (solo lectura, o lectura y escritura). Ese alcance prevalece incluso si una acción de escritura acabara por error en una lista de acciones autorizadas en lectura, y nunca se concede nada por defecto por el simple hecho de conectar una herramienta.

Eso deja tres cosas claramente del lado humano. Primero, la investigación de la causa raíz y la decisión técnica de la corrección: el agente aporta un punto de partida (logs, commit sospechoso, historial), no un diagnóstico definitivo. Segundo, la escritura y la fusión del código, una acción humana por naturaleza, fuera del alcance de lo que el agente puede hacer. Tercero, el post-mortem: ajustar los umbrales de gravedad, revisar el runbook, mejorar las reglas de triaje, un trabajo de equipo que el agente no sustituye.

Este reparto es lo que se conoce como human-in-the-loop: el agente absorbe la parte repetitiva y que consume tiempo del triaje, la persona conserva el control de las decisiones que realmente importan. Para verificar lo que el agente hizo realmente, cada llamada de integración queda registrada, con el agente implicado, la acción, el estado (autorizada y ejecutada, denegada por un control de grant, o fallida del lado del proveedor) y la latencia. Ese rastro es visible en la línea de tiempo de actividad del agente y, para un administrador, en el registro de integraciones de toda la empresa, exportable en CSV.

Resultado medible

El beneficio más directo es el tiempo entre el fallo del build y el momento en que la persona correcta tiene la información completa para actuar. Ya no hace falta esperar a que un humano note la alerta, abra los logs y cruce manualmente con los commits recientes: el agente lo hace de forma continua, incluso a las 3 de la madrugada, sin dormir nunca ni cambiar de humor según la carga de la semana. Esto no sustituye a las métricas DORA clásicas como la frecuencia de despliegue o el tiempo de restauración tras un fallo, pero reduce la parte de esas métricas que depende únicamente de la disponibilidad humana en un momento dado.

El costo sigue el plan Standard de Atako: 20 euros al mes por slot de agente, con 1000 créditos incluidos cada mes para cubrir las llamadas al modelo usadas en el razonamiento, la clasificación y la redacción. Para calcular el retorno antes de lanzarse, el detalle está en la página de precios.