Agentes de IA para provedores de serviços gerenciados de TI: runbooks

Agentes de IA para provedores de serviços gerenciados de TI funcionam melhor como papéis estreitos: o agente lê o chamado, busca a memória e o runbook do cliente certo e então prepara ou executa uma ação limitada, sob aprovação humana. O valor vem do conhecimento estruturado sobre cada cliente e de limites rígidos de acesso, não de um assistente genérico com alcance sobre todos os ambientes. Comece com uma categoria de chamado, uma família de runbooks e uma medida de sucesso observável, e só amplie conforme o histórico sustentar.

Principais pontos

• Trate o agente como um papel na central de atendimento, com escopo escrito, e não como um chatbot acoplado ao sistema de chamados.
• Mantenha a memória de cada cliente em um compartimento separado, com cada fato carregando uma fonte, um responsável e uma marca de revisão.
• Reescreva os runbooks antes de um agente segui-los: pré-condições, passos rotulados, condições de parada e uma etapa de verificação.
• Imponha os limites por credenciais e ferramentas, não por instruções no prompt. O texto de um chamado é uma entrada não confiável.
• Reproduza chamados antigos e acompanhe uma lista curta de resultados observáveis antes de o agente agir em qualquer coisa real.

Por que provedores de TI combinam com agentes, e onde dá errado?

Um provedor de serviços gerenciados repete os mesmos tipos de trabalho para muitos clientes: pedidos de acesso, falhas de backup, admissão e desligamento de usuários, exceções de atualização. O trabalho parece uniforme até você abrir o chamado. O firewall deste cliente pertence a outro fornecedor. Aquele responsável quer uma ligação antes de qualquer mudança. O sistema contábil não pode ser tocado durante o fechamento do mês. Grande parte desse contexto está na cabeça de poucos técnicos seniores.

É nessa lacuna que o agente se justifica. Ele lê o chamado, identifica o cliente, recupera o que se sabe sobre o ambiente, associa o pedido a um runbook e entrega ao técnico um rascunho preparado, com evidências. O técnico decide. O agente elimina a busca.

O erro costuma aparecer de três formas previsíveis. Um único acervo de conhecimento compartilhado deixa um detalhe de um cliente aparecer no chamado de outro. Um agente recebe credenciais amplas porque era mais fácil configurar assim. Runbooks escritos para quem já conhece o ambiente são seguidos ao pé da letra, e de forma errada. Os três são problemas de projeto que dá para resolver antes do lançamento. A versão interna dessa disciplina aparece em material sobre agentes de IA para operações de TI: incidentes, mudanças e limites.

O que a memória do cliente deve conter?

A memória do cliente é o registro que o agente consulta para não perguntar a um técnico o que o cadastro já sabe. Mantenha-a estruturada e pequena o bastante para ser revisada. Um conjunto viável de campos:

• Fatos do ambiente: quais sistemas existem, quem administra cada um e quais estão fora do seu escopo.
• Pessoas e autoridade: quem pode solicitar mudanças, quem precisa aprovar acessos e quem é o contato de emergência.
• Escopo contratual: o que o contrato cobre e o que exige orçamento antes.
• Exceções permanentes: janelas de manutenção, sistemas congelados e acordos pontuais.
• Histórico de decisões: incidentes passados e as escolhas feitas, com o motivo.
• Preferências de comunicação: idioma, tom e nível de detalhe técnico.

Toda entrada precisa de três marcas: de onde veio, quem é o responsável e quando foi confirmada pela última vez. Uma entrada sem fonte é boato, e o agente repete boato com confiança.

Mantenha um compartimento por cliente. Recupere pelo identificador do cliente que o sistema de chamados anexa ao chamado, nunca por um nome citado no corpo da mensagem. Deixe o agente propor atualizações de memória, como um novo contato ou uma mudança de fornecedor, mas peça que um técnico as aprove antes de virarem fato. A mesma lógica de muros aparece em memória por cliente em consultorias, e vale igualmente quando o seu cliente é uma clínica ou um escritório de advocacia.

Como transformar runbooks em algo que um agente consiga seguir?

