Agente de IA para operaciones de IT: tickets internos, accesos, monitorización y documentación

El problema

Las operaciones internas de IT nunca se detienen, pero el equipo que las atiende sí. Un análisis de Jitbit sobre unas 1000 empresas, citado con frecuencia en el sector del soporte, situaba en 2017 el volumen medio gestionado por un técnico en 21 tickets al día, con un tiempo de resolución medio de 82 horas. Son datos antiguos, presentados por sus propios autores como una base histórica más que como un objetivo actual, que hay que tomar como un orden de magnitud y no como una cifra actualizada.

Sobre el tiempo dedicado por ticket, Endsight, un proveedor de soporte gestionado, señala 63 minutos de media sobre sus propios 10 923 usuarios seguidos durante 12 meses. Es un dato interno de una sola empresa, no verificado por terceros: hay que considerarlo como un indicio, no como una norma del sector.

El punto documentado más sólido tiene que ver con los accesos. Una investigación de Wing Security recogida por The Hacker News en 2024 estima que el 63 % de las empresas cuenta con exempleados que conservan acceso a datos de la organización, y el 43 % a repositorios de código en GitHub o GitLab. Cada solicitud de acceso o de revocación que se eterniza en una cola de tickets internos es candidata directa a este tipo de estadística.

Este retraso en el tratamiento tiene una segunda consecuencia, menos visible que el riesgo de seguridad: la propia cola de tickets se vuelve ilegible. Cuando las solicitudes urgentes (un acceso bloqueado que impide trabajar) se mezclan con las solicitudes rutinarias (una pregunta ya respondida diez veces en la base de conocimiento), el equipo de IT dedica tanto tiempo a clasificar como a resolver. Buena parte de esa cola nunca debería llegar a una persona: es exactamente el tipo de triaje que un agente que lee la documentación existente puede absorber antes de que el ticket espere su turno.

Qué hace el agente, paso a paso

Un agente de IA autónomo dedicado a las operaciones de IT funciona de forma continua, en su propio entorno aislado, y supervisa la cola de tickets sin dormir nunca.

Empieza categorizando cada ticket entrante en Jira: pregunta ya conocida, solicitud de acceso, incidente técnico. Para las solicitudes ya documentadas, responde directamente citando el procedimiento encontrado en la base de Notion del equipo. Para una solicitud de acceso a una herramienta o un repositorio, abre un ticket estructurado con toda la información necesaria para la decisión, en lugar de ejecutarla él mismo.

En el lado de la monitorización, el agente vigila las alertas notificadas por Datadog y las correlaciona con los commits o despliegues recientes visibles en GitHub: un aumento de latencia que sigue de cerca a un despliegue no se trata como un incidente aislado. Cuando la correlación es clara, abre una issue documentada en GitHub, con el contexto útil para el equipo técnico. Cualquier ticket que quede bloqueado, cualquier alerta crítica o cualquier solicitud de acceso pendiente activa una notificación en Slack hacia el equipo de IT. Cada acción, ticket creado, alerta correlacionada, mensaje enviado, queda registrada en la línea de tiempo del agente, con su estado exacto.

Un ejemplo concreto ilustra bien la mecánica: un empleado abre un ticket un viernes por la noche para pedir acceso a un repositorio de GitHub concreto, en el marco de un proyecto transversal. El agente categoriza la solicitud, verifica que está completa (repositorio objetivo, justificación, duración deseada), y luego prepara un ticket estructurado listo para que un responsable de IT lo valide el lunes por la mañana, en lugar de dejar la solicitud dormida en una cola genérica hasta que alguien la note por casualidad.

Las integraciones utilizadas

Jira sigue siendo la cola de referencia de los tickets internos. El agente busca ahí las solicitudes (search_issues), consulta el detalle (get_issue) y puede crear una nueva issue estructurada, según las acciones cubiertas por su grant.

GitHub sirve para correlacionar una alerta técnica con un cambio de código: lista de commits recientes (list_commits), detalle de una pull request (get_pull_request), y creación de una issue documentada (create_issue) cuando se establece la correlación.

Datadog proporciona la señal bruta de supervisión, que el agente consulta sin sustituir nunca a la propia herramienta de monitorización. Notion aloja los procedimientos y runbooks que el agente consulta antes de responder a una solicitud, y Slack lleva las notificaciones al equipo de IT en tiempo real.

Lo que sigue en manos humanas

El agente prepara y alerta, nunca ejecuta un cambio de acceso o de infraestructura por iniciativa propia. Conceder o revocar efectivamente un acceso sigue siendo una acción humana: el agente abre la solicitud documentada en Jira, una persona de IT la ejecuta y la cierra.

La criticidad real de una alerta ambigua, la que no corresponde a ningún despliegue reciente identificable, la decide una persona antes de cualquier escalada más allá de una notificación en Slack. Decidir y aplicar una corrección de código o de infraestructura sigue siendo, sin sorpresas, trabajo de ingeniería. Y como con cualquier agente de Atako, un administrador debe conceder y ajustar los grants sobre Jira, GitHub y Datadog, acción por acción, con un alcance de lectura o de lectura y escritura definido explícitamente.

Este límite también rige para el propio agente: si se encuentra con una situación que queda fuera de lo que cubre su contexto de negocio, una renovación de licencia inusual, una solicitud de acceso a un sistema no documentado, no fuerza una respuesta aproximada. Notifica al equipo de IT y deja el ticket abierto para un tratamiento humano, en lugar de adivinar un procedimiento que no existe en su base de conocimiento.

Resultado medible

El beneficio más directo es la reducción del tiempo muerto entre la llegada de un ticket o una alerta y su primera atención. Un agente que funciona las 24 horas del día puede categorizar un ticket abierto un domingo por la noche y preparar la solicitud de acceso correspondiente antes de que el equipo llegue el lunes, en lugar de dejar la solicitud esperando en la cola.

El segundo beneficio afecta directamente al problema documentado por Wing Security: al sistematizar la apertura de un ticket de revocación en cuanto se notifica una salida, el agente reduce el plazo entre el evento disparador y la acción de IT, lo que limita la ventana durante la cual un acceso permanece activo innecesariamente, una ventana que, sin supervisión continua, puede extenderse semanas o incluso meses según las constataciones citadas más arriba.

Cada ticket abierto, cada alerta correlacionada, cada mensaje enviado sigue siendo consultable en el audit trail de Atako, exportable en CSV para el equipo de IT hasta 50 000 líneas. Esta trazabilidad completa también facilita las auditorías de seguridad internas: encontrar quién solicitó un acceso, cuándo, y sobre qué base se formalizó la solicitud ya no exige reconstruir una cronología a partir de varias herramientas distintas.

Un agente de IT se incluye en el plan Standard, 20 euros al mes por slot, con 1000 créditos incluidos cada mes para cubrir las llamadas al modelo. El número de tickets tratados o de colaboradores que interactúan con el agente no tiene ningún impacto en este precio, solo cuenta el número de agentes activos simultáneamente. Un equipo de IT reducido puede así hacer funcionar un solo agente sobre el conjunto de sus tickets internos, sus alertas de monitorización y sus solicitudes de acceso, sin tener que multiplicar los slots para cubrir cada flujo por separado, lo que mantiene el costo previsible incluso cuando el alcance del agente se amplía progresivamente a nuevas herramientas o nuevos equipos internos a lo largo de los meses.