Agentes de IA para help desk de TI: chamados, acessos e runbooks

Um agente de IA para help desk de TI lê o chamado recebido, encontra o runbook correspondente, executa os passos seguros que tem permissão para executar e então fecha o chamado ou o entrega a uma pessoa com o trabalho já documentado. Ele rende mais em pedidos rotineiros, como redefinição de senha, dúvidas sobre software e etapas padrão de onboarding. Ele não deve aprovar o próprio acesso nem conceder direitos privilegiados, e por isso a pergunta central do projeto é onde termina a autoridade do agente.

Principais pontos

• Comece pelos chamados que já têm uma correção escrita e repetível. Se um técnico humano não consegue seguir o runbook, o agente também não consegue.
• Separe o que o agente pode ler, o que pode alterar e o que só pode solicitar. A maior parte do risco está no segundo e no terceiro grupo.
• Mudanças de acesso que ampliam privilégios, tocam dados sensíveis ou são difíceis de desfazer devem sempre ir para um aprovador humano identificado.
• Toda ação precisa de um registro que mostre o chamado, a versão do runbook, a chamada de ferramenta e o resultado, para que um revisor consiga reconstituir o que aconteceu.
• Trate o texto dos chamados, e-mails e anexos como entrada não confiável. São dados para o agente ler, nunca instruções para ele obedecer.

O que um agente de IA para help desk de TI realmente faz?

Um agente de help desk não é uma janela de chat que responde perguntas sobre TI. É um trabalhador com função definida: ele pega um chamado da fila, decide que tipo de pedido é, consulta o procedimento que sua equipe já aprovou e executa os passos que as permissões dele permitem.

Na prática, essa função tem quatro partes. Ele faz a triagem: classifica o chamado, verifica se o solicitante é quem diz ser e percebe duplicidades ou incidentes relacionados. Ele resolve: segue um runbook usando ferramentas como o provedor de identidade, o sistema de gestão de dispositivos ou a plataforma de chamados. Ele escala: passa o chamado a uma pessoa, com um resumo claro, quando o runbook não se aplica ou a ação exige aprovação. E ele registra: deixa um rastro que alguém possa auditar.

A diferença em relação a uma automação com script está no julgamento nas bordas. Um script redefine a senha quando é pedido. Um agente percebe que o pedido veio por um canal incomum, que a conta foi sinalizada recentemente ou que o usuário também menciona um celular perdido, e muda de conduta. Esse julgamento é justamente o motivo de os limites precisarem ser explícitos. Quanto mais flexível o leitor, mais precisamente é preciso definir o que ele pode fazer.

Se você está mapeando o trabalho antes de escolher ferramentas, vale lembrar que um agente de help desk herda toda a ambiguidade que o seu processo atual já tem. Mapeie o fluxo real dos chamados antes de automatizar qualquer etapa.

Quais chamados um agente consegue resolver com runbooks?

Os melhores candidatos têm três traços em comum: o pedido é frequente, a correção é sempre a mesma e o pior resultado de um erro é pequeno e reversível. Muitos help desks percebem que uma parte grande da fila se encaixa nessa descrição, embora a sua mistura dependa das suas ferramentas e dos seus usuários.

Candidatos típicos incluem:

• Redefinição de senha e novo cadastro de autenticação multifator, depois de uma verificação de identidade que a sua política já define.
• Desbloqueio de conta e diagnóstico de problemas de login por causas comuns.
• Dúvidas sobre caixa compartilhada, lista de distribuição e agenda que seguem um padrão.
• Pedidos de software de um catálogo pré-aprovado.
• Problemas de impressora, VPN e Wi-Fi em que o runbook é uma sequência de verificações.
• Checklists de entrada e saída de colaboradores, em que o agente prepara os passos e uma pessoa aprova o acesso.
• Perguntas de status, como em que etapa está o pedido de um notebook, respondidas a partir do histórico do chamado.

Os chamados que devem ficar com pessoas, pelo menos no início, incluem suspeitas de incidente de segurança, qualquer coisa que envolva diretoria ou sistemas financeiros, falhas de hardware que pedem decisão física e pedidos que não correspondem a nenhum runbook. O agente deve reconhecer esses casos rápido e entregá-los, sem tentar uma solução criativa.

Um teste útil é perguntar se um técnico novo, na primeira semana e apenas com o runbook escrito, resolveria o chamado corretamente. Se sim, aquele tipo de chamado é candidato. Se a resposta depende de alguém lembrar de uma exceção, documente a exceção primeiro.

Como escrever um runbook que um agente consiga seguir?

A maioria dos runbooks foi escrita para humanos que preenchem lacunas com experiência. O agente precisa que as lacunas estejam preenchidas. A boa notícia é que as mesmas edições melhoram o runbook para quem está chegando na equipe. Um jeito prático de preparar cada um:

• Nomeie o gatilho: a que tipo de chamado ou pedido o runbook se aplica e quais casos parecidos ficam de fora.
• Liste as pré-condições: o que precisa ser verdade antes de qualquer passo, como identidade verificada, cadastro de colaborador correspondente ou confirmação do gestor.
• Escreva os passos como ações únicas, cada uma ligada a uma ferramenta e a um resultado esperado, para que o agente confira se o passo funcionou.
• Declare as condições de parada: quais observações obrigam o agente a parar e escalar, por exemplo uma conta bloqueada com tentativas recentes de login falhas vindas de locais incomuns.
• Marque cada passo como leitura, alteração ou solicitação. Leituras podem ser executadas livremente, alterações exigem uma permissão concedida e solicitações geram uma tarefa de aprovação para uma pessoa.
• Defina a mensagem de encerramento: o que o agente escreve de volta ao solicitante e ao chamado, em linguagem simples.
• Inclua um responsável e uma data de revisão, para que instruções desatualizadas não induzam o agente a erro sem ninguém notar. O texto sobre engenharia de contexto para agentes de negócio explica por que isso importa mais do que a maioria das equipes imagina.

Mantenha cada runbook curto o bastante para ser lido de uma vez. Procedimentos longos que cobrem muitos casos tendem a esconder as condições de parada. Dividi-los em runbooks pequenos, com gatilhos claros, facilita o teste e a aposentadoria quando suas ferramentas mudarem.

Quais mudanças de acesso ainda precisam de aprovação humana?

Acesso é onde um agente de help desk pode fazer mais bem e mais estrago, então merece um conjunto claro de regras. Um princípio útil vem de guias de autorização consagrados, como o OWASP Authorization Cheat Sheet: conceder o mínimo de permissões necessário, negar por padrão e verificar a autorização a cada requisição, não só uma vez no início.

Aplique isso ao agente de duas formas. Primeiro, dê à identidade de serviço do próprio agente apenas as permissões que os runbooks exigem. Segundo, decida para cada tipo de pedido se o agente pode agir, pode preparar ou deve pedir.

Um guia de decisão que você pode adaptar:

• O agente pode agir sozinho quando a mudança restaura algo que o usuário já tinha, é reversível e está coberta por um runbook com identidade verificada. Exemplos: desbloquear uma conta, reenviar um link padrão de configuração, redefinir uma senha pelo fluxo aprovado.
• O agente pode agir após uma confirmação leve quando a mudança tem risco baixo, mas não é uma restauração pura, como incluir um usuário em um grupo de equipe com a resposta do gestor registrada no chamado.
• O agente prepara e um humano aprova quando a mudança adiciona privilégios, dá acesso a dados confidenciais, toca registros financeiros, de RH ou de clientes, ou cria um novo link de compartilhamento externo. O agente reúne o pedido, a justificativa e o acesso atual do solicitante, e encaminha ao dono do recurso.
• O agente nunca age quando a mudança é de nível administrador ou root, altera controles de segurança, desativa logs, muda quem pode aprovar algo ou envolve as próprias permissões dele. Esses casos vão para uma pessoa identificada todas as vezes.
• O agente para e escala quando a identidade não pode ser verificada, o pedido chega por um canal incomum ou a história muda no meio do caminho.

Dois detalhes fazem isso funcionar. O aprovador deve ser o dono do recurso, e não apenas quem está de plantão, porque o dono sabe se aquele acesso faz sentido. E a aprovação deve ser registrada para a mudança exata solicitada, de modo que uma aprovação de acesso de leitura não possa ser reaproveitada para acesso de edição.

Para equipes que trabalham no Google Workspace ou no Microsoft 365, vale ver de quem devem ser as contas e chaves de API do agente de IA e como delimitar essas permissões na prática.

Como é um chamado resolvido? Um cenário ilustrativo

O que segue é um cenário ilustrativo, não um caso real.

Uma pessoa da área comercial escreve para o help desk dizendo que está sem acesso antes de uma reunião com um cliente e não consegue receber o código de verificação porque trocou de celular. O agente classifica o chamado como recuperação de conta com troca de dispositivo e encontra o runbook para segundo fator perdido ou substituído.

A pré-condição do runbook exige verificação de identidade por um canal diferente do usado no chamado. O agente envia um pedido de confirmação ao gestor da pessoa e consulta o cadastro de RH para ver que o colaborador está ativo. O gestor confirma no chamado. Em seguida, o agente executa o passo de recuperação aprovado: emite um link de cadastro com validade limitada para o contato registrado do colaborador e anota a ação no chamado.