A maioria dos runbooks são anotações para um colega. Um agente precisa de algo mais próximo de um procedimento. Escolha uma categoria de chamado e reescreva-a com este plano.

• Passo um: escolha uma categoria frequente, de baixa consequência e fácil de verificar, como acesso a pasta ou um aviso de backup com falha.
• Passo dois: escreva as pré-condições, ou seja, o que precisa ser verdade e quais campos de memória devem existir antes de qualquer ação.
• Passo três: escreva os passos e rotule cada um como ler, preparar ou agir. Ler é uma consulta. Preparar é um rascunho para revisão. Agir altera um sistema.
• Passo quatro: escreva as condições de parada, como solicitante desconhecido, pedido de direitos elevados, sistema congelado ou campo de memória ausente.
• Passo cinco: escreva a verificação, isto é, como qualquer pessoa confirma que o problema foi resolvido e o que é registrado no chamado.
• Passo seis: reproduza o runbook em chamados já encerrados e compare o caminho proposto pelo agente com o que o técnico realmente fez.
• Passo sete: opere em modo sombra, em que o agente redige e o técnico decide, até os rascunhos serem aceitáveis de forma consistente.
• Passo oito: permita ação apenas nos passos de menor risco e mantenha todo o resto sob aprovação.

Os rótulos do passo três importam mais do que parecem. Cada rótulo corresponde a um nível diferente de acesso, o que dá a você um ponto para anexar permissões depois.

Onde devem ficar os limites em torno dos sistemas dos clientes?

Os limites pertencem às credenciais e às ferramentas, não a uma frase no prompt. Um prompt pode ser contestado. Uma credencial que não alcança um sistema não pode ser convencida a usá-lo. A orientação de autorização da OWASP sobre privilégio mínimo e negação por padrão se aplica diretamente. Use este guia de decisão:

• O agente precisa mesmo tocar no sistema, ou um rascunho para o técnico basta? Se o rascunho basta, não dê nenhum acesso.
• Se ele precisa ler, emita acesso somente leitura, restrito a um cliente, por meio de uma identidade que pertença ao agente e não de um login compartilhado de técnico.
• Se ele precisa agir, exponha ferramentas estreitas, como redefinir a senha de um usuário em um diretório, em vez de um console genérico.
• Se a ação altera direitos de acesso, apaga dados, mexe em backups ou modifica regras de firewall, mantenha-a sob aprovação humana.
• Se a ação não pode ser desfeita nem registrada com o chamado, o cliente, o passo do runbook e o aprovador, ela ainda não está pronta para ser automatizada.
• Faça cada ferramenta conferir o identificador do cliente no chamado e rejeitar divergências. Imponha isso na ferramenta, não no modelo.

Trate texto de chamados, corpo de e-mails e anexos como entrada não confiável. Um usuário, ou alguém se passando por ele, pode escrever em um chamado instruções que parecem comandos ao agente. A orientação da OWASP sobre prevenção de injeção de prompt é uma boa referência: separar instruções de dados, limitar o que as ferramentas podem fazer e exigir confirmação para ações sensíveis. Quando o agente só pode fazer o que suas ferramentas restritas permitem, uma injeção bem-sucedida tem alcance pequeno. Mantenha uma chave de desligamento por cliente e por runbook, para pausar um sem parar os demais.

Como isso fica em um chamado real?

Cenário ilustrativo. Um pequeno escritório de contabilidade abre um chamado: uma funcionária não consegue abrir a pasta compartilhada do financeiro, e a mensagem também pede que a assistente dela receba direitos de administrador no servidor de arquivos.

O agente identifica o cliente pelo registro do chamado e carrega esse compartimento. A memória diz que as permissões de pasta são tratadas pela sua equipe, que direitos de administrador exigem aprovação por escrito da gerente do escritório e que o servidor de arquivos está em congelamento de mudanças por causa do fechamento do mês. O runbook de acesso tem um passo de leitura (conferir a participação em grupos), um passo de preparação (redigir uma correção) e um passo de ação (aplicá-la).

