Processo de solicitação de mudança em agente de IA: passo a passo

Um processo de solicitação de mudança em agente de IA é um caminho curto e escrito, com quatro paradas: um colaborador descreve a mudança, o dono classifica o risco, a mudança é agendada com um jeito de voltar atrás, e alguém confere o resultado contra o que foi prometido. Basta um formulário, um aprovador nomeado por agente e um registro do que mudou. Isso permite que o agente continue melhorando sem que ninguém o edite de modo informal.

Principais pontos

• Trate toda mudança em instruções, conhecimento, ferramentas, permissões ou configurações do modelo como mudança em um sistema em produção, mesmo quando parecer uma edição pequena.
• Use um formulário curto que obrigue quem pede a dizer qual é o problema, qual comportamento deseja e como saberá que funcionou.
• Separe os pedidos em poucas classes de risco, para que ajustes de redação andem rápido e mudanças de acesso recebam um olhar mais atento.
• Agende cada mudança aprovada com o plano de reversão escrito antes da liberação e verifique o resultado com tarefas de exemplo guardadas.
• Mantenha um registro de mudanças simples. Ele será a evidência de que você vai precisar em revisões de permissão, incidentes e passagens de responsabilidade.

Por que as mudanças em um agente precisam de processo?

Um agente de IA não é uma ferramenta fixa. O comportamento dele resulta de várias partes trabalhando juntas: instruções, conhecimento de referência, memória, ferramentas conectadas, permissões e configurações do modelo. Uma edição pequena em qualquer uma delas pode alterar o que o agente faz para todas as pessoas que o usam.

Sem uma porta de entrada, as mudanças chegam por mensagens de chat, pedidos de corredor e por quem tiver acesso de administrador naquele dia. Disso saem três problemas. Ninguém consegue explicar por que o agente se comporta de outro jeito neste mês. Uma mudança que ajuda uma equipe prejudica outra sem que ninguém perceba. E uma permissão é ampliada para uma tarefa pontual e nunca mais é reduzida.

Processo de mudança não é burocracia por si só. A função dele é a proporção: mudanças pequenas passam rápido, mudanças de risco ganham um segundo par de olhos e tudo deixa rastro. O NIST AI Risk Management Framework descreve governança e medição como trabalho contínuo, não como tarefa de lançamento, e o processo de mudança é a forma cotidiana dessa ideia.

Se você ainda está decidindo quem, na sua empresa, deve ser o dono dessas decisões, leia Líder interno de IA na empresa: quem é o dono da IA no dia a dia.

O que um pedido de mudança deve conter?

O formulário deve caber em uma página. Se levar mais do que alguns minutos para preencher, as pessoas vão contorná-lo. Se for raso demais, o dono gastará o primeiro dia só fazendo perguntas. Um conjunto de campos que funciona:

• A mudança em uma frase: o que o agente deve fazer de forma diferente, saber ou conseguir acessar?
• Solicitante e equipe afetada: quem está pedindo e quem mais usa essa parte do agente?
• O problema hoje: um ou dois exemplos reais de tarefa em que o comportamento atual ficou aquém.
• Comportamento desejado: um exemplo de entrada e como seria uma boa resposta ou ação.
• Sistemas e dados envolvidos: qualquer nova ferramenta, fonte de dados, canal ou permissão de escrita.
• Quem é afetado se der errado: clientes, colegas, registros financeiros, fornecedores.
• Urgência: se existe um prazo real e a que ele está ligado.
• Verificação de sucesso: como o solicitante saberá que a mudança funcionou.

Duas observações sobre essa lista. Primeiro, pedido de mudança é diferente de relato de falha. Se o agente fez algo errado que já deveria fazer certo, o caminho é o relato de problema, não este formulário. O pedido de mudança serve para quando você quer que o agente se comporte de um jeito diferente do que foi desenhado.

Segundo, devolva qualquer pedido que não consiga indicar uma verificação de sucesso. Se ninguém sabe dizer como perceberia que a mudança funcionou, ninguém poderá verificá-la depois, e o pedido ainda não está pronto.

