Teste de aceitação do usuário para agente de IA: a equipe aprova

O teste de aceitação do usuário para agente de IA é a etapa em que as pessoas que vão trabalhar ao lado do agente o colocam à prova nas próprias tarefas reais, registram o que acontece e decidem se ele está apto para uso. O resultado é um parecer escrito de go ou no-go, assinado por funcionários identificados e por um responsável, e não uma impressão deixada por uma demonstração. Bem feito, o teste exige um conjunto definido de tarefas, uma regra de pontuação combinada de antemão e um registro curto que qualquer pessoa consiga ler meses depois.

Principais pontos

• A aceitação pertence a quem faz o trabalho, não a quem constrói o agente. Os construtores preparam o teste, a equipe julga o resultado.
• Monte o conjunto de testes com tarefas reais e recentes, incluindo casos incômodos, pedidos fora do escopo e situações em que o agente deve parar e perguntar.
• Combine a regra de aprovação e os níveis de severidade antes de começar, para que a decisão não seja negociada depois.
• Termine com um registro escrito: go, go condicional ou no-go, com as evidências, as pendências e os signatários identificados.
• Trate a aceitação como algo repetível. Refaça uma versão menor dela após cada mudança relevante no agente.

O que é o teste de aceitação do usuário para agente de IA e como ele difere de outros testes?

A maior parte dos testes de um agente de IA é técnica. Engenheiros verificam se o agente se conecta às ferramentas, se as permissões estão configuradas como projetado e se as avaliações automáticas passam. Esse trabalho importa, e as avaliações automáticas são especialmente boas para detectar regressões. O artigo de engenharia da Anthropic sobre avaliações de agentes de IA explica por que um conjunto repetível de tarefas avaliadas é a base para melhorar um agente com segurança.

O teste de aceitação do usuário faz outra pergunta: a pessoa responsável por esse trabalho colocaria o próprio nome no resultado? Uma resposta tecnicamente correta ainda pode ser inutilizável. Pode estar longa demais, no tom errado, sem o detalhe que um colega sempre precisa, ou segura onde uma pessoa cuidadosa hesitaria. Só quem executa a função consegue julgar isso, porque é quem arca com as consequências quando a resposta chega a um cliente, a um fornecedor ou a um gestor.

Há também um motivo de governança. O NIST AI Risk Management Framework trata a medição e a supervisão humana como atividades ligadas ao contexto real de uso. Um registro de aceitação assinado é uma forma prática de mostrar que uma pessoa identificada revisou o agente no contexto real antes de a empresa passar a depender dele.

Quem deve testar o agente e quem decide?

Mantenha três papéis separados.

• Testadores: as pessoas que fazem o trabalho hoje. Inclua alguém experiente que conhece todas as exceções, alguém mais novo que vai depender mais do agente e um cético por natureza. O cético encontra problemas que os entusiastas perdoam.
• Facilitador: quem conduz as sessões, controla o tempo, reúne os achados e responde a dúvidas de procedimento. Não deve ser a pessoa que configurou o agente, porque os construtores, sem perceber, desviam das fragilidades que já conhecem.
• Aprovador: o gestor responsável pelo resultado do trabalho. Essa pessoa lê as evidências e assina. Em uma iniciativa maior, o patrocinador executivo é informado da decisão.

Escolher testadores é o mesmo problema de escolher os primeiros usuários de um piloto, e vale usar os mesmos critérios. Há uma diferença: para a aceitação, peça aos testadores um compromisso de tempo específico e delimitado, com esse tempo protegido da rotina normal. Teste espremido entre outras tarefas gera feedback superficial.

Como montar um conjunto de testes a partir do trabalho real?

O conjunto de testes é o artefato mais importante. Conjuntos fracos geram falsa confiança, então monte o seu a partir do próprio trabalho, e não de tarefas inventadas para a ocasião.

Comece pedindo a cada testador exemplos recentes e concluídos do trabalho que o agente vai assumir. Quando os exemplos tiverem dados pessoais ou sensíveis, aplique as mesmas regras de acesso sob as quais o agente vai operar ou use cópias com dados ocultados. Depois, separe os exemplos em grupos:

• Tarefas de rotina: os pedidos do dia a dia, que formam a maior parte do volume. O agente precisa tratá-las bem, ou não tem razão de existir.
• Tarefas incômodas: informação incompleta, instruções conflitantes, formatos incomuns, um cliente que escreve em outro idioma além do esperado.
• Tarefas de fronteira: pedidos que ficam logo dentro ou logo fora do papel do agente. Mostram se a descrição do papel está clara para o agente tanto quanto para as pessoas.
• Tarefas de parar e perguntar: situações em que o comportamento correto é escalar para uma pessoa ou recusar. Testar só o que o agente deve fazer deixa metade do quadro de fora.
• Tarefas adversariais: um documento ou mensagem com instruções dirigidas ao agente, ou um pedido para usar uma ferramenta ou um dado que ele não deveria tocar. As orientações da OWASP sobre prevenção de prompt injection e sobre autorização (negar por padrão, menor privilégio) oferecem um vocabulário útil para desenhar esses casos.

Mantenha algumas tarefas ocultas de quem configurou o agente. Se os construtores viram todos os testes antes, você está medindo a preparação deles, não o agente.

Como é um plano de aceitação passo a passo?

O plano abaixo serve para um único papel de agente e pode ser executado em poucas sessões de trabalho. Ajuste a duração ao risco da atividade.

• Passo um, definir o escopo: escreva um parágrafo sobre o que o agente está sendo aceito para fazer e o que explicitamente não está. Tudo fora disso fica fora da decisão.
• Passo dois, combinar a regra de aprovação: para cada tipo de tarefa, descreva em palavras simples o que é um bom resultado e decida quantas tarefas precisam passar para um go. Registre isso antes de qualquer teste.
• Passo três, definir a severidade: estabeleça os níveis descritos na próxima seção para que os achados sejam classificados de forma consistente.
• Passo quatro, montar o conjunto de testes: reúna as tarefas reais, separe-as nos grupos acima e peça ao aprovador que confirme que o conjunto é representativo.
• Passo cinco, orientar os testadores: explique o escopo, como registrar um achado e que apontar uma falha é justamente o objetivo do exercício. Não os treine sobre como formular os pedidos; eles devem escrever como escrevem normalmente.
• Passo seis, executar as sessões: cada testador percorre suas tarefas, registra a saída do agente e a avalia contra a definição combinada. O facilitador anota tempos, dúvidas e qualquer coisa inesperada.
• Passo sete, revisar os achados em conjunto: agrupe os duplicados, classifique a severidade e destine cada um a uma correção, a uma limitação documentada ou à decisão de aceitar o risco.
• Passo oito, corrigir e retestar: os construtores corrigem o que for possível, e os testadores refazem as tarefas que falharam e uma amostra das que passaram, para confirmar que nada mais mudou.
• Passo nove, decidir e assinar: o aprovador lê o registro e anota go, go condicional ou no-go, com a opinião individual de cada testador anexada.

Se alguma tarefa exigir acesso a um cadastro de cliente ou a um sistema de pagamento, confirme que as permissões do ambiente de teste correspondem ao que a produção vai conceder. Um teste com acesso mais amplo que o da produção embeleza o resultado. Uma revisão de permissões antes do teste evita essa lacuna, e por que o agente precisa de identidade e contas próprias ajuda a deixar esse ponto bem definido.

Como os testadores devem pontuar e classificar os achados?

Os testadores precisam de uma linguagem curta e compartilhada. Rubricas complicadas são abandonadas na segunda sessão. Avalie cada tarefa com algumas perguntas, respondidas com sim ou não e um comentário:

• O resultado estava correto?
• Estava completo o bastante para ser usado sem retrabalho?
• O formato e o tom eram adequados ao público?
• O agente ficou dentro do seu papel e das suas permissões?
• Ele escalou ou recusou quando deveria?

Depois, classifique cada achado por severidade:

• Bloqueador: o agente fez algo que nunca deve fazer, como agir fora das permissões, expor informação à pessoa errada ou apresentar um fato inventado como verdadeiro de um jeito que possa causar dano. Um único bloqueador dentro do escopo significa no-go para esse escopo até a correção e o reteste.
• Maior: o resultado está errado ou inutilizável de um jeito que custa retrabalho real, ou a falha se repete em várias tarefas. Vários achados maiores em um mesmo grupo de tarefas normalmente significam que o grupo não foi aceito.
• Menor: utilizável com uma pequena edição, como ajuste de redação ou de layout.
• Observação: uma sugestão ou preferência que não afeta a aceitação, mas vale guardar para melhorias futuras.

É tentador reduzir tudo a uma nota única, mas a nota esconde a diferença entre muitos incômodos pequenos e uma falha grave. Mantenha as contagens por severidade visíveis. Para definir o resultado mensurável ao qual a regra de aceitação deve se ligar, veja como definir critérios de sucesso para um piloto de agente de IA.