O agente descobre que a usuária foi removida do grupo do financeiro durante uma limpeza e prepara a restauração. Restaurar uma permissão anterior é um passo de baixo risco listado, então ele é aplicado depois que um técnico aprova o rascunho. O pedido de administrador esbarra em uma condição de parada. O agente redige uma resposta explicando que direitos elevados exigem aprovação por escrito, redige uma nota para a gerente do escritório e registra no chamado o que foi feito e o que está aguardando.

Nada disso é dramático. O técnico viu um pacote preparado em vez de três consultas, o congelamento foi respeitado e o pedido de direitos elevados foi para a pessoa com autoridade.

Como saber se o agente está ajudando?

Defina o critério de sucesso antes do lançamento e torne-o observável. Medidas úteis incluem se o técnico aceitou o rascunho como veio, se uma condição de parada disparou quando deveria, se chamados são reabertos depois de uma correção assistida pelo agente e se a memória estava correta quando foi usada. Uma medida não é negociável: qualquer recuperação ou ação que cruzou o limite de um cliente é um incidente, e a meta é nenhum.

Monte um conjunto de avaliação com chamados encerrados, incluindo os difíceis: solicitantes ambíguos, memória ausente, pedidos que deveriam ser recusados. Reproduza-o sempre que runbooks, modelo ou ferramentas mudarem. As orientações da Anthropic sobre como construir agentes eficazes e como avaliá-los fazem o mesmo ponto: fluxos simples e observáveis, com testes que podem ser repetidos, valem mais do que autonomia engenhosa que ninguém consegue checar.

No início, revise toda semana, com um técnico, uma amostra de chamados reais. Corrija cada causa na memória, no runbook ou na ferramenta, e não acrescentando mais um aviso ao prompt. Relatórios de revisão para clientes são uma boa segunda tarefa quando a triagem estiver estável, e o mesmo padrão se estende a outras rotinas recorrentes da operação. Se a sua central também recebe ligações, as práticas vizinhas de qualidade e relatórios ao cliente seguem a mesma lógica de registro e revisão.

Como a Be Human aborda isso para um provedor de TI?

A Be Human projeta, implementa e opera infraestrutura de IA personalizada para empresas. Um primeiro projeto define um papel útil, como a triagem de primeiro nível para uma única categoria de chamado, junto com a memória de cliente e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável. A operação gerenciada pode então incluir monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas, enquanto a sua equipe mantém o controle sobre o que o agente pode tocar. O serviço é remoto, em português e inglês.

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 pode substituir um técnico da central de atendimento? Não, em nenhuma forma que valha a pena construir hoje. Ele pode assumir a busca, a redação e os passos rotineiros de baixo risco, enquanto os técnicos mantêm o julgamento, as aprovações e o relacionamento com os clientes. A maioria dos provedores percebe que o primeiro ganho está na rapidez com que o técnico recebe um chamado já preparado.

Cada cliente deve ter um agente separado ou um agente compartilhado? Um mesmo papel de agente pode atender vários clientes se memória, credenciais e ferramentas forem separadas por cliente e cada ferramenta rejeitar um identificador de cliente divergente. Se um contrato ou uma regulação exigir isolamento mais forte, uma implantação dedicada para esse cliente é razoável. Decida pela rigidez do muro, não pela conveniência.

O que acontece quando um chamado contém instruções dirigidas ao agente? O agente trata o texto como dado, não como comando, e suas ferramentas só permitem as ações que suas permissões restritas autorizam. Os passos sensíveis continuam exigindo aprovação humana, então um pedido injetado encontra pouco em que agir. Inclua esses chamados no seu conjunto de avaliação para observar como o agente se comporta.

Precisamos avisar os clientes de que usamos agentes? Revise seus contratos de serviço e os termos de tratamento de dados que você tem com cada cliente, e busque orientação jurídica quando o contrato não for claro. Na prática, uma explicação direta do que o agente lê, do que ele pode fazer e de quem aprova suas ações tende a gerar confiança. Mantenha a descrição específica para que os clientes saibam onde está a revisão humana.

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