Agentes de IA en la operación de TI: dónde funcionan hoy

Qué es un agente de IA, en qué tareas de operación aporta valor hoy, dónde sigue siendo riesgoso y qué necesitas tener listo antes de ponerlo a trabajar.

La palabra "agente" se usa hoy para casi todo: desde un chatbot con acceso a un buscador hasta un sistema que ejecuta cambios en producción sin intervención humana. Para un equipo de operación de TI esa ambigüedad es un problema, porque la pregunta útil no es si los agentes son el futuro, sino en qué tareas concretas ayudan ya, con qué controles y con qué datos. Este artículo propone una respuesta práctica.

Qué es un agente y en qué se diferencia de un script o un chatbot

Un agente de IA combina cuatro elementos:

Modelo: un modelo de lenguaje que interpreta la situación, razona sobre ella y decide el siguiente paso.
Herramientas: funciones o API que el agente puede invocar, por ejemplo consultar métricas, leer un ticket, buscar en la CMDB o abrir una solicitud de cambio.
Memoria: el contexto que conserva durante la tarea (lo que ya consultó, lo que descartó) y, a veces, información persistente entre tareas, como runbooks o decisiones anteriores.
Objetivo: una meta acotada ("clasifica esta alerta y propone a quién asignarla"), no una instrucción paso a paso.

La diferencia con un script es que el script sigue una ruta fija: si la condición A se cumple, ejecuta B. Es predecible, barato y auditable, y por eso sigue siendo la opción correcta para todo proceso estable y bien definido. Un agente decide la ruta en tiempo de ejecución, lo que le permite manejar variaciones que nadie programó, pero también lo hace menos predecible.

La diferencia con un chatbot es la acción. Un chatbot responde preguntas con lo que sabe o con lo que le pegas en la conversación. Un agente consulta sistemas reales, encadena varias consultas y produce un resultado sobre el que alguien puede actuar. Esa capacidad de actuar es justamente lo que obliga a pensar en permisos, trazabilidad y límites.

Una regla útil: si puedes escribir el proceso como un diagrama de flujo sin ramas ambiguas, automatízalo con un script o con una herramienta como Ansible. Reserva los agentes para tareas donde el trabajo consiste en leer señales dispersas, interpretar y resumir.

Dónde aportan valor hoy

Las tareas donde un agente rinde mejor comparten un patrón: mucho dato que leer, un resultado que una persona puede revisar rápido y un costo de error bajo o contenible. En operación de TI, eso describe varias áreas.

Monitoreo con contexto

Un agente puede revisar una anomalía, consultar métricas, logs y trazas relacionadas, cruzarlas con los cambios recientes y entregar al centro de comando un resumen legible. No reemplaza a la plataforma de observabilidad; trabaja sobre sus datos. Es un tema que merece un análisis propio.

Triaje de incidentes

Enriquecer una alerta con telemetría y datos de la CMDB, proponer una clasificación, una causa probable y un grupo resolutor. Es trabajo repetitivo, consume tiempo de analistas experimentados y el resultado es fácil de validar. Es uno de los casos de uso que más conviene diseñar con detalle.

Rightsizing

Revisar el uso real de cómputo, memoria y almacenamiento frente a lo asignado, y proponer ajustes con su justificación. El agente analiza y recomienda; el cambio pasa por el proceso normal de habilitación de cambios.

Arquitectura y documentación

Leer configuraciones, repositorios e inventarios para generar o actualizar diagramas, fichas de servicio y runbooks. La documentación es una de las deudas más comunes en operación, y un agente puede detectar cuándo lo documentado ya no coincide con lo desplegado. La revisión humana sigue siendo necesaria antes de publicar.

Otras tareas de apoyo

Preparar el borrador de un informe posincidente a partir de la línea de tiempo del ticket, revisar una solicitud de cambio para detectar campos incompletos o dependencias no declaradas, o responder preguntas del equipo sobre la base de conocimiento interna citando la fuente.

Dónde siguen siendo riesgosos

Los modelos de lenguaje pueden producir respuestas plausibles e incorrectas, y lo hacen con el mismo tono de seguridad que cuando aciertan. Eso define dónde no conviene darles autonomía:

Cambios en producción sin aprobación. Reiniciar servicios, modificar reglas de firewall o escalar infraestructura de forma autónoma exige un nivel de confianza que pocas organizaciones pueden demostrar hoy con evidencia.
Acciones de seguridad irreversibles. Bloquear cuentas, aislar equipos o borrar datos puede tener un impacto mayor que el incidente original si la causa estaba mal identificada.
Incidentes nuevos o poco frecuentes. Cuando no hay historial ni runbook, el agente tiende a forzar la situación hacia patrones conocidos.
Decisiones con impacto regulatorio o sobre clientes. En banca, seguros y salud, la responsabilidad sobre esas decisiones debe quedar en personas identificables.
Datos sensibles sin gobierno. Si el agente lee logs con datos personales o financieros y los envía a un modelo externo, el problema deja de ser técnico y pasa a ser de cumplimiento.