Como o dono deve classificar e aprovar um pedido?

O dono é a pessoa responsável pelo papel do agente, não necessariamente quem o configura. A primeira tarefa dele é classificar o pedido. Quatro classes bastam para a maioria das empresas, e cada uma tem um aprovador e um nível de teste diferentes.

• Redação e conhecimento: documentos de referência atualizados, modelos de texto, tom, nomes de produtos. Aprovador: o dono do agente. Teste com um punhado de tarefas de exemplo.
• Comportamento: instruções alteradas, regras de roteamento, gatilhos de escalonamento, o que o agente pode decidir sem perguntar. Aprovador: o dono mais o líder de cada equipe afetada. Teste com um conjunto guardado mais amplo, que inclua casos difíceis.
• Acesso: nova ferramenta, fonte de dados, canal, ou qualquer passagem de leitura para escrita. Aprovador: o dono mais o responsável pelo sistema ou pelos dados. Confira o pedido contra o princípio do menor privilégio, presente nas orientações de autorização da OWASP: quem age deve ter apenas o acesso que a tarefa exige.
• Estrutura: outro modelo, outra forma de hospedagem, outros horários de operação ou outro desenho de memória. Aprovadores: o patrocinador executivo e o dono, com plano de reversão por escrito. Teste com o conjunto guardado completo e compare com os resultados atuais.

Quando um pedido ficar entre duas classes, classifique para cima. O custo de uma revisão a mais é pequeno perto do custo de uma mudança de acesso conferida de qualquer jeito.

O dono tem três respostas possíveis: aprovar, recusar com um motivo ou adiar com uma condição. Motivos comuns para recusar: o pedido não tem um resultado definido, conflita com uma mudança pendente de outra equipe ou pede que o agente assuma trabalho fora do papel que lhe foi definido. Uma recusa com motivo claro ajuda quem pediu. Uma fila silenciosa não ajuda.

Como agendar e liberar uma mudança aprovada?

Aprovar não é o mesmo que liberar. É no intervalo entre as duas coisas que se pegam os problemas mais evitáveis. Uma sequência que funciona sem ferramentas especiais:

• Registre a decisão: classe, aprovador, data e a mudança exata em palavras simples.
• Agrupe mudanças compatíveis, mas nunca junte uma mudança de acesso com uma de comportamento. Se algo quebrar, você precisa saber qual delas causou o problema.
• Escolha uma janela longe do pico de uso e avise a equipe afetada quando ela será.
• Escreva a reversão antes da mudança: o que restaurar, quem faz e como você saberá que deu certo.
• Teste em uma cópia do agente, ou em um canal limitado, usando tarefas de exemplo guardadas.
• Libere e depois explique aos usuários, em uma ou duas frases, o que ficou diferente. Surpresas corroem a confiança mais rápido do que um comportamento imperfeito.
• Mantenha um período curto de acompanhamento, em que o dono ou o operador lê conversas e ações reais.

Para o lado técnico de liberar sem causar interrupção, veja O que é AgentOps? Como operar um agente de IA no dia a dia. O processo descrito aqui é a camada de negócio em volta desse trabalho: quem pediu, quem concordou e quando.

Como verificar se a mudança funcionou?

A verificação deve responder à pergunta que o solicitante escreveu no formulário. Se a verificação de sucesso era que as respostas sobre pedidos atrasados mencionassem o novo status da transportadora, o teste é saber se elas mencionam.

Mantenha, para cada agente, um pequeno conjunto guardado de tarefas de exemplo: pedidos típicos, pedidos incômodos e alguns que o agente deve recusar ou escalar. Rode esse conjunto antes e depois de toda mudança que não seja trivial. É a versão pequena e cotidiana do que a engenharia chama de avaliações (evals): testes com critérios de sucesso definidos, que a Anthropic descreve em seus textos sobre evals para agentes de IA. Você não precisa de uma bateria grande. Precisa de exemplos que reflitam o trabalho real e do hábito de rodá-los.

Uma lista de fechamento para o dono:

