São Paulo · Brasil texto · arquivo vivo

07 de ago. de 2026 · guia pesquisado

Agente de IA agiu. Como provar o que aconteceu?

Um guia para ligar pedido, regra, versão, ferramenta, aprovação, resultado e correção no mesmo rastro — sem guardar conversa inteira por reflexo.

O cliente diz que o agente cancelou. O CRM mostra uma atualização. A conversa termina com ‘pronto’. Ainda assim, ninguém consegue dizer qual regra foi usada, qual ferramenta mudou o estado e se a confirmação veio do sistema ou do próprio agente.

Log não é uma pilha de texto. É a trilha mínima que permite reconstruir uma ação sem transformar dado de cliente em decoração de dashboard.

O agente disse “feito”. O sistema não contou a mesma história.

Um cliente pede cancelamento. O agente consulta uma política, recebe uma aprovação humana, chama uma ferramenta e responde que concluiu.

Dias depois, o cliente volta. No CRM existe uma anotação. No sistema responsável, o contrato continua ativo. A equipe abre a conversa, procura o prompt, pergunta no grupo e tenta descobrir se houve erro de regra, ferramenta, aprovação ou mensagem.

Há muito registro. Falta rastro.

Auditar uma ação de agente de IA é conseguir reconstruir o caminho entre pedido, decisão, autorização, execução e estado final. A transcrição inteira pode ajudar. Sozinha, não prova que a ferramenta fez o que o texto anunciou.

Resposta curta

Para provar o que aconteceu, ligue oito peças com identificadores estáveis:

  1. pedido: quem solicitou o quê e em qual contexto;
  2. decisão: qual intenção e qual risco o agente classificou;
  3. regra: versão, fonte e trecho que sustentaram a proposta;
  4. autorização: quem ou qual política permitiu a ação, com limite e validade;
  5. execução: ferramenta, entrada, tentativa, horário e versão do agente;
  6. resultado: resposta técnica e estado confirmado no sistema responsável;
  7. comunicação: o que foi dito ao cliente;
  8. revisão: QA, correção, reversão e dono posterior.

O registro de execução do agente de IA organiza esse mínimo numa página copiável. Num piloto estreito, uma planilha com acesso restrito já resolve. O valor não está no software de observabilidade. Está em parar de misturar intenção, tentativa e resultado como se fossem a mesma coisa.

Conversa, log e auditoria não são sinônimos

A conversa mostra o que cliente e agente trocaram. O log técnico mostra eventos do sistema. O rastro de auditoria permite atribuir e reconstruir uma ação relevante.

RegistroResponde melhor a qual pergunta?Limite
transcriçãoo que foi dito?pode não mostrar ferramenta, autorização nem estado final
log de aplicaçãoqual evento o software registrou?pode ser ruidoso e sem significado operacional
trace técnicopor onde a execução passou e quanto demorou?não decide sozinho qual regra de negócio valia
trilha de auditoriaquem pediu, quem autorizou, o que mudou e com qual prova?exige desenho de campos, acesso, retenção e integridade
registro de QAo resultado estava correto e o cliente foi bem atendido?normalmente cobre amostra, não toda execução

A OWASP observa que logs operacionais, de transação, auditoria e segurança podem ter objetivos diferentes e, muitas vezes, devem permanecer separados. Isso evita dois extremos: guardar tudo no mesmo lugar ou acreditar que um log de servidor responde uma pergunta de negócio.

O primeiro identificador nasce antes da ferramenta

Se o agente vai cancelar, cobrar, remarcar, atualizar ou enviar, crie um identificador para a intenção antes da execução.

Exemplo:

acao-20260807-8472-remarcacao-01

Esse identificador precisa acompanhar:

  • conversa ou ticket;
  • pedido do cliente;
  • versão do agente;
  • regra e fonte;
  • aprovação, quando houver;
  • chamada de ferramenta;
  • resposta recebida;
  • registro no sistema responsável;
  • mensagem enviada;
  • revisão ou correção.

