Agentes de IA para operações de TI: incidentes, mudanças e limites

Agentes de IA para operações de TI funcionam melhor como um engenheiro júnior cuidadoso, com memória perfeita. Eles leem dados de monitoramento, seguem seus runbooks, redigem resumos de incidentes e preparam mudanças, enquanto pessoas aprovam qualquer coisa que altere um sistema em produção. O caminho seguro é começar com acesso somente leitura, escrever os runbooks como passos explícitos e levar toda mudança pelas regras de aprovação em que você já confia. A capacidade cresce então uma permissão por vez, conforme o histórico do agente justificar.

Principais pontos

• Um agente de operações de TI gera valor primeiro ao ler e explicar, não ao agir. Triagem, correlação e passagens de bastão claras vêm antes de qualquer acesso de escrita.
• O runbook é a descrição de cargo do agente. Se um passo não pode ser escrito de forma simples, ele ainda não está pronto para ser delegado.
• A aprovação de mudanças deve depender da reversibilidade e do alcance do impacto, não da confiança com que o agente se expressa.
• Cada nova permissão deve ser concedida de forma deliberada, testada contra incidentes passados e removível sem drama.
• Logs, tickets e textos de alerta são entrada não confiável. Projete o agente para que um texto que ele lê nunca se torne uma autoridade que ele exerce.

O que um agente de IA realmente consegue fazer em operações de TI?

Operações de TI são um ciclo de quatro atividades: observar, decidir, executar e registrar. As pessoas são boas em decidir, mas costumam estar sobrecarregadas no resto. Um agente pode assumir boa parte da observação e do registro, e uma parcela controlada da execução.

Na prática, isso significa algumas tarefas bem delimitadas:

• Ler alertas assim que chegam, agrupar os relacionados e anexar o contexto que o engenheiro de plantão teria de reunir manualmente.
• Encontrar o runbook certo para um sintoma e percorrer seus passos de diagnóstico com ferramentas somente leitura.
• Manter a linha do tempo do incidente e redigir atualizações de status para as partes interessadas, em linguagem clara.
• Preparar solicitações de mudança com motivo, passos, plano de rollback e sistemas afetados já preenchidos.
• Escrever as notas pós-incidente enquanto os detalhes estão frescos, indicando quais passos do runbook faltaram ou estavam errados.
• Verificar, de forma agendada, desvios de configuração, certificados prestes a expirar, contas esquecidas e permissões sem revisão.

Isso é diferente de um assistente de chat que responde perguntas sobre TI. Um agente de operações tem identidade própria, memória do seu ambiente e um conjunto definido de ferramentas, e trabalha de forma recorrente. O problema vizinho, as solicitações dos colaboradores ao helpdesk de TI (tickets, acessos e runbooks), tem muitos dos mesmos limites que valem aqui.

Por que a primeira versão deve ser somente leitura?

A maior parte do valor na resposta a incidentes está no primeiro trecho: entender o que está acontecendo. Os dados de observabilidade (logs, métricas e traces, como descreve o material introdutório do OpenTelemetry) já guardam as evidências. Um agente que consulta esses dados, compara com as mudanças recentes e resume o quadro encurta esse trecho sem tocar em nenhum sistema.

O acesso somente leitura também limita o que pode dar errado. Se o agente interpretar mal um sinal, o custo é um resumo ruim que uma pessoa corrige. Se interpretar mal um sinal tendo acesso de escrita, o custo é um segundo incidente.

A orientação de autorização da OWASP aponta na mesma direção: negar por padrão, conceder o menor privilégio necessário e verificar as permissões a cada requisição, em vez de presumi-las. Para um agente, isso se traduz em uma lista curta de configuração:

• Dê ao agente uma identidade de serviço própria, nunca uma conta de administrador compartilhada nem as credenciais de uma pessoa.
• Limite o acesso de leitura aos sistemas citados nos runbooks, não ao ambiente inteiro.
• Mantenha segredos fora do que o agente pode ler e mascare campos sensíveis nos logs sempre que possível.
• Registre cada consulta feita pelo agente, para que os revisores vejam o que ele examinou.
• Garanta que as credenciais possam ser revogadas em um único passo por um responsável nomeado.

Há também uma razão de segurança. Textos de alerta, corpos de tickets e linhas de log podem conter instruções escritas por alguém que não é você. A orientação da OWASP sobre prompt injection trata todo esse conteúdo como não confiável. Um agente somente leitura que trata o que lê como dado, e nunca como comando, tem muito menos a perder se um texto hostil entrar em um log.

