Como reportar problema em agente de IA para resolver rápido

Para reportar um problema em agente de IA e conseguir que ele seja corrigido, envie uma única mensagem com quatro partes: a tarefa que você pediu ao agente, o resultado que esperava, o que realmente aconteceu e o contexto (onde, quando, qual conta ou canal). Anexe a resposta exata e diga o quanto o problema afeta o seu trabalho. Um relato montado assim permite que quem opera o agente reproduza o problema sem precisar de uma nova conversa.

Principais pontos

• Descreva a tarefa, o resultado esperado, o resultado real e o contexto. Essas quatro partes respondem à maioria das perguntas que quem vai corrigir faria depois.
• Guarde a resposta exata. Parafrasear o que o agente disse elimina o detalhe que, em geral, explica a falha.
• Diga o que você esperava e por quê. Sem isso, ninguém sabe se o agente errou ou se seguiu uma instrução pouco clara.
• Trate uma ação indesejada ou uma informação exposta de forma diferente de uma resposta errada: reporte na hora e peça uma pausa se aquilo puder continuar.
• Use um único canal de reporte combinado e um único modelo, para que os relatos cheguem completos e nada dependa de quem ficou sabendo do problema.

Por que relatos vagos sobre agentes de IA demoram tanto para ser resolvidos?

Um agente de IA raramente falha como uma impressora. A impressora trava sempre no mesmo ponto. Um agente pode responder certo para uma pessoa e errado para outra, conforme a forma como o pedido foi escrito, os documentos a que ele teve acesso, a ferramenta que acionou e as instruções que seguia naquele dia. Um relato que diz apenas que o agente errou de novo dá a quem vai corrigir quase nada para trabalhar.

Boa parte da primeira hora de uma correção se perde em perguntas. O que exatamente você pediu? O que esperava ver? Qual cliente ou documento estava envolvido? Foi a primeira vez? Cada pergunta custa uma ida e volta, e quando a resposta chega o funcionário já passou para outra tarefa, a conversa subiu na tela e os detalhes estão pela metade na memória.

O objetivo de um bom relato é eliminar essas idas e vindas. Ele não precisa diagnosticar a causa. O diagnóstico é trabalho de quem opera o agente. O seu trabalho é descrever o que viu com tanta clareza que outra pessoa consiga ver o mesmo.

O que um relato de problema em agente de IA deve conter?

Use cinco partes curtas. As quatro primeiras trazem os fatos. A quinta diz a quem vai corrigir qual é a urgência.

• Tarefa: o que você pediu ao agente, copiado palavra por palavra, se possível.
• Esperado: como seria um resultado correto e por que você o esperava (uma política, um resultado anterior, um documento que você conferiu).
• Ocorrido: o que o agente disse ou fez, com a resposta exata anexada.
• Contexto: onde e quando aconteceu, qual canal ou conta você usou, qual documento, cadastro de cliente ou arquivo estava envolvido e se já tinha acontecido antes.
• Impacto: o que o problema afetou, se alguém fora da sua equipe viu e se você consegue continuar trabalhando.

O resultado esperado é a parte que as pessoas pulam, e é a mais útil. Agentes muitas vezes acertam uma pergunta diferente daquela que você tinha em mente. Se você escreve que esperava a versão mais recente de um documento e que o agente usou uma versão antiga, quem corrige sabe que deve olhar o que o agente consegue ler e como ele escolhe entre versões. Se você escreve apenas que a resposta estava errada, a pessoa precisa adivinhar.