Sem essa ligação, a equipe tenta correlacionar horário, nome e texto parecido. Funciona até aparecerem duas ações iguais, dois clientes com nome igual ou uma resposta atrasada. Ou seja: funciona justamente antes de ser necessário.

Registre estado, não só texto

O agente pode dizer “cancelei” por três caminhos ruins:

  1. entendeu que deveria cancelar e confundiu intenção com execução;
  2. chamou a ferramenta e tratou ausência de erro como sucesso;
  3. recebeu sucesso técnico, mas o estado de negócio não mudou como esperado.

Por isso, separe:

EtapaEstado possível
propostasugerida, recusada, corrigida ou pendente
autorizaçãonão exigida, pendente, válida, expirada ou negada
tentativanão iniciada, enviada, rejeitada, timeout ou concluída
efeitonão alterado, alterado, parcialmente alterado ou desconhecido
confirmaçãoausente, resposta técnica, consulta posterior ou conferência humana
comunicaçãonão enviada, enviada, entregue ou corrigida

A evidência mais forte vem do sistema que responde pelo estado. Para agenda, é a agenda. Para cobrança, é o sistema financeiro. Para cadastro, é a base responsável. O resumo do agente é interpretação; não é fonte de verdade por promoção automática.

A versão da regra precisa viajar com a ação

Guardar apenas o texto final não explica por que o agente agiu.

Registre pelo menos:

  • identificador e versão do agente;
  • versão da regra ou política;
  • fonte consultada;
  • data de vigência da fonte;
  • decisão ou categoria atribuída;
  • exceção encontrada;
  • dado ausente que poderia mudar o resultado.

Quando a política muda, duas conversas parecidas podem ter respostas diferentes e ambas estarem corretas no seu momento. Sem versão, a revisão vira debate sobre qual documento alguém lembra ter visto.

O guia Mudou a regra do agente de IA. Como publicar sem quebrar? mostra como preservar antes, depois, casos de teste e caminho de volta.

Aprovação só entra no rastro se estiver ligada ao efeito

Um clique humano isolado prova pouco.

A trilha precisa responder:

  • quem aprovou;
  • qual função ou autoridade tinha;
  • qual ação exata viu;
  • qual valor, alvo, prazo e escopo autorizou;
  • qual versão da regra estava na tela;
  • quando a aprovação expirava;
  • qual tentativa usou aquela autorização;
  • qual estado foi confirmado depois.

Se a pessoa aprovou R$ 80 e a ferramenta executou R$ 800, guardar “aprovado por Ana” não reconstrói o controle. Só registra presença humana.

O cartão de aprovação humana ajuda a definir o que precisa aparecer antes do clique. O rastro de execução fecha o outro lado: o que realmente aconteceu depois.

Fluxo de evidência da ação

1. Identifique o pedido.Conversa, cliente, intenção, objeto e autorização recebida ganham um identificador de ação.
2. Preserve a decisão.Versão do agente, regra, fonte, classificação, lacuna e risco ficam ligados ao pedido.
3. Verifique a autoridade.Política automática ou aprovação humana define ação, limite, validade e responsável.
4. Registre a tentativa.Ferramenta, entrada protegida, chave, horário, resposta, erro e duração entram no mesmo rastro.
5. Confirme o estado.O sistema responsável prova se a mudança aconteceu, não aconteceu ou continua incerta.
6. Compare a mensagem.O que foi dito ao cliente precisa bater com o estado confirmado e com o prazo real.
7. Feche com revisão.QA, contestação, correção, reversão e mudança de regra permanecem atribuíveis.

Um registro mínimo que cabe numa planilha

Comece com estas colunas:

CampoExemplo
ID da açãoacao-20260807-8472-remarcacao-01
conversa ou ticketconv-8472
ação e objetoremarcar reserva 441 para quinta às 15h
versãoagente 18; regra agenda 7
fontepolítica de remarcação vigente em 07/08
autorizaçãocliente confirmou; sem aprovação interna adicional
ferramentaagenda; tentativa tool-921
retorno técnicosucesso às 10:31:08
estado confirmadonova data consultada na agenda às 10:31:10
mensagemconfirmação enviada com protocolo
QAamostra aprovada; sem correção
retenção e acesso90 dias; operação e segurança

Não comece capturando cada prompt, documento, token e resposta completa. Primeiro descubra quais campos permitem resolver as perguntas que a operação realmente recebe.

O que não deveria entrar no log por reflexo

Observabilidade sem contenção pode criar outro incidente: um depósito de dados pessoais, credenciais e conteúdo sensível com acesso amplo.

Evite registrar em texto aberto:

  • senha, token, chave ou credencial;
  • documento completo quando um identificador protegido basta;
  • cartão, dado financeiro ou dado de saúde sem necessidade clara;
  • conteúdo integral de ferramenta quando status e referência resolvem;
  • instrução interna sensível entregue a qualquer analista;
  • transcrição inteira por tempo indefinido;
  • raciocínio interno do modelo como se fosse prova necessária.

A OWASP recomenda remover ou mascarar dados sensíveis e decidir o nível de registro conforme risco e finalidade. O desenho prático é guardar referência, versão, categoria e resultado sempre que isso bastar; abrir conteúdo detalhado apenas para pessoas autorizadas e por tempo definido.

Pergunte para cada campo:

  1. qual investigação ou decisão usa isto?;
  2. quem precisa acessar?;
  3. por quanto tempo?;
  4. dá para guardar referência em vez de conteúdo?;
  5. como detectar alteração ou exclusão indevida?;
  6. o que acontece se esse registro vazar?

Se ninguém sabe responder a primeira pergunta, talvez seja só acúmulo com custo jurídico.

Trace técnico ajuda, mas o padrão ainda está evoluindo

As convenções de GenAI do OpenTelemetry distinguem operações como invocar agente, invocar workflow e executar ferramenta. Isso ajuda a correlacionar chamadas e tempos entre componentes.

A própria especificação marca essas convenções como em desenvolvimento. Use-a como vocabulário técnico útil, não como política de auditoria pronta.

Um trace pode mostrar:

  • qual agente foi invocado;
  • qual workflow participou;
  • qual ferramenta executou;
  • duração e tipo de erro;
  • relação entre etapas.

Ainda cabe à operação acrescentar o que o trace não conhece sozinho: qual regra valia, quem tinha autoridade, qual estado de negócio importa, o que o cliente ouviu e qual correção encerrou o caso.

Cinco perguntas que o rastro precisa responder em minutos

Escolha uma ação real e tente responder:

  1. Por que o agente decidiu agir?
  2. Quem ou qual política autorizou?
  3. Qual ferramenta recebeu qual pedido?
  4. Qual sistema confirmou o estado final?
  5. O que foi comunicado e corrigido depois?

Se a resposta depende de abrir quatro sistemas e perguntar para três pessoas, existe informação. Ainda não existe uma trilha utilizável.

Teste o rastro com casos ruins

Preencha o registro de execução e simule:

CasoO que precisa aparecer
regra muda entre decisão e execuçãoação para ou exige nova decisão
aprovação expiraferramenta rejeita ou pede nova autorização
chamada retorna timeoutestado fica desconhecido; não há confirmação inventada
ferramenta executa duas vezesidentificador revela duplicidade e permite correção
mensagem diz sucesso, sistema diz falhadivergência gera alerta e contato corretivo
alguém altera o registrointegridade, autoria e horário da alteração ficam visíveis
cliente contestaequipe reconstrói pedido, regra, ação e estado sem depender de memória

O teste não termina quando o dashboard mostra uma linha. Termina quando uma pessoa consegue localizar o erro e decidir o próximo passo sem expor mais dado do que precisa.