Como transformar runbooks em algo que um agente consiga seguir?

A maioria das equipes já tem runbooks, mas eles são escritos para um colega que compartilha o contexto. Dizem reinicie o serviço quando travar, e confiam que o leitor saiba qual serviço, qual servidor e como é um travamento. O agente precisa que esse contexto seja explícito, e o exercício melhora o runbook também para as pessoas.

Um plano prático para cada runbook:

• Primeiro, escolha um tipo de incidente recorrente com sintoma claro, como uma fila acumulada ou um certificado prestes a expirar.
• Segundo, escreva o gatilho em termos observáveis: qual sinal, qual limite, qual sistema.
• Terceiro, liste os passos de diagnóstico em ordem e marque cada um como somente leitura ou como mudança.
• Quarto, indique o resultado esperado de cada passo, para que o agente saiba se ele funcionou.
• Quinto, defina as condições de parada: quando o agente deve escalar em vez de continuar, e para quem.
• Sexto, anexe o rollback de cada passo de mudança, mesmo que o rollback seja não fazer nada.
• Sétimo, reproduza o runbook em dois ou três incidentes passados e veja onde a leitura do agente difere do que os responsáveis fizeram.

O passo de reprodução é o mais importante. As diferenças aparecem como contexto ausente, redação ambígua ou passos que os responsáveis faziam por hábito e nunca registraram. A memória do agente passa a guardar a versão corrigida, e o runbook vira um documento vivo, com um responsável, e não um arquivo que ninguém abre. O texto da Anthropic sobre como construir agentes eficazes faz um ponto parecido: fluxos simples e bem definidos, com pontos de verificação claros, tendem a superar a autonomia aberta.

Como a aprovação de mudanças deve funcionar quando há um agente envolvido?

A gestão de mudanças existe porque mudanças bem-intencionadas causam indisponibilidades. Um agente não faz esse risco desaparecer, e pode fazer mudanças acontecerem mais rápido do que alguém percebe. Por isso, a regra de aprovação não deve depender de quem propõe a mudança. Deve depender do que a mudança pode causar.

Um guia simples de decisão, organizado por reversibilidade e alcance do impacto:

• O agente pode agir sozinho apenas em ações restritas, reversíveis e pré-aprovadas, com rollback testado, como limpar um cache conhecido ou reexecutar um job que falhou em um sistema não crítico.
• O agente redige e uma pessoa nomeada aprova, nas mudanças que tocam a produção mas estão cobertas por um runbook, como reiniciar um pool de workers ou renovar um certificado.
• Uma pessoa conduz e o agente auxilia, nas mudanças que alteram dados, acessos, rede ou qualquer coisa voltada ao cliente, com o agente preparando o plano e conferindo o resultado.
• Nenhuma execução pelo agente em ações destrutivas ou irreversíveis, como apagar dados ou alterar fronteiras de segurança, até que a sua própria política diga o contrário.

Em qualquer nível, cada registro de mudança deve trazer os mesmos fatos: o que vai mudar, por quê, quem aprovou, o rollback e a verificação que comprova que funcionou. O agente pode preparar tudo isso e, depois da mudança, executar a verificação e anexar o resultado. Quando uma ação pode ser repetida após um timeout, projete-a para ser segura de repetir, de modo que uma segunda tentativa não aplique a mudança duas vezes.

As aprovações também devem expirar. Um sim dado a uma mudança em um momento não é uma permissão permanente, e o agente não deve tratá-lo como tal.

Como isso funciona na prática? Um cenário ilustrativo

Cenário ilustrativo: uma empresa de médio porte opera um serviço de processamento de pedidos, e a fila de mensagens começa a acumular fora do horário comercial. O agente percebe o acúmulo crescente pelo acesso de monitoramento somente leitura e identifica que o sintoma corresponde a um runbook para workers travados.

Ele percorre os passos de diagnóstico. Verifica a saúde dos workers, compara o início do acúmulo com a implantação mais recente e não encontra mudança relacionada. Vê que dois workers pararam de reportar ao mesmo tempo e escreve um resumo curto para o engenheiro de plantão: o que observou, qual runbook se aplica e o que recomenda.

O próximo passo do runbook é reiniciar o pool de workers, que é uma mudança em produção. O agente não a executa. Envia ao engenheiro de plantão um rascunho de mudança com o motivo, o passo único, o rollback e a verificação que fará depois. O engenheiro lê as evidências, aprova aquele único passo, e o agente o executa e confirma que a fila está sendo drenada.

