Como solicitar mudanças em um agente de IA gerenciado: fluxo completo

Para solicitar uma mudança em um agente de IA gerenciado, escreva um pedido curto e específico que diga qual é o problema, qual comportamento você quer e como vai saber que funcionou. Em seguida, o fornecedor avalia o impacto, testa a mudança contra exemplos combinados e a libera com um aprovador nomeado e um jeito de reverter. Use o mesmo ciclo para toda mudança, pequena ou grande, e as melhorias continuam controladas e rastreáveis.

Principais pontos

• Passe toda mudança por uma única porta, com um pedido escrito e um registro, em vez de mensagens de chat e pedidos de corredor.
• Um bom pedido informa o problema, um exemplo real, o comportamento desejado, o que não pode mudar e um critério de sucesso.
• Classifique as mudanças por risco. Ajustes de redação pedem aprovação leve. Novas ferramentas, permissões mais amplas e dados sensíveis pedem um aprovador nomeado e liberação em etapas.
• Teste contra um conjunto fixo de casos de referência antes e depois, para ver o que a mudança fez e o que ela quebrou.
• Mantenha um registro de mudanças e um ponto de reversão. Se você não consegue dizer o que mudou na semana passada, não consegue operar o agente com responsabilidade.

Por que as mudanças em um agente de IA precisam de um processo próprio?

Um agente de IA não é uma configuração única. O comportamento dele vem de instruções, fontes de conhecimento, ferramentas, permissões, canais e do modelo que está por baixo. Uma pequena edição em qualquer um desses itens pode alterar resultados em um ponto que você não estava olhando. Um tom mais simpático pode fazer o agente pedir desculpas demais. Um documento novo na base de conhecimento pode contradizer um antigo. Uma ferramenta nova pode abrir uma ação que ninguém planejou.

A falha mais comum é informal. Alguém pede um ajuste em uma conversa de chat, alguém aplica, e um mês depois a equipe percebe que o agente se comporta de outro jeito sem que ninguém saiba por quê. Ninguém foi descuidado. A empresa apenas nunca combinou como a mudança acontece.

Um processo leve resolve isso. Ele tem uma porta de entrada, uma etapa de classificação, um teste, uma aprovação e um registro. Deve parecer mais um formulário curto do que um comitê. O objetivo não é frear a melhoria. É fazer de cada melhoria algo que você consiga explicar, repetir e desfazer. Para ver o quadro mais amplo do que acontece depois que o agente entra em operação, leia como melhorar a IA que a empresa já usa.

O que deve constar em uma solicitação de mudança?

A qualidade do pedido define a maior parte do resultado. Pedidos vagos geram mudanças vagas, e mudanças vagas são difíceis de testar. O pedido não precisa ser longo, mas precisa destas partes:

• O problema ou objetivo, em uma frase.
• Um exemplo real do comportamento atual: a entrada que o agente recebeu e o que ele produziu, com detalhes sensíveis removidos.
• O comportamento desejado, de preferência com um exemplo de bom resultado.
• O que não pode mudar, como o tom com clientes-chave, um aviso obrigatório ou uma regra de escalonamento.
• A área que você acha que será afetada: instruções, conhecimento, ferramentas, permissões ou canal. Um palpite basta, o fornecedor confirma.
• Quem pede e o responsável de negócio que vai julgar o resultado.
• A urgência, com o motivo.
• Um critério de sucesso: como você vai saber, na prática, que a mudança funcionou.

Compare dois pedidos. O primeiro diz: deixe o agente melhor ao responder clientes. O segundo diz: quando um cliente pergunta sobre entrega, o agente hoje informa uma data que a equipe não confirmou. Troque isso por uma mensagem dizendo que a equipe vai confirmar a data, e continue respondendo normalmente quando o cliente informar uma data. Sucesso significa que um revisor não encontra datas não confirmadas em uma amostra de rascunhos recentes.

O segundo pedido pode ser testado, aprovado e revertido. O primeiro só serve para discussão.

Quem revisa, quem aprova e quanta revisão é suficiente?

Nem toda mudança merece o mesmo rigor. Tratar um ajuste de redação como uma mudança de permissão gasta tempo, e tratar uma mudança de permissão como um ajuste de redação cria risco. Separe os pedidos em níveis e combine antes quem dá o aval de cada um. Este é um guia de decisão que você pode adaptar:

• Risco baixo: redação, tom, formatação, correções em conteúdo de conhecimento já existente. O responsável pelo agente aprova depois de checar os casos de referência. Liberação na janela regular.
• Risco médio: nova fonte de conhecimento, nova tarefa rotineira, regra de escalonamento alterada, novo canal, qualquer mudança em mensagens voltadas ao cliente. O responsável pelo agente e o líder do departamento envolvido aprovam. O fornecedor revisa quais dados a mudança toca.
• Risco alto: nova ferramenta, qualquer ação que grave ou envie algo, permissões mais amplas, acesso a dados sensíveis, troca de modelo ou de fornecedor. O responsável pelo agente e, conforme o caso, TI, segurança ou jurídico precisam aprovar. A revisão de permissões faz parte do trabalho, e a liberação é feita em etapas, primeiro para um grupo pequeno.
• Restrição urgente: parar ou limitar um comportamento agora, como desativar uma ferramenta que está funcionando mal. Qualquer pessoa autorizada pode pedir e o fornecedor age de imediato. A revisão acontece depois e fica registrada.

Duas regras mantêm isso honesto. Primeiro, quando o nível não estiver claro, escolha o mais alto. Segundo, reduzir o que o agente pode fazer costuma ser mais seguro e rápido do que ampliar, então trate expansões com mais cuidado do que restrições.

Registre por escrito quem aprova. Uma tabela curta de responsabilidades ajuda, e o modelo de responsabilidade compartilhada em agentes de IA mostra como definir quem executa, quem responde pelo resultado, quem é consultado e quem é informado. Para qualquer mudança que amplie acessos, faça uma revisão de permissões antes da liberação. Orientações de autorização, como o OWASP Authorization Cheat Sheet, apoiam o mesmo princípio: conceder o menor acesso necessário e revisá-lo quando ele muda.

Como testar uma mudança antes de ela entrar no ar?

Testar uma mudança é comparar o agente antes e depois com as mesmas entradas. A ferramenta para isso é um conjunto de casos de referência: tarefas reais ou realistas, cada uma com a descrição de como é um bom resultado. Comece pequeno. Um conjunto modesto que cubra as tarefas principais é mais útil do que um conjunto grande que ninguém mantém.

Um conjunto de referência útil inclui quatro tipos de caso:

• Tarefas típicas que o agente executa todos os dias.
• Tarefas difíceis em que ele já errou.
• Casos-limite em que ele deve recusar, pedir ajuda ou escalar para uma pessoa.
• Casos sem relação com a mudança, incluídos para detectar efeitos colaterais.

Rode o conjunto antes da mudança para ter uma linha de base e de novo depois. Peça a alguém que conheça o trabalho para revisar as diferenças, já que nem toda diferença é uma regressão e nem todo teste aprovado é um sucesso de verdade. Onde o resultado é claramente verificável, como uma frase obrigatória ou uma ação proibida, verificações automáticas poupam esforço. Materiais publicados sobre avaliação de agentes, como a visão geral da Anthropic sobre evals para agentes de IA, defendem a mesma ideia: avalie com regras claras o que for possível e use julgamento humano para o resto.

Toda correção aumenta o conjunto. Quando um erro chega a um usuário, transforme-o em caso de referência para que o mesmo erro seja pego da próxima vez. Ao longo dos meses, o conjunto de referência vira um registro do que a empresa espera do agente. O mesmo conjunto também ajuda a definir o que um piloto precisa provar, como explicado em critérios de sucesso para piloto de agente de IA.

Como é o fluxo do pedido até a liberação?

Este é um passo a passo que funciona para a maioria das empresas. Ele pode rodar em um formulário compartilhado, uma fila de chamados ou um canal dedicado, desde que seja um só lugar.

• Passo um, envio: quem pede preenche a solicitação com as partes listadas acima e envia ao canal único combinado.
• Passo dois, triagem: o fornecedor confirma o recebimento, tira dúvidas e atribui um nível de risco. Quem pediu é informado do nível e de quem vai aprovar.
• Passo três, análise de impacto: o fornecedor lista quais instruções, conhecimentos, ferramentas e permissões a mudança toca e quais usuários ou equipes vão perceber.
• Passo quatro, construção em uma cópia: a mudança é feita em uma versão de trabalho separada, nunca direto no agente em operação.
• Passo cinco, teste: os casos de referência rodam antes e depois. Os resultados, inclusive o que piorou, são registrados.
• Passo seis, aprovação: o aprovador nomeado para aquele nível lê o pedido, o impacto e as evidências dos testes, e então aprova, pede retrabalho ou recusa com um motivo.
• Passo sete, liberação: a mudança entra no ar com um ponto de reversão salvo. Mudanças de risco alto vão primeiro para um grupo pequeno e só se ampliam depois de revisão.
• Passo oito, observação e encerramento: por um período combinado, a equipe acompanha possíveis problemas e confere o critério de sucesso. Depois, o pedido é encerrado no registro.