Quando o caminho simples basta

Uma planilha ou tabela protegida funciona quando:

  • há um agente ou fluxo estreito;
  • poucas ações mudam estado;
  • os sistemas fornecem identificadores consultáveis;
  • uma pessoa revisa falhas no mesmo turno;
  • versões de regra são poucas e conhecidas;
  • acesso e retenção podem ser controlados;
  • o volume permite amostragem e investigação manual.

Faça você mesmo. Registre dez ações, provoque duas falhas e tente reconstruí-las no dia seguinte. Isso ensina mais do que escolher ferramenta de observabilidade pelo desenho da tela.

Onde começa a quebrar

O controle manual perde força quando:

  • vários agentes usam as mesmas ferramentas;
  • voz, WhatsApp, CRM e sistemas internos produzem registros separados;
  • diferentes versões atendem ao mesmo tempo;
  • aprovação e execução ficam em plataformas distintas;
  • uma ação gera outras ações encadeadas;
  • QA não consegue localizar a amostra certa;
  • incidentes exigem pausa e reconciliação em minutos;
  • acesso, retenção e mascaramento variam por dado;
  • ninguém liga correção de operação à mudança de regra.

Aí não basta ter logs. É preciso operar identidade, versão, autorização, ferramenta, estado, evidência, QA e correção como uma sequência.

É nesse cenário que uma camada de gestão de agentes em produção pode fazer sentido. Antes disso, monte o registro mínimo e descubra qual pergunta sua operação ainda não consegue responder.

Quando a reconstrução prova que o erro já chegou ao cliente, o trabalho continua. O guia Agente de IA errou. Quem corrige com o cliente? separa contenção, alcance, estado real, contato corretivo e fechamento.

O teste mais honesto

Pegue uma ação concluída ontem. Esconda a transcrição e tente provar, apenas pelos registros, quem pediu, qual regra valia, quem autorizou, o que a ferramenta fez e qual estado ficou no sistema responsável.

Depois faça o contrário: abra a conversa e esconda o log técnico.

Se nenhuma das duas visões fecha a história, o problema não é falta de dashboard. É falta de ligação.

Vídeo

Eu não encontrei um vídeo em português que eu usaria como resposta principal para esta rotina. Há material sobre tracing, observabilidade e logs de LLM. Pouco começa numa contestação de cliente e reconstrói regra, aprovação, ferramenta, estado, mensagem e correção sem despejar dados sensíveis na tela.

Se bastante gente pedir, este assunto entra na fila de gravação. Não é promessa.

sinal de demanda

Quer um vídeo reconstruindo uma ação do agente?

Se bastante gente pedir, este assunto entra na fila de gravação. O vídeo útil esconderia uma confirmação, trocaria a versão e mostraria como localizar a ruptura sem abrir todos os dados da conversa. Não é promessa.

rastro prático

reconstruir a ação sem adivinhar

Ligue intenção, versão, fonte, autorização, ferramenta e estado final com identificadores estáveis; guarde conteúdo sensível apenas quando houver motivo e proteção.

  1. 01 Quem pediu, qual ação e qual objeto foram afetados.
  2. 02 Versão do agente, regra e fonte usadas.
  3. 03 Aprovação, limite e identidade de quem autorizou.
  4. 04 Ferramenta, tentativa, resposta e estado confirmado.
  5. 05 Mensagem ao cliente, revisão de QA e correção posterior.

materiais para usar

Leia a página. Baixe o Markdown só quando ele ajudar.

O material renderizado é a experiência principal. Os arquivos simples ficam como fonte para copiar, adaptar ou entregar a um agente.

acompanhar por fora do site

Continuo essas notas no LinkedIn.

Sigo publicando ali bastidores, leituras e decisões práticas sobre CRM, atendimento, WhatsApp, IA e agentes. Se esse texto ajudou, me acompanhe por lá também.