O que o agente não fez é tão importante quanto o que fez. Durante a leitura, ele notou que a carga do banco de dados estava um pouco elevada. Escalar o banco não está no runbook, então ele registrou isso como observação para a manhã seguinte e não tomou nenhuma ação. Depois escreveu a linha do tempo do incidente e apontou que o runbook não tinha um passo para checar os heartbeats dos workers. Uma pessoa revisou a inclusão proposta no dia seguinte.

Como um agente ganha capacidade sem ficar mais arriscado?

A resposta é tratar a capacidade como uma escada, não como um interruptor. Cada degrau acrescenta uma coisa, e o agente permanece nele até que o histórico sustente o próximo.

• Observar: acesso somente leitura, resumos e linhas do tempo, revisados por pessoas.
• Recomendar: propõe o runbook e o próximo passo, com evidências anexadas.
• Preparar: redige solicitações de mudança completas, planos de rollback e verificações.
• Agir com aprovação: executa um único passo aprovado e o verifica.
• Agir dentro de uma classe restrita: trata sozinho um pequeno conjunto de ações reversíveis, com revisão posterior.

Um agente deve conquistar cada nova permissão como um engenheiro novo: mostrando primeiro o seu trabalho.

Subir de degrau deve se apoiar em evidências. Reproduza incidentes passados, faça avaliações recorrentes que comparem as ações do agente com o que um responsável cuidadoso faria e revise onde ele escalou, onde ficou em silêncio e onde errou. A orientação da Anthropic sobre avaliações (evals) de agentes descreve em detalhe esse tipo de teste repetível. Descer de degrau deve ser igualmente fácil: se uma integração muda, um runbook é revisado ou ocorre um erro, o agente volta um degrau até que a causa seja compreendida.

Essa escada também orienta como ampliar o escopo no restante da empresa. Equipes que já usam agentes em desenvolvimento, revisão e operação de software ou em trabalho operacional recorrente e relatórios podem aplicar os mesmos degraus, com permissões revisadas por função e não por entusiasmo.

Como a Be Human trata agentes de IA para operações de TI?

A Be Human projeta, implementa e opera infraestrutura de IA personalizada, e um agente de operações de TI começa como todo projeto: uma função útil, a memória e as ferramentas de que ela precisa, limites de aprovação e um critério de sucesso que você consiga observar. Para essa função, isso normalmente significa acesso de monitoramento somente leitura, um pequeno conjunto de runbooks e um caminho de aprovação definido para cada tipo de mudança. A operação gerenciada pode incluir monitoramento do próprio agente, avaliações recorrentes, manutenção das integrações, revisão de permissões, resposta a incidentes e melhorias controladas, de modo que o acesso do agente só mude quando alguém tiver decidido que deve mudar.

Se você está avaliando por onde um agente poderia ajudar primeiro a sua equipe de TI, faça o diagnóstico gratuito de IA da Be Human para encontrar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

Um agente de IA vai substituir nossos engenheiros de plantão? Não. O agente assume a coleta de contexto, a redação de atualizações e o cumprimento de passos documentados, enquanto as pessoas mantêm o julgamento, a aprovação e a responsabilidade. O efeito prático é que o engenheiro de plantão começa cada incidente com as evidências já reunidas.

Precisamos de um monitoramento maduro antes de começar? Você precisa de visibilidade suficiente para que uma pessoa conseguisse diagnosticar os tipos de incidente escolhidos primeiro. Se os sinais estão espalhados ou os runbooks são frágeis, a primeira etapa do trabalho é melhorá-los, o que beneficia sua equipe com ou sem agente. Comece por um tipo de incidente em que os dados e os passos já estejam razoavelmente claros.

Como proteger um agente de instruções escondidas em logs ou tickets? Trate tudo o que o agente lê como dado, nunca como instrução, e mantenha as permissões dele restritas o bastante para que uma leitura manipulada não cause dano. Acesso somente leitura, aprovação para mudanças e um registro completo do que ele consultou e propôs limitam o prejuízo. As orientações da OWASP sobre prompt injection e sobre aplicações com LLMs são uma boa referência para a sua revisão de segurança.

O que medir para saber se o agente está funcionando? Escolha um critério observável, como se os responsáveis recebem um resumo correto e o runbook certo no início de um incidente, ou se as solicitações de mudança chegam completas. Revise com regularidade as escaladas e os erros do agente, junto com os acertos. Amplie as permissões dele somente quando esse histórico sustentar a decisão.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.