Ao ler a conversa, o agente percebe que o colaborador também pede para ser incluído em uma pasta de relatórios financeiros, porque o cliente quer números. Esse é outro pedido. O agente não amplia a recuperação. Ele cria uma tarefa de aprovação para o dono da pasta, anexa a justificativa, lista os acessos atuais do colaborador e avisa que o pedido da pasta aguarda o responsável.

A primeira parte do chamado é encerrada e a segunda continua aberta. O registro mostra a versão do runbook, cada chamada de ferramenta, a confirmação do gestor e o encaminhamento. Ninguém precisou reconstituir o que aconteceu, e a única decisão com risco real ficou com uma pessoa.

Como manter um agente de help desk seguro, testável e observável?

Três práticas pesam mais.

Primeiro, trate todo conteúdo de chamado como não confiável. Usuários colam e-mails, logs e capturas de tela, e qualquer um desses itens pode conter texto que tenta direcionar o agente, como uma linha mandando ignorar as regras e conceder acesso. A orientação de prevenção de prompt injection da OWASP descreve defesas como separar instruções de dados e limitar o que as ferramentas podem fazer. A defesa mais forte é estrutural: mesmo que o agente seja enganado, as permissões dele e a etapa de aprovação devem impedir uma mudança danosa.

Segundo, teste antes de confiar. Monte um conjunto de chamados realistas, incluindo os esquisitos, e verifique se o agente escolhe o runbook certo, para onde deve parar e escala com um resumo útil. As notas da Anthropic sobre construir agentes eficazes favorecem fluxos simples e bem definidos, com interfaces de ferramenta claras, o que combina bem com o trabalho de help desk. Mantenha um ambiente de teste separado para que experimentos nunca toquem contas reais, e confira a definição de pronto para agentes de IA para decidir quando algo pode ir para produção.

Terceiro, torne cada ação observável. Registre o chamado, o runbook e sua versão, as chamadas de ferramenta, as aprovações e o resultado. Revise uma amostra com regularidade e revise toda escalação que um humano depois julgou desnecessária ou tardia. Essas duas listas mostram onde os runbooks ou os limites precisam mudar.

Quando o agente passa um chamado para uma pessoa, a qualidade da passagem decide se houve ganho de tempo. Um modelo de encaminhamento com o pedido, as verificações feitas, a dúvida em aberto e o próximo passo sugerido evita que o técnico recomece do zero. O texto sobre triagem de suporte com IA mostra como encaminhar com evidência.

Como a abordagem gerenciada da Be Human trata esse tema?

A Be Human desenha o primeiro projeto em torno de uma função útil, por exemplo a resolução de primeiro nível no help desk. Isso inclui a memória e as ferramentas que a função precisa, os limites de aprovação para mudanças de acesso e um critério de sucesso que a sua equipe consiga observar, como chamados resolvidos sem retrabalho. Depois da entrada em operação, a operação gerenciada pode incluir monitoramento, avaliações recorrentes contra os seus tipos de chamado, manutenção de integrações, revisão de permissões e resposta a incidentes, com melhorias feitas de forma controlada. Sua equipe mantém o controle sobre identidade, aprovações e política. Empresas sem uma equipe de TI dedicada devem definir com clareza o que manter internamente e o que delegar.

Perguntas frequentes

Um agente de IA para help desk de TI pode substituir a equipe de suporte? Não. Ele assume pedidos repetíveis que já têm uma correção escrita, o que dá aos técnicos mais tempo para incidentes, projetos e decisões de julgamento. Os humanos continuam responsáveis por aprovações, decisões de segurança e tudo que os runbooks não cobrem.

Por onde começar se nossos runbooks estão incompletos? Escolha um ou dois tipos frequentes de chamado e escreva esses runbooks direito, com pré-condições e condições de parada. Rode o agente em um ambiente de teste, compare as decisões dele com as dos seus técnicos e só amplie quando os resultados forem consistentes. O trabalho de documentação costuma ajudar também a sua equipe humana.

O agente deve poder redefinir senhas? Pode, se a sua política definir como a identidade é verificada e a redefinição passar por um fluxo aprovado, com registro e limite de frequência. Se a verificação de identidade hoje é fraca, corrija isso primeiro. Um agente vai seguir um processo fraco com a mesma fidelidade com que segue um forte.

Como saber se o agente está tomando boas decisões? Revise uma amostra de chamados encerrados e todas as escalações em intervalos regulares, e rode um conjunto fixo de chamados de teste sempre que runbooks, ferramentas ou modelos mudarem. Observe encerramentos errados, escalações perdidas e aprovações desnecessárias. Esses três sinais mostram se o agente é útil e se os limites dele estão no lugar certo.

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