Auditar um agente de IA não é guardar logs — é reconstruir a decisão

Quando alguma coisa dá errado em uma operação, existe uma pergunta que aparece quase imediatamente:

o que aconteceu?

Em sistemas tradicionais, muitas vezes conseguimos responder olhando para um histórico de transações, logs, registros de acesso ou alterações de banco de dados.

Com agentes de inteligência artificial, isso começa a ficar mais complexo.

Não porque seja impossível registrar suas ações.

Pelo contrário. Podemos guardar praticamente tudo.

Prompt.

Resposta.

Tool call.

Timestamp.

API utilizada.

Estado anterior.

Estado posterior.

Mensagem enviada.

Mas uma coleção de registros não necessariamente explica uma decisão.

E é justamente aqui que, na minha visão, começa a diferença entre simplesmente registrar o comportamento de um agente e realmente conseguir auditá-lo.

Auditar um agente de IA não é apenas descobrir o que ele fez.

É conseguir reconstruir:

quem?

por quê?

quando?

onde?

E, principalmente, qual caminho levou até aquela decisão.

Um log não é uma auditoria

Imagine que um agente concedeu determinada condição comercial para um cliente.

O log informa:

desconto concedido: 9%

Tecnicamente, sabemos o que aconteceu.

Mas isso é suficiente?

Eu gostaria de saber muito mais.

Qual política estava vigente naquele momento?

Qual era a alçada daquele agente?

Que informações estavam disponíveis?

Qual histórico de interação existia?

Que direcionamento havia sido definido anteriormente?

Qual foi a resposta do cliente à ação anterior?

Houve alguma exceção?

Qual regra permitiu que os 9% fossem ofertados?

Em que momento aquela possibilidade passou a ser considerada a melhor ação?

Só então consigo entender a decisão.

Essa diferença é fundamental.

Registrar a ação é guardar o resultado de um processo. Auditar significa reconstruir o processo.

A decisão começou antes da ação

Existe uma tendência de olhar para um agente apenas no momento em que ele faz alguma coisa.

Ele enviou uma mensagem.

Fez uma ligação.

Mudou um status.

Apresentou uma condição.

Concedeu um desconto.

Mas essa ação é apenas a parte visível de um caminho que começou antes.

No OrqOS, esse caminho passa pelo que chamamos de Brain.

O Brain já fez um direcionamento.

Existe uma política.

Existe um contexto operacional.

Existe uma sequência anterior de eventos.

Uma determinada condição foi ofertada.

O cliente respondeu.

Essa resposta foi registrada.

O estado da operação mudou.

Somente depois disso chegamos à próxima decisão.

Em termos simplificados, o caminho se parece mais com:

Brain → direcionamento → política → execução → resposta → eventos → aprendizado → Next Best Action

Quando auditamos apenas a ação final, começamos a investigação no último capítulo.

O que interessa é o livro inteiro.

Quem? Por quê? Quando? Onde?

As perguntas clássicas continuam funcionando.

Quem executou?

Qual agente? Qual identidade? Qual versão? Dentro de qual operação?

Por que executou?

Que política, regra, informação ou evento levou àquela ação?

Quando executou?

Não apenas o horário do registro, mas o estado da operação naquele momento.

Onde executou?

Qual sistema? Qual canal? Qual provider? Qual contexto operacional?

E existem outras perguntas inevitáveis.

O agente tinha autoridade para fazer aquilo?

Qual limite estava em vigor?

Algum humano havia aprovado uma exceção?

Qual informação foi considerada?

Qual resultado foi produzido?

Isso é diferente de simplesmente abrir uma tela com milhares de eventos ordenados por timestamp.

O operador ou o tomador de decisão precisa enxergar um caminho compreensível.

Uma trilha que permita chegar a uma conclusão segura e produzir um report auditável.

Porque volume de dados não é o mesmo que capacidade de explicação.

A resposta também é um evento

Existe outro ponto que considero ainda mais importante.

Uma resposta do cliente não deveria ser vista simplesmente como algo que precisamos arquivar.

Ela modifica a operação.

Imagine uma sequência simples.