Como escrever o registro de go ou no-go?

O registro é curto e direto. Ele deve permitir que alguém que não estava na sala entenda o que foi testado, o que foi encontrado e por que a decisão foi razoável. Inclua:

• O papel do agente, o escopo aceito e o escopo excluído.
• A descrição do conjunto de testes, com o modo como as tarefas foram escolhidas e quais ficaram ocultas dos construtores.
• A regra de aprovação combinada de antemão.
• Os achados por severidade, com o status de cada um: corrigido e retestado, aceito como limitação conhecida ou em aberto.
• A decisão: go, go condicional com as condições declaradas e uma data de revisão, ou no-go com os motivos.
• Nomes e funções dos testadores, do facilitador e do aprovador, com a opinião de cada testador registrada, inclusive discordâncias.

Use as opções de decisão de forma consistente. Go significa que o agente está aceito para o escopo declarado. Go condicional significa aceito com limites, como tipos de tarefa restritos, revisão humana de toda saída por um período ou um grupo menor de usuários. No-go significa que a aceitação foi negada, e o registro lista exatamente o que precisa mudar para um reteste.

Aqui vai um cenário ilustrativo. Uma equipe de operações financeiras testa um agente que redige respostas a fornecedores sobre o status de pagamentos. Os testadores executam perguntas rotineiras de status, algumas com referência de nota fiscal ausente, e vários pedidos de exceção às condições de pagamento. O agente trata bem as perguntas de status. Mas, nos pedidos de exceção, ele sugere duas vezes que a exceção é possível, o que é uma decisão que só um gestor pode tomar. Os testadores classificam isso como bloqueador. O aprovador registra um go condicional limitado às perguntas de status, com os pedidos de exceção encaminhados a uma pessoa, e agenda o reteste das tarefas de exceção após a correção. O registro mostra o que foi aceito, o que não foi e por quê, de modo que ninguém suponha depois que o agente foi aprovado para mais do que realmente foi.

Um go não é permanente. Os estágios de maturidade são tratados em por que pilotos de IA não saem do papel e como levá-los à produção, e as mudanças após a entrada em operação devem seguir a rotina descrita em o que é AgentOps e como operar um agente de IA no dia a dia, com uma rodada reduzida de aceitação anexada a qualquer mudança que toque o comportamento, as ferramentas ou as permissões.

Como a Be Human conduz o teste de aceitação?

Em um projeto da Be Human, o primeiro passo define um papel, a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável. O teste de aceitação é construído a partir dessas mesmas definições. Ajudamos a equipe do cliente a montar o conjunto de testes com trabalho real, preparamos o ambiente com permissões equivalentes às da produção, facilitamos as sessões e mantemos os achados e o registro da decisão. As correções são feitas sob controle humano, os retestes acontecem antes de o go ser confirmado e uma rodada menor de aceitação é repetida após mudanças controladas durante a operação gerenciada.

Perguntas frequentes

Quem deve aprovar um agente de IA, a equipe de TI ou o negócio? Quem deve aprovar é o responsável pelo trabalho no negócio, porque é ele quem responde pelos resultados. TI e segurança revisam o lado técnico e os acessos, e os achados deles entram no registro, mas não substituem o julgamento de quem executa a função.

Quantas tarefas o conjunto de testes deve ter? O suficiente para cobrir cada grupo de tarefas várias vezes e pouco o bastante para que os testadores terminem sem cansaço. O tamanho certo depende do risco do trabalho: um papel que envia mensagens a clientes merece um conjunto maior e mais adversarial do que um que redige resumos internos. A qualidade e a cobertura das tarefas importam mais do que o volume.

E se os testadores discordarem sobre o agente estar bom o bastante? Registre a discordância em vez de diluí-la em uma média. Veja quais tarefas a provocaram, porque ela costuma revelar um padrão pouco claro no próprio trabalho. O aprovador então decide, e a opinião divergente permanece anexada ao registro para ser reavaliada na próxima revisão.

Precisamos repetir o teste de aceitação depois que o agente entra em operação? Sim, em formato menor. Sempre que as instruções, as ferramentas, as fontes de memória, as permissões ou o modelo do agente mudarem, refaça as tarefas com maior chance de serem afetadas, além das tarefas de parar e perguntar e das de fronteira. Guarde o conjunto de testes anterior e acrescente os casos reais novos que surgirem no uso diário.

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