• O solicitante confirma que o problema original foi resolvido no uso real.
• Os exemplos guardados se comportam como esperado e nada que funcionava antes regrediu.
• Não existe acesso que não tenha sido aprovado, e qualquer acesso temporário foi removido.
• A entrada no registro de mudanças está completa, incluindo a reversão que não precisou ser usada.
• Os usuários afetados sabem o que mudou.

Depois, encerre o pedido. Revise o registro na sua revisão periódica de permissões, para que as mudanças aprovadas sejam conferidas contra o que o agente realmente consegue fazer hoje.

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

Este cenário é ilustrativo e não descreve uma empresa real.

Uma líder de atendimento em uma distribuidora pede que o agente rascunhe respostas sobre entregas atrasadas usando o status de pedido em tempo real. O formulário diz que o problema é que a equipe copia o status do sistema de logística à mão. O comportamento desejado é um rascunho que informe o status atual e a próxima etapa prevista. A verificação de sucesso é que os rascunhos de pedidos atrasados batam com o que o sistema de logística mostra.

O dono classifica como mudança de acesso, porque o agente precisa ler um sistema que hoje não alcança. O gerente de logística entra como coaprovador. Eles combinam acesso somente de leitura, limitado aos campos de status do pedido, sem dados de pagamento de clientes e sem poder editar pedidos.

A mudança é agendada para uma manhã tranquila. A reversão é desconectar a integração e voltar às instruções anteriores. Em uma cópia de teste, a equipe roda perguntas guardadas sobre pedidos atrasados, mais uma armadilha deliberada: uma pergunta sobre o pedido de outro cliente, que o agente deve recusar. Após a liberação, o dono lê rascunhos reais por um período curto de acompanhamento, encerra o pedido e registra o acesso no log.

Nada disso foi lento. Foi ordenado, e cada etapa levou só o tempo que o risco justificava.

Como a Be Human trata pedidos de mudança em agentes?

Na operação gerenciada da Be Human, os pedidos de mudança entram em uma fila única por agente. Cada um é classificado junto com o dono do negócio, testado antes da liberação com tarefas de exemplo guardadas, liberado com uma reversão por escrito e registrado em um log de mudanças. O dono do negócio mantém a aprovação sobre comportamento e acesso, enquanto a Be Human cuida dos testes, da liberação, da manutenção das integrações e da revisão de permissões que cercam essas decisões. Se um pedido exige nova ferramenta ou permissões mais amplas, ele é tratado e revisado como mudança de acesso.

Perguntas frequentes

Quem deve aprovar mudanças em um agente de IA? O dono do agente aprova a maioria dos pedidos, pois responde pelo papel que o agente exerce. Mudanças que tocam o trabalho ou o sistema de outra equipe precisam do líder dessa equipe como coaprovador, e mudanças estruturais precisam do patrocinador executivo. O ponto é que o aprovador seja uma pessoa nomeada, não um grupo de mensagens.

Precisamos de um software de chamados para rodar esse processo? Não. Um formulário compartilhado e um registro simples, como uma planilha ou um documento com entradas datadas, bastam para começar. O que importa é que todo pedido tenha os mesmos campos, uma decisão registrada e uma nota de verificação. Você pode migrar para uma ferramenta própria mais tarde, se o volume justificar.

E as mudanças urgentes? Permita um caminho acelerado, mas mantenha o mesmo registro. O dono aprova rápido, a reversão continua sendo escrita primeiro e a mudança é revisada depois para confirmar que nada ficou em aberto. Se a maioria dos pedidos for marcada como urgente, provavelmente o processo está lento demais ou a fila não está sendo lida.

Com que frequência devemos revisar o registro de mudanças? Olhe para ele a cada revisão regular de permissões e sempre que o comportamento mudar de forma inesperada. Os padrões importam mais do que as entradas isoladas: pedidos repetidos para o mesmo ajuste sugerem um problema de desenho, e uma sequência de acessos temporários nunca removidos sugere uma falha no fechamento dos pedidos. Revisão trimestral de IA na empresa: manter, corrigir ou encerrar descreve um ritmo de revisão que combina bem com esse registro.

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