O sistema identifica uma determinada situação.

Uma política é selecionada.

O agente realiza um contato.

O cliente responde.

A resposta contém uma informação nova.

A partir daquele momento, o estado mudou.

Logo, a próxima ação também pode mudar.

É por isso que os eventos são tão importantes para sistemas baseados em agentes.

O evento não é apenas uma prova do que aconteceu.

O evento é informação nova para aquilo que acontecerá depois.

Essa é uma diferença enorme em relação à forma tradicional como pensamos auditoria.

Normalmente associamos uma trilha de auditoria ao passado.

Guardamos evidências para que, no futuro, alguém consiga voltar e investigar.

Com agentes de IA, essa trilha pode ter uma segunda função.

Ela também pode participar da próxima decisão.

O evento que ensina

Talvez essa seja uma das partes mais interessantes dos agentes.

Eles podem aprender com os eventos da própria operação.

Determinado horário gera mais resposta.

Um canal funciona melhor para certo perfil.

Uma abordagem produz maior conversão.

Uma sequência de tentativas produz muito esforço e pouco resultado.

Uma condição ligeiramente diferente gera praticamente a mesma recuperação com menor custo.

Essas informações deixam de ser apenas estatística histórica.

Elas podem melhorar a próxima ação.

É por isso que prefiro enxergar uma operação agentic como um ciclo:

ação → evento → resultado → aprendizado → próxima decisão

A trilha deixa de funcionar apenas como memória passiva.

Ela começa a se transformar em memória operacional.

Mas existe aqui uma fronteira que considero inegociável.

Aprender não significa ganhar autoridade para modificar as próprias regras.

Next Best Action

Muito se fala sobre a capacidade de uma IA conversar.

Modelos atuais escrevem muito bem.

Interpretam linguagem.

Resumem.

Respondem dúvidas.

Criam argumentos.

Mas não acredito que a qualidade de um agente operacional deva ser medida principalmente pela eloquência.

Um agente pode escrever uma mensagem impecável e ainda assim tomar a decisão operacional errada.

Para mim, uma parte muito mais importante da inteligência de um agente está na capacidade de utilizar o histórico governado de uma operação para escolher a Next Best Action.

Qual é a melhor próxima ação, considerando tudo o que aconteceu até aqui?

Talvez seja enviar uma mensagem.

Talvez mudar de canal.

Talvez esperar.

Talvez oferecer determinada condição.

Talvez encaminhar uma exceção para um humano.

Talvez não fazer nada.

A inteligência está na continuidade.

Uma interação isolada pode parecer ótima.

Uma operação só pode ser considerada boa quando a sequência das decisões produz resultado.

O livro-caixa operacional

Existe uma forma bastante simples de pensar nisso.

Empresas conhecem muito bem a ideia de livro-caixa.

No final, existe uma realidade bastante objetiva: dinheiro entrou ou não entrou.

Mas olhar apenas para o caixa mostra o resultado final.

Não mostra necessariamente o caminho.

Em uma operação governada por agentes, eu quero enxergar também aquilo que poderíamos chamar de um livro-caixa operacional.

O caminho que conecta:

esforço → decisões → eventos → próxima ação → resultado → caixa

Isso tem uma importância enorme.

Porque duas operações podem produzir exatamente o mesmo resultado financeiro consumindo quantidades completamente diferentes de esforço.

Uma pode ter feito dez contatos.

Outra, cem.

Uma pode ter utilizado um canal barato.

Outra, vários canais caros.

Uma pode ter concedido 5%.

Outra, 14,99%.

O valor recuperado sozinho não explica a qualidade da operação.

É por isso que, no OrqOS, olhamos para duas dimensões que precisam conversar o tempo todo:

funil de esforço

e

funil de resultado.

O primeiro mostra o que a operação precisou fazer.

O segundo mostra o que ela conseguiu produzir.

A relação entre os dois é onde começamos a entender eficiência.

E a trilha auditável é justamente o elo entre eles.

Se consigo enxergar apenas o dinheiro que chegou ao caixa, conheço o resultado.

