Agente de IA para operações de TI: tickets internos, acessos, monitoramento e documentação

O problema

As operações de TI internas nunca param, mas a equipe que cuida delas para. Uma análise da Jitbit sobre cerca de 1.000 empresas, regularmente citada no setor de suporte, situava em 2017 o volume médio gerenciado por um técnico em 21 tickets por dia, com um tempo médio de resolução de 82 horas. São dados antigos, apresentados pelos próprios autores como uma base histórica e não como uma meta atual, a serem tratados como uma ordem de grandeza, não como um número atualizado.

Sobre o tempo gasto por ticket, a Endsight, uma prestadora de suporte gerenciado, aponta 63 minutos em média sobre seus próprios 10.923 usuários acompanhados durante 12 meses. É um dado interno de uma única empresa, não verificado por terceiros: a ser considerado como um indício, não como um padrão do setor.

O ponto mais bem documentado envolve os acessos. Uma pesquisa da Wing Security divulgada pelo The Hacker News em 2024 estima que 63% das empresas têm ex-colaboradores que mantêm acesso a dados da organização, e 43% a repositórios de código no GitHub ou GitLab. Toda solicitação de acesso ou de revogação que se arrasta em uma fila de tickets internos é uma candidata direta a esse tipo de estatística.

Esse atraso no tratamento tem uma segunda consequência, menos visível que o risco de segurança: a própria fila de tickets fica ilegível. Quando as solicitações urgentes (um acesso bloqueado que impede alguém de trabalhar) se misturam às solicitações rotineiras (uma pergunta já respondida dez vezes na base de conhecimento), a equipe de TI gasta tanto tempo triando quanto resolvendo. Boa parte dessa fila nunca deveria chegar a um humano: é exatamente o tipo de triagem que um agente que lê a documentação existente consegue absorver antes que o ticket espere sua vez.

O que o agente faz, passo a passo

Um agente de IA autônomo dedicado às operações de TI roda continuamente, em seu próprio ambiente isolado, e monitora a fila de tickets sem nunca dormir.

Ele começa categorizando cada ticket recebido no Jira: pergunta já conhecida, solicitação de acesso, incidente técnico. Para as solicitações já documentadas, responde diretamente citando o procedimento encontrado na base do Notion da equipe. Para uma solicitação de acesso a uma ferramenta ou repositório, abre um ticket estruturado com todas as informações necessárias para a decisão, em vez de executá-la sozinho.

No lado do monitoramento, o agente acompanha os alertas gerados pelo Datadog e os correlaciona com os commits ou implantações recentes visíveis no GitHub: um aumento de latência logo após uma implantação não é tratado como um incidente isolado. Quando a correlação é clara, ele abre uma issue documentada no GitHub, com o contexto útil para a equipe técnica. Qualquer ticket que fique bloqueado, alerta crítico ou solicitação de acesso pendente dispara uma notificação no Slack para a equipe de TI. Cada ação, ticket criado, alerta correlacionado, mensagem enviada, fica registrada na linha do tempo do agente, com seu status exato.

Um exemplo concreto ilustra bem a mecânica: um colaborador abre um ticket numa sexta à noite pedindo acesso a um repositório específico do GitHub, no contexto de um projeto transversal. O agente categoriza a solicitação, verifica se ela está completa (repositório visado, justificativa, duração desejada) e prepara um ticket estruturado pronto para ser validado por um responsável de TI já na segunda de manhã, em vez de deixar a solicitação dormindo em uma fila genérica até que alguém a note por acaso.

As integrações mobilizadas

O Jira continua sendo a fila de referência dos tickets internos. O agente busca ali as solicitações (search_issues), consulta o detalhe (get_issue) e pode criar uma nova issue estruturada, conforme as ações cobertas pelo seu grant.

O GitHub serve para correlacionar um alerta técnico com uma mudança de código: lista dos commits recentes (list_commits), detalhe de uma pull request (get_pull_request), e criação de uma issue documentada (create_issue) quando a correlação é estabelecida.

O Datadog fornece o sinal bruto de supervisão, que o agente consulta sem nunca substituir a própria ferramenta de monitoramento. O Notion hospeda os procedimentos e runbooks que o agente consulta antes de responder a uma solicitação, e o Slack carrega as notificações para a equipe de TI em tempo real.

O que continua com o humano

O agente prepara e alerta, ele nunca executa uma mudança de acesso ou de infraestrutura por conta própria. Conceder ou revogar um acesso de fato continua sendo uma ação humana: o agente abre a solicitação documentada no Jira, alguém da TI a executa e a encerra.

A criticidade real de um alerta ambíguo, aquele que não corresponde a nenhuma implantação recente identificável, é decidida por um humano antes de qualquer escalonamento além de uma notificação no Slack. Decidir e aplicar uma correção de código ou de infraestrutura continua sendo, sem surpresa, trabalho de engenheiro. E, como em qualquer agente Atako, um admin precisa conceder e ajustar os grants no Jira, no GitHub e no Datadog, ação por ação, com um escopo de leitura ou de leitura e escrita definido explicitamente.

Esse limite também vale para o próprio agente: se ele encontra uma situação fora do que seu contexto de negócio cobre, uma renovação de licença incomum, uma solicitação de acesso a um sistema não documentado, ele não força uma resposta aproximada. Notifica a equipe de TI e deixa o ticket aberto para tratamento humano, em vez de adivinhar um procedimento que não existe em sua base de conhecimento.

Resultado mensurável

O benefício mais direto é a redução do tempo morto entre a chegada de um ticket ou alerta e sua primeira tomada em conta. Um agente que roda 24 horas por dia pode categorizar um ticket aberto num domingo à noite e preparar a solicitação de acesso correspondente antes da chegada da equipe na segunda, em vez de deixar a solicitação esperando na fila.

O segundo benefício toca diretamente o problema documentado pela Wing Security: ao sistematizar a abertura de um ticket de revogação assim que uma saída é sinalizada, o agente reduz o intervalo entre o evento que dispara a ação e a resposta da TI, o que limita a janela em que um acesso permanece ativo sem necessidade, uma janela que, sem monitoramento contínuo, pode se estender por semanas ou até meses conforme os dados citados acima.

Cada ticket aberto, cada alerta correlacionado, cada mensagem enviada continua consultável no audit trail da Atako, exportável em CSV para a equipe de TI até 50.000 linhas. Essa rastreabilidade completa também facilita as auditorias de segurança internas: descobrir quem pediu um acesso, quando, e com base em que a solicitação foi formalizada não exige mais reconstituir uma cronologia a partir de várias ferramentas diferentes.

Um agente de TI se encaixa no plano Standard, 20 euros por mês por slot, com 1.000 créditos incluídos a cada mês para cobrir as chamadas ao modelo. O número de tickets tratados ou de colaboradores que interagem com o agente não tem nenhum impacto nesse preço, só o número de agentes ativos simultaneamente conta. Uma equipe de TI reduzida pode assim rodar um único agente sobre o conjunto de seus tickets internos, seus alertas de monitoramento e suas solicitações de acesso, sem precisar multiplicar os slots para cobrir cada fluxo separadamente, o que mantém o custo previsível mesmo quando o escopo do agente se amplia progressivamente para novas ferramentas ou novas equipes internas ao longo dos meses.