Además, los agentes tienen superficies de ataque propias. La inyección de instrucciones (un texto malicioso dentro de un ticket o un log que el agente interpreta como orden) y los permisos excesivos son dos de los riesgos que el OWASP Top 10 para aplicaciones con LLM describe de forma explícita.

Tarea, valor y riesgo

La siguiente tabla resume un punto de partida razonable. El riesgo se refiere al uso en modo recomendación, con una persona aprobando la acción.

Tarea	Valor esperado	Riesgo principal	Modo recomendado al inicio
Resumen de anomalías para el centro de comando	Menos tiempo de lectura de paneles y logs	Resumen incompleto o sesgado	Solo lectura
Triaje y enrutamiento de incidentes	Asignación más rápida y consistente	Causa probable inventada, asignación errónea	Solo lectura, sugerencia al analista
Rightsizing de recursos	Menor gasto en capacidad ociosa	Subdimensionar un servicio con picos estacionales	Recomendación con aprobación
Documentación y diagramas	Documentación al día con lo desplegado	Errores publicados como verdad	Borrador con revisión
Revisión de solicitudes de cambio	Menos cambios rechazados por información incompleta	Falsa sensación de revisión completa	Comentarios al solicitante
Remediación automática en producción	Menor tiempo de recuperación en fallas conocidas	Acción equivocada a escala	Solo después de evidencia sostenida y con runbook acotado

El paso de "recomienda" a "ejecuta" debería ser una decisión explícita por tipo de tarea, no una consecuencia de que la herramienta lo permita. Esa decisión conviene tomarla con una escala explícita de niveles de autonomía, acordada con las áreas de riesgo y cumplimiento.

Requisitos previos

Un agente no compensa una operación desordenada; la amplifica. Antes de ponerlo a trabajar, revisa estos puntos:

Datos de observabilidad confiables. Métricas, logs y trazas con nombres consistentes, identificadores de correlación y retención suficiente. Si tus equipos no pueden reconstruir un incidente con los datos disponibles, el agente tampoco podrá. OpenTelemetry es un buen punto de partida para estandarizar la instrumentación.
Inventario y CMDB razonablemente actualizados. El agente necesita saber qué servicio depende de qué componente y quién es el dueño. Una CMDB desactualizada produce enrutamientos errados con mucha confianza.
Runbooks escritos. Son la referencia contra la que el agente propone acciones y contra la que tú evalúas sus propuestas. Si el conocimiento vive solo en la cabeza de dos personas, empieza por ahí.
API y herramientas expuestas de forma controlada. Cada herramienta que el agente puede invocar debe tener un propósito claro, validación de parámetros y registro de uso.
Permisos de mínimo privilegio. Cuentas de servicio dedicadas, con acceso de solo lectura al inicio y separadas de las cuentas humanas. Así cada acción del agente queda atribuida y revocable.
Trazabilidad. Registra qué datos consultó el agente, qué concluyó, qué recomendó y qué decidió la persona. Sin ese registro no puedes auditar ni mejorar.
Criterio de evaluación. Define antes de empezar cómo medirás si el agente acierta, por ejemplo comparando sus clasificaciones con las de los analistas durante un periodo de prueba.

Cómo empezar sin apostar la operación

Un camino prudente consiste en elegir una sola tarea con mucho volumen y bajo costo de error, típicamente el resumen de alertas o el triaje inicial. Despliega el agente en modo sombra: trabaja en paralelo con el equipo, sus resultados se registran pero no se usan. Compara durante algunas semanas. Si la precisión es aceptable y los errores son comprensibles, pasa a modo sugerencia, donde el analista ve la propuesta y decide. Solo después, y para casos acotados, considera acciones automáticas.

Para priorizar qué tareas abordar primero sirve el mismo criterio que usamos con cualquier automatización: valor frente a complejidad. Una tarea de alto valor y baja complejidad (pocos sistemas, datos disponibles, bajo riesgo de cambio) es una victoria rápida. Una de alto valor y alta complejidad conviene dividirla en entregas menores.

Por último, recuerda que el objetivo no es retirar personas del proceso. Es quitarles trabajo de lectura y clasificación para que dediquen su criterio a lo que lo necesita: incidentes nuevos, decisiones de riesgo y mejora del servicio.