Um agente pode executar várias etapas corretamente e ainda parecer fora de controle. A interface mostra um indicador genérico, o tempo passa e o usuário recebe um resultado sem saber quais informações foram consideradas. Quando esse resultado afeta dinheiro, acesso ou uma decisão importante, precisão isolada não produz confiança.
Um artigo da Smashing Magazine chama de "transparency moments" os pontos onde o sistema deixa um caminho determinístico e faz uma escolha probabilística. Identificar esses pontos permite explicar o que o agente está avaliando, quando precisa de confirmação e como uma pessoa pode contestar o resultado.
Transparência útil não exige publicar chain of thought nem despejar logs técnicos. Ela exige mostrar estado, evidência relevante e consequência no momento em que o usuário consegue agir.
Nem toda etapa merece a mesma explicação
Copiar um arquivo, validar um formato ou consultar um registro por identificador segue regras previsíveis. Classificar uma imagem, resumir um boletim ou escolher entre hipóteses envolve probabilidade. Se a interface apresenta tudo como uma sequência uniforme, o usuário não percebe onde existe margem de erro.
Uma auditoria de nós de decisão pode percorrer o fluxo e marcar cada etapa como determinística ou probabilística. Para as probabilísticas, o time registra entrada, saída, confiança disponível, impacto e possibilidade de reversão. O resultado não é uma tela cheia de avisos. É um mapa para escolher poucos momentos de comunicação.
Etapas de baixo impacto podem receber uma descrição de progresso: "comparando os dados enviados". Uma escolha reversível pode mostrar a opção selecionada e permitir ajuste. Uma decisão de alto impacto pode exigir confirmação ou encaminhamento humano. A quantidade de fricção acompanha a consequência.
Progresso específico reduz opacidade
O exemplo citado no artigo envolve análise automatizada de sinistros. O sistema avaliava fotos, procurava sinais no boletim e conferia cobertura da apólice. Clientes viam apenas espera e resposta. Exibir as etapas não alterou o processamento; tornou o caminho legível.
Mensagens específicas ajudam porque estabelecem expectativa. "Analisando fotos do dano" permite entender por que aquela informação foi pedida. "Verificando cobertura" mostra que o resultado depende do contrato, não apenas da imagem. Se a etapa falha, o usuário consegue associar o problema à fonte.
Esse texto precisa corresponder ao trabalho real. Mensagens decorativas que avançam num timer enquanto o backend executa outra coisa pioram confiança. O estado deve vir do processo, com nomes estáveis e sem prometer uma precisão inexistente.
Também convém evitar linguagem que antropomorfiza o agente. "Estou pensando" informa menos que "comparando o pedido com 12 regras de elegibilidade". O segundo texto descreve operação e oferece uma base para questionamento.
Explicação precisa permitir ação
Mostrar que uma decisão foi probabilística sem permitir correção pode funcionar apenas como aviso jurídico. Uma transparência útil oferece ao menos uma saída: editar a entrada, escolher outra opção, solicitar revisão ou ver as evidências consideradas.
O nível de detalhe depende do público. Um cliente pode precisar de razões em linguagem comum. Um operador precisa dos campos e regras usados. Um auditor pode exigir versão do modelo, política aplicada e registro da execução. Tentar servir os três na mesma camada cria uma interface ilegível.
Uma arquitetura em níveis resolve melhor. A interface principal mostra estado e razão curta. Um detalhe expansível apresenta evidência e limitações. Logs preservam informação técnica para suporte e auditoria, com controles de acesso e retenção.
Transparência também inclui incerteza. Se o sistema não tem uma medida calibrada, inventar uma porcentagem causa falsa precisão. É preferível indicar que dados estão incompletos, que houve conflito entre fontes ou que a etapa exige revisão.
Confiança não é uma métrica única
Times frequentemente acompanham accuracy do modelo e taxa de conclusão. Para o usuário, confiança também depende de previsibilidade, controle e recuperação. Um agente pode acertar 95% e ser inadequado se os 5% restantes forem irreversíveis e impossíveis de contestar.
Métricas de produto podem incluir cancelamentos durante execução, correções após resultado, pedidos de revisão e abandono em cada etapa. Pesquisas qualitativas ajudam a descobrir se as mensagens explicam o processo ou apenas aumentam ansiedade.
Testes devem comparar diferentes níveis de detalhe em tarefas reais. Mais transparência pode aumentar compreensão e também sobrecarregar. O objetivo é oferecer a informação necessária no ponto de decisão, mantendo detalhes disponíveis para quem precisa.
Um roteiro para o próximo fluxo
Desenhe a sequência completa do agente, inclusive chamadas a ferramentas e regras tradicionais. Marque onde uma saída depende do modelo. Para cada marca, responda: qual o dano de um erro, a ação é reversível e qual evidência o usuário reconhece?
Depois escolha a menor intervenção compatível com o risco. Pode ser um estado específico, uma prévia, confirmação, citação da fonte ou encaminhamento. Implemente a mensagem a partir de eventos reais do backend e teste cancelamento e falha.
Por fim, dê ao suporte acesso ao mesmo vocabulário usado na interface. Quando um usuário relata problema na "verificação de cobertura", logs e runbooks precisam usar esse nome. Transparência externa sem rastreabilidade interna produz uma explicação que ninguém consegue investigar.
Agentes adicionam escolhas probabilísticas a produtos acostumados com fluxos determinísticos. Tornar esses pontos visíveis não diminui a capacidade do sistema. Define onde pessoas precisam observar, corrigir ou assumir a decisão.