O contexto importa porque o comportamento de um agente depende do ambiente em que ele atua. O mesmo pedido pode gerar resultados diferentes numa janela de chat e num canal de e-mail, ou para dois usuários com acessos distintos. Informar o canal, a conta e o horário permite que o operador encontre o registro correspondente nos logs do agente. A prática de observabilidade em geral se apoia nessa ideia: quando um sistema registra o que fez e em que sequência, um sintoma relatado pode ser rastreado até a causa (o [guia introdutório de observabilidade do OpenTelemetry](https://opentelemetry.io/docs/concepts/observability-primer/) explica os conceitos). O seu relato é o ponteiro que mostra ao operador qual registro abrir.

Como é um bom relato na prática?

Este é um cenário ilustrativo. Uma coordenadora de operações de vendas pede ao agente da empresa que prepare um resumo de renovação para a conta de um cliente. O resumo traz um prazo contratual que havia sido substituído por um aditivo. A coordenadora percebe antes de encaminhar o documento.

Um relato fraco seria assim:

O resumo da renovação está errado, por favor corrijam.

Agora o operador precisa perguntar qual cliente, qual resumo, o que estava errado e qual deveria ser o prazo correto. Um relato forte para o mesmo caso seria:

• Tarefa: pedi ao agente, no canal de vendas, que preparasse um resumo de renovação para a conta de um cliente específico, usando o contrato arquivado.
• Esperado: o resumo deveria mostrar o prazo de aviso previsto no aditivo, porque o aditivo substituiu a cláusula original.
• Ocorrido: o resumo mostra o prazo de aviso do contrato original. O agente não mencionou o aditivo. Resposta anexada.
• Contexto: canal de vendas, minha própria conta, hoje de manhã. Os dois documentos estão na pasta do cliente. Não vi isso em outras contas, mas conferi só esta.
• Impacto: percebi antes de enviar. Posso continuar conferindo os prazos manualmente, mas não confiaria nos resumos de outras contas com aditivos até que isso seja analisado.

Esse relato é curto e já aponta para uma causa provável: o agente encontrou o documento original e não conseguiu enxergar o aditivo, ou não o priorizou. O operador pode abrir a mesma pasta, repetir o pedido e verificar o que o agente conseguia ler. Não é preciso reunião.

Como descrever diferentes tipos de problema?

Nem todo problema merece o mesmo tratamento. Use este guia para decidir como redigir o relato e com que rapidez enviá-lo.

• A resposta estava errada ou incompleta: envie o relato padrão. Inclua a fonte com a qual você conferiu, pois é assim que quem corrige sabe qual dos dois está certo.
• O agente não fez algo que deveria: diga o que esperava que ele fizesse, o que ele fez no lugar (inclusive nada) e se mostrou um erro ou simplesmente parou.
• O agente fez algo que não deveria, como enviar uma mensagem, alterar um registro ou fazer uma reserva: reporte imediatamente. Diga o que mudou, onde e se pode acontecer de novo. Peça uma pausa se puder.
• O agente mostrou informação a alguém que não deveria vê-la, ou pareceu seguir instruções escondidas dentro de um documento ou mensagem: trate como assunto de segurança. Reporte de imediato pelo canal combinado e não encaminhe o conteúdo além do necessário. Essas categorias aparecem no [OWASP Top 10 para aplicações de LLM](https://genai.owasp.org/llm-top-10/) como divulgação de informações sensíveis e injeção de prompt.
• O agente estava lento, indisponível ou inconsistente: anote o horário, o que você tentava fazer e se tentar de novo ajudou.

Na dúvida, reporte. Um relato que se revela um mal-entendido custa alguns minutos. Um problema real que ninguém mencionou porque parecia pequeno pode se repetir em silêncio pela equipe.

O que fazer entre perceber o problema e enviar o relato?

Os momentos logo após uma falha são aqueles em que a evidência é mais fácil de perder. Uma rotina curta ajuda.

• Pare e preserve a evidência. Não apague a conversa, não tente de novo várias vezes e não sobrescreva o arquivo que o agente mexeu.
• Capture a resposta exata. Copie o texto ou tire uma captura de tela que mostre o pedido e a resposta juntos.
• Anote os detalhes enquanto estão frescos: o horário, o canal, o registro ou documento envolvido.
• Escreva as cinco partes em linguagem simples. Duas ou três frases para cada uma bastam.
• Envie o relato pelo único canal combinado, e não numa conversa paralela com um colega.
• Diga se o trabalho deve ser pausado. Se o agente ainda está agindo sobre algo errado, escreva isso na primeira linha.

Uma verificação rápida antes de enviar:

• Alguém que não estava presente conseguiria repetir o pedido a partir do que escrevi?
• Eu disse o que esperava, e não apenas o que deu errado?
• A resposta exata está anexada?
• Informei o canal, a conta e o registro envolvidos?
• Está claro se o assunto é urgente?

Procure não incluir mais do que o necessário. Não cole dados sensíveis de clientes num relato se o nome do registro ou uma referência bastar. O operador pode consultar o registro com o próprio acesso.

O que acontece depois que você envia o relato?

Um processo bem conduzido segue um caminho previsível. O operador confirma o recebimento, tenta reproduzir o problema e descobre qual parte da configuração é responsável. A causa costuma estar em um de poucos lugares: as instruções que o agente segue, o conhecimento ou a memória a que ele recorre, uma ferramenta que ele aciona, uma permissão que ele tem ou não tem, ou o comportamento do modelo por trás. Saber qual deles é decide a correção.

Se a causa é uma instrução ou uma ferramenta, a correção é uma mudança no agente, e mudança em agente em produção deve ser aprovada e testada, não improvisada. O artigo O que é AgentOps? Como operar um agente de IA no dia a dia ajuda a entender essa rotina. Se o relato apontar para um acesso amplo demais ou restrito demais, ele alimenta a revisão de permissões.

Os melhores operadores também transformam um problema confirmado em um caso de teste salvo: a mesma tarefa, o mesmo contexto e o resultado correto conhecido. Depois da correção, eles rodam o teste de novo para confirmar que o problema sumiu e o mantêm, para que uma mudança futura não o traga de volta. Essa é a ideia básica por trás das avaliações de agentes, discutida na [orientação de engenharia da Anthropic sobre avaliações](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents). Um relato com tarefa clara e resultado esperado claro se converte nesse tipo de teste quase direto. Um relato vago, não.

Por fim, quem reportou deve receber uma resposta. Mesmo uma nota curta dizendo o que foi encontrado e o que mudou mostra ao funcionário que reportar funciona, e é isso que mantém os próximos relatos chegando.

Como a empresa pode facilitar o reporte para que as pessoas o façam?

As pessoas reportam problemas quando é rápido, quando está claro para onde enviar e quando algo visível acontece depois. Três hábitos fazem a diferença.

• Um canal: um único lugar ou endereço para problemas com o agente, informado na mesma mensagem que apresenta o agente à equipe.
• Um modelo: as cinco partes acima, fixadas onde as pessoas vão ver, para que um relato leve alguns minutos.
• Uma regra de confirmação: todo relato recebe uma resposta dizendo quem está com ele e qual é o próximo passo, mesmo que a correção leve tempo.

Esses hábitos fazem parte da adoção como um todo. Funcionários que sabem para que serve o agente, o que ele não deve fazer e como sinalizar uma falha têm muito mais chance de continuar usando. O guia Como engajar a equipe no uso de agentes de IA cobre esse quadro mais amplo, e o texto Como melhorar a IA que a empresa já usa mostra como olhar os relatos e o retorno dos funcionários como um padrão, e não um por um.

Como a Be Human trabalha isso: num acompanhamento gerenciado, o reporte é combinado no início, junto com a função do agente, as ferramentas e os limites de aprovação. Os funcionários recebem um canal e um modelo curto. A equipe de operações registra cada relato, reproduz o caso usando os registros do agente, identifica a camada responsável, propõe uma mudança para o responsável aprovar e confere o resultado contra o caso original. Os relatos recorrentes são revisados periodicamente em busca de padrões, e tudo que envolva exposição de informação ou ações indesejadas é tratado como incidente, e não como solicitação de rotina.

Perguntas frequentes

Preciso de conhecimento técnico para reportar um problema em agente de IA? Não. Basta descrever, em linguagem comum, o que você pediu, o que esperava e o que aconteceu. O operador cuida do diagnóstico técnico. A resposta exata e uma descrição clara do contexto valem mais do que qualquer explicação técnica.

Devo reportar todo errinho do agente? Reporte tudo o que você corrigiria à mão mais de uma vez, tudo o que poderia chegar a um cliente e tudo o que envolva acesso, dados ou ações. Preferências pontuais de redação podem entrar no retorno de rotina, sem relato formal. Se você não tem certeza de qual é o caso, envie o relato e deixe o operador decidir como tratá-lo.

E se eu não conseguir repetir o problema? Reporte mesmo assim e diga que não conseguiu repetir. Inclua o horário, o canal e a resposta exata do momento em que aconteceu. Agentes podem se comportar de forma diferente de um pedido para o outro, e o operador muitas vezes encontra o evento original nos registros do agente, mesmo quando ele não se repete sob demanda.

Quando devo pedir que o agente seja pausado? Peça a pausa quando o agente estiver executando ações erradas, quando puder ter exposto informação à pessoa errada ou quando você não conseguir continuar trabalhando com segurança a partir da resposta dele. Escreva isso na primeira linha do relato. Interromper um piloto ou um fluxo é um controle normal, e o operador pode retomá-lo quando a causa estiver entendida.

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