O registro de mudanças é o produto duradouro desse fluxo. Cada entrada deve conter o que mudou, por quê, quem pediu, quem aprovou, quando foi liberado, o que os testes mostraram e onde está o ponto de reversão. Práticas de observabilidade, como as descritas na introdução do OpenTelemetry, também ajudam aqui: fica mais fácil julgar uma mudança quando você consegue ver o comportamento do agente antes e depois.

Pedidos recusados e adiados também pertencem ao registro. Um pedido razoável que foi postergado, com o motivo, evita que a próxima pessoa pergunte de novo às cegas.

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

Este cenário é ilustrativo, não um caso real. Uma empresa de serviços usa um agente para redigir respostas a consultas de clientes. A líder de atendimento percebe que os rascunhos às vezes prometem datas de entrega que a equipe não confirmou. Ela envia um pedido com dois rascunhos de exemplo, a redação desejada e um critério de sucesso: um revisor não deve encontrar datas não confirmadas em uma amostra de rascunhos recentes.

O fornecedor classifica o pedido como risco médio, porque a mudança afeta mensagens voltadas ao cliente. O gerente de operações é nomeado coaprovador. A mudança é feita em uma cópia de trabalho e rodada contra os casos de referência. Um resultado surpreende: o agente agora também evita repetir datas que os clientes informam nas próprias mensagens, o que não é o que a equipe quer. A instrução é refinada e os casos rodam de novo.

O gerente de operações revisa as evidências e aprova. A mudança entra no ar primeiro em uma única caixa de entrada, com um ponto de reversão salvo. Após o período de observação, a líder de atendimento confirma o critério de sucesso, e a entrada é encerrada no registro com os resultados dos testes anexados.

Nada nessa história é complicado. Cada etapa simplesmente deixa evidências, e é isso que torna fácil responder a perguntas depois.

Como a Be Human trata pedidos de mudança em uma operação gerenciada?

Em um contrato gerenciado, a Be Human recebe os pedidos de mudança por um canal único combinado, atribui um nível de risco com os aprovadores nomeados pelo cliente e constrói a mudança em uma versão de trabalho separada, não no agente em operação. A mudança é checada contra os casos de referência, liberada com um ponto de reversão após o aval e registrada em um log que o cliente pode ler. Mudanças que ampliam acessos passam por revisão de permissões, e as permissões permanecem sob controle do cliente o tempo todo. Melhorias controladas são uma parte do trabalho recorrente descrito em primeiros meses com um agente de IA gerenciado.

Perguntas frequentes

Quem na nossa empresa deve poder enviar pedidos de mudança? Qualquer pessoa que use o agente pode descrever um problema, mas ajuda ter uma ou duas pessoas nomeadas como solicitantes, geralmente o responsável pelo agente e os líderes de departamento. Elas transformam o retorno bruto da equipe em pedidos completos. Isso mantém a fila clara e evita que pedidos conflitantes cheguem ao fornecedor.

E se a mudança for urgente e não pudermos esperar o fluxo completo? Use o caminho de restrição urgente: qualquer pessoa autorizada pode pedir para parar ou limitar um comportamento, e o fornecedor age na hora. Escreva o pedido e conclua a revisão depois. Expansões urgentes de capacidade ainda devem seguir o nível normal, porque pressa é um mau motivo para ampliar acessos.

E se uma mudança piorar as coisas depois da liberação? Use o ponto de reversão salvo para voltar à versão anterior, depois registre o que aconteceu e adicione o caso que falhou ao conjunto de referência. Reverter primeiro e investigar depois mantém os usuários seguros. O mesmo pedido pode ser reaberto com as novas evidências.

Mudanças que o próprio fornecedor faz, como uma atualização de modelo, também precisam de aprovação? Sim. Mudanças do lado do fornecedor podem alterar o comportamento tanto quanto os seus pedidos, então devem ser comunicadas, classificadas em um nível e testadas contra os mesmos casos de referência. Se o contrato não diz como isso funciona, peça que seja registrado por escrito, por exemplo no escopo de trabalho.

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