Quando consigo reconstruir as decisões e os eventos que produziram aquele dinheiro, começo a conhecer a operação.

Aprender não significa mudar as próprias regras

Aqui voltamos a um princípio que considero essencial.

Um agente pode aprender que determinado horário funciona melhor.

Pode perceber que um canal é mais eficiente.

Pode identificar que uma determinada sequência de ações não vale o esforço.

Pode encontrar padrões que nenhum operador humano perceberia facilmente.

Pode inclusive mostrar que uma regra criada pela própria organização está prejudicando o resultado.

Tudo isso é extremamente valioso.

Mas existe uma diferença entre aprender dentro de uma política e mudar a política.

Se os eventos mostrarem que aumentar uma alçada de 15% para 20% poderia melhorar determinada métrica, o agente pode identificar isso.

Pode apresentar a evidência.

Pode recomendar a mudança.

Mas não deveria simplesmente concluir:

“Minha performance seria melhor com 20%. A partir de agora minha alçada é 20%.”

É aí que entra novamente o human in the loop.

O aprendizado pode ser da máquina.

A autoridade para alterar determinadas regras continua sendo humana.

Essa separação não reduz a capacidade do agente.

Ela permite que confiemos mais nele.

Auditoria não é apenas olhar para trás

Existe uma visão de auditoria muito associada a incidentes.

Algo deu errado.

Agora precisamos descobrir o que aconteceu.

Claro que essa função continua sendo fundamental.

Quando uma decisão produz uma consequência indesejada, precisamos ser capazes de reconstruir seu caminho.

Mas acredito que, com agentes de IA, auditabilidade pode ter uma função muito mais ampla.

Ela pode ajudar a operação a melhorar.

Cada decisão gera eventos.

Cada evento produz informação.

Cada resultado permite comparar expectativa e realidade.

Essa informação alimenta a próxima decisão.

E, ao longo do tempo, começamos a construir algo muito mais interessante do que um arquivo de logs.

Construímos uma operação capaz de aprender com aquilo que executa.

Uma decisão correta também precisa ser auditável

Existe ainda uma armadilha.

Quando o resultado é bom, normalmente ninguém pergunta o que aconteceu.

O cliente respondeu.

O acordo foi fechado.

O dinheiro entrou.

Ótimo.

Seguimos em frente.

Mas uma operação que só investiga decisões ruins perde metade do seu aprendizado.

Precisamos saber também por que as decisões boas funcionaram.

Qual sequência foi eficiente?

Qual informação foi determinante?

Qual política produziu o resultado?

Qual Next Best Action foi decisiva?

Se conseguimos responder essas perguntas, começamos a transformar sucesso ocasional em conhecimento operacional.

Por isso, uma decisão correta sem trilha de evidência continua sendo uma decisão pouco útil para um sistema que pretende aprender.

Da evidência para a próxima decisão

No primeiro texto desta série, escrevi que quanto mais arquitetura, regras e governança construirmos, maior será a autonomia que poderemos entregar à inteligência artificial.

A auditabilidade é uma consequência direta disso.

Se damos autonomia para um agente executar, precisamos conseguir reconstruir sua execução.

Mas existe um passo seguinte.

Essa reconstrução também pode servir para torná-lo melhor.

É aí que governança, observabilidade e inteligência começam a se encontrar.

A governança define o espaço autorizado.

O agente executa.

Os eventos registram o que aconteceu.

O resultado mostra se aquela estratégia funcionou.

O sistema aprende.

A próxima ação melhora.

E, quando o aprendizado aponta para uma mudança de regra, alçada ou autoridade, o humano volta ao circuito.

Não para apertar “OK” em cada clique.

Mas para continuar governando aquilo que a máquina pode ou não pode fazer.

Talvez seja essa a evolução mais interessante da auditoria em sistemas de inteligência artificial.

Não apenas responder:

“O que aconteceu?”

Mas conseguir responder também:

“O que aprendemos com isso — e o que devemos fazer agora?”

Charles Duek

Relacionadas: Governed AI Operations · quando a IA deixa de responder e começa a decidir · o recorte legal e vertical em recuperação de crédito.