Triaje de incidentes con agentes: diseño, controles y trazabilidad

El triaje es el momento en que una alerta se convierte en un incidente con dueño, prioridad y una primera hipótesis. Es un trabajo que exige experiencia y, al mismo tiempo, mucha lectura repetitiva: abrir paneles, buscar el componente en la CMDB, revisar si hubo un cambio reciente, mirar si el mismo síntoma apareció la semana pasada. Esa combinación lo convierte en uno de los primeros candidatos razonables para un agente de IA, siempre que el diseño ponga los controles antes que la autonomía.

Por qué el triaje es un buen primer caso

Tres características hacen del triaje un caso adecuado para empezar:

• Alto volumen y patrón repetible. Una parte importante de las alertas corresponde a síntomas conocidos con un grupo resolutor claro.
• Resultado verificable. El analista puede revisar en segundos si la clasificación y el enrutamiento propuestos tienen sentido, y el cierre del incidente confirma después si la causa probable era correcta.
• Costo de error contenible. Si el agente solo sugiere, un error cuesta una reasignación, no una caída.

Lo que no conviene es saltar directamente a un agente que reasigna, escala y ejecuta acciones por su cuenta. El valor del triaje asistido está en la velocidad y la consistencia de la primera lectura, no en eliminar al analista.

Flujo de referencia

Un diseño que funciona bien separa el trabajo en etapas, cada una con entradas y salidas claras. Así puedes evaluar y corregir cada etapa por separado.

1. Alerta. El evento llega desde la plataforma de monitoreo (Dynatrace, Datadog, Prometheus u otra) o desde el service desk. El agente recibe el payload original sin modificar.
2. Enriquecimiento. El agente consulta, mediante herramientas de solo lectura, las métricas, logs y trazas del servicio afectado en la ventana relevante; el registro de la CMDB (dependencias, dueño, criticidad, horario de servicio); los cambios aplicados en las últimas horas; y los incidentes recientes con síntomas parecidos.
3. Clasificación. Propone categoría, servicio afectado, impacto y urgencia según la matriz de prioridad que ya usa tu organización. No inventa una matriz nueva.
4. Causa probable. Formula una o más hipótesis, cada una con la evidencia concreta que la sostiene (la métrica, la línea de log, el cambio) y un nivel de confianza.
5. Enrutamiento. Sugiere el grupo resolutor a partir del dueño en la CMDB y de las reglas de asignación vigentes.
6. Acción sugerida. Si existe un runbook aplicable, lo referencia y propone el primer paso. Si no existe, lo dice explícitamente.

El resultado de todo el flujo es una nota estructurada en el ticket, visible para el analista, que decide si la acepta, la corrige o la descarta.

Primero solo lectura

La regla de diseño más importante es empezar con permisos de solo lectura sobre todo: telemetría, CMDB, historial de tickets y repositorio de cambios. El único permiso de escritura inicial debería ser agregar una nota interna al ticket.

Esto tiene consecuencias prácticas:

• Usa una cuenta de servicio dedicada para el agente, separada de las cuentas humanas, con alcance limitado a los sistemas del flujo.
• Expón al agente herramientas específicas ("consultar métricas del servicio X en esta ventana") en lugar de acceso genérico a una API o a una consola.
• Valida los parámetros de cada herramienta: ventanas de tiempo máximas, servicios permitidos, límites de resultados.
• Trata el contenido de alertas, logs y tickets como datos no confiables. Un texto dentro de un log puede intentar darle instrucciones al agente (inyección de instrucciones); el agente no debe tener permisos que conviertan ese intento en daño.
• Revisa qué datos sensibles pueden aparecer en los logs que el agente lee y dónde se procesan. En sectores regulados esto debe pasar por las áreas de seguridad y cumplimiento antes del despliegue.

Cuándo y cómo ampliar esos permisos es una decisión que conviene tomar con un marco explícito. Conviene definirla con una escala explícita de niveles de autonomía, acordada con riesgo y cumplimiento.

Registro de decisiones para auditoría

Si un agente participa en el triaje, cada una de sus intervenciones debe poder reconstruirse después: qué vio, qué concluyó, qué propuso y qué hizo la persona con esa propuesta. Este registro sirve para tres cosas: auditoría, mejora del agente y aprendizaje del equipo.

Un registro mínimo puede verse así. Es un ejemplo ilustrativo, con valores ficticios:

{
  "incidente": "INC-000123",
  "agente": "triaje-v1.4",
  "modelo": "nombre-y-version-del-modelo",
  "timestamp": "2025-01-08T03:12:44Z",
  "consultas": [
    {"herramienta": "metricas", "servicio": "pagos-api", "ventana": "60m"},
    {"herramienta": "cmdb", "ci": "pagos-api"},
    {"herramienta": "cambios", "ventana": "24h"}
  ],
  "clasificacion": {"categoria": "rendimiento", "impacto": 2, "urgencia": 2},
  "hipotesis": [
    {
      "causa": "Saturación del pool de conexiones a base de datos",
      "evidencia": ["metrica db.pool.en_uso al 100 % desde 03:01",
                    "cambio CHG-000456 aplicado a las 02:55"],
      "confianza": "media"
    }
  ],
  "grupo_sugerido": "Plataforma de pagos",
  "runbook": "RB-PAGOS-07",
  "decision_humana": {"analista": "id-analista", "resultado": "aceptada_con_cambios"}
}

Algunas recomendaciones sobre este registro:

• Guarda la versión del agente, de sus instrucciones y del modelo. Sin eso no puedes explicar por qué el comportamiento cambió.
• Registra la decisión humana como un campo propio. Es la base de la evaluación.
• Almacena el registro fuera del alcance de escritura del agente, con la misma retención que exige tu política para los registros de incidentes.
• Exige que cada hipótesis cite evidencia consultada en esa misma ejecución. Una hipótesis sin evidencia no debería mostrarse al analista.

Cómo evaluar la precisión frente al triaje humano

Antes de que un analista confíe en las sugerencias del agente, necesitas evidencia propia, medida con tus datos. Un método simple es el modo sombra: durante un periodo definido, el agente procesa los mismos incidentes que el equipo, pero sus resultados no se muestran. Al final se comparan.

Métricas útiles para esa comparación:

• Coincidencia de clasificación: porcentaje de incidentes en que categoría y prioridad del agente coinciden con las asignadas por el analista.
• Acierto de enrutamiento: porcentaje en que el grupo sugerido es el que finalmente resolvió el incidente. Es más informativo que comparar con la primera asignación humana, que también se equivoca.
• Acierto de causa probable: se evalúa al cierre, comparando las hipótesis con la causa documentada. Conviene distinguir entre "acertó", "parcialmente" y "no acertó".
• Calidad de la evidencia: en una muestra revisada por un analista experimentado, cuántas evidencias citadas eran reales y pertinentes.
• Abstenciones: cuántas veces el agente dijo "no tengo suficiente información". Un agente que nunca se abstiene es una señal de alerta.

Separa los resultados por tipo de incidente. Es habitual que un agente rinda bien en categorías frecuentes y mal en las raras, y un promedio global esconde esa diferencia. Repite la evaluación cada vez que cambies el modelo, las instrucciones o las herramientas.

Define también, antes de empezar, qué resultado justifica pasar del modo sombra al modo sugerencia. No hay un número universal: depende del costo de una mala asignación en tu operación y de cuánto tiempo dedica hoy el equipo al triaje. Lo importante es que el criterio quede escrito y aprobado por el responsable del servicio antes de ver los resultados, para no ajustarlo a posteriori. Una vez en modo sugerencia, sigue midiendo: la tasa de sugerencias aceptadas sin cambios, la tasa de sugerencias descartadas y, sobre todo, cuántas aceptaciones resultaron erradas al cierre.

Comparte los resultados con el equipo de analistas. Son ellos quienes detectan los patrones de error que una métrica agregada no muestra, y su confianza en la herramienta depende de ver que los errores se reconocen y se corrigen.

Modos de falla y mitigaciones

El modo de falla más delicado es la causa inventada: el agente construye una explicación coherente que no se sostiene en los datos. Es especialmente peligroso porque un analista con prisa puede aceptarla. La tabla resume este y otros modos de falla frecuentes en este tipo de diseño.

Modo de falla	Cómo se manifiesta	Mitigación
Causa inventada	Hipótesis plausible sin respaldo en la telemetría	Exigir evidencia citada y verificable por cada hipótesis; ocultar hipótesis sin evidencia
Correlación tomada como causa	Atribuye el incidente al último cambio solo por cercanía temporal	Pedir que indique qué evidencia descartaría la hipótesis; presentar varias hipótesis
Contexto desactualizado	Enruta a un equipo que ya no es dueño del servicio	Mostrar la fecha de la última actualización del CI; corregir la CMDB como parte del cierre
Exceso de confianza	Confianza alta en incidentes nuevos o raros	Permitir y medir abstenciones; bajar la confianza cuando no hay incidentes similares
Inyección de instrucciones	Texto en logs o tickets que altera el comportamiento del agente	Solo lectura, herramientas acotadas, separar datos de instrucciones
Sesgo de automatización	El analista acepta sin revisar	Mostrar la evidencia junto a la sugerencia; revisar periódicamente aceptaciones que resultaron erradas

Ninguna de estas mitigaciones elimina el riesgo; lo hacen visible y medible. Ese es el objetivo razonable para un primer despliegue.