Pensa comigo!

Imagina um produto de reembolso corporativo, que pedidos de até R$ 500 seguem são aprovados automaticamente.

Acima disso, alguém do financeiro precisa olhar antes de liberar.

É uma etapa chata.

O pedido fica parado, o usuário reclama e, na maior parte das vezes, a pessoa abre os comprovantes, confere algumas informações e clica em aprovar.

Hoje existe uma oportunidade bastante óbvia de colocar IA aí.

Um modelo consegue ler a solicitação, extrair valores dos comprovantes, comparar o pedido com a política da empresa, identificar inconsistências e organizar tudo para uma decisão.

Se ele já consegue fazer isso, por que continuar esperando alguém clicar em “aprovar”?

Eu provavelmente também tentaria tirar essa pessoa do fluxo.

Só não faria isso antes de descobrir uma coisa:

por que existe aprovação acima de R$ 500?

Pode ser uma regra antiga que ninguém teve coragem de remover.

Pode ser uma exigência contábil.

Pode ter surgido depois de uma fraude.

Pode ser que pedidos acima desse valor tenham um padrão de risco completamente diferente.

Para quem olha o fluxo hoje, todas essas histórias têm a mesma aparência:

uma etapa manual irritante.

É por isso que gosto da ideia que ficou conhecida como Cerca de Chesterton.

Antes de tirar a cerca, descubra quem colocou

G.K. Chesterton propôs uma provocação simples.

Você encontra uma cerca no caminho e não entende por que ela está ali.

Não saber a função da cerca ainda não é uma boa razão para removê-la.

Primeiro descubra por que alguém se deu ao trabalho de construí-la.

Depois, se a razão não existir mais, derrube.

Isso vale bastante para software.

Uma segunda aprovação.

Um limite de valor.

Uma permissão esquisita.

Um campo obrigatório.

Uma espera de algumas horas.

Uma revisão manual.

Algumas dessas coisas são puro entulho.

Outras são proteções tão antigas que ninguém mais lembra do problema que as criou.

E aí acontece uma injustiça curiosa.

Quanto melhor a proteção funciona, menos visível fica sua utilidade.

Se durante três anos ninguém conseguiu fazer determinado tipo de fraude por causa daquela aprovação, daqui a pouco alguém olha para o histórico e conclui:

“Viu? Nunca tivemos fraude. Essa aprovação não serve para nada.”

Talvez.

Ou talvez essa seja justamente a razão de nunca ter acontecido.

Tirar a pessoa não significa tirar a regra

Volta para o nosso reembolso.

Depois de investigar, descobrimos que a aprovação acima de R$ 500 existe porque determinados tipos de despesa exigem uma checagem adicional.

Ótimo.

Isso não significa que precisamos manter alguém fazendo a checagem manualmente para sempre.

Talvez a pessoa possa sair.

A regra, não.

Se a condição é objetiva, eu não entregaria essa decisão ao LLM.

Transformaria aquilo em um deterministic gate.

O nome é técnico. A ideia não.

É uma porta do sistema que só abre quando condições explícitas forem satisfeitas.

Por exemplo:

valor > R$ 500 + categoria sensível = aprovação obrigatória

A IA pode fazer o trabalho em volta.

Ler o comprovante.

Extrair o valor.

Identificar a categoria.

Consultar a política.

Apontar inconsistências.

Montar uma recomendação.

Mas uma regra que a empresa considera inegociável não precisa depender da interpretação probabilística de um modelo.

Essa separação é importante.

Modelos de linguagem são ótimos para lidar com linguagem, ambiguidade e contexto.

Código continua sendo muito bom em fazer exatamente o que foi mandado.

Não existe prêmio por usar IA nas duas coisas.

A política também precisa estar em algum lugar

Agora aparece outra situação.

A regra não é simples.

Existe uma política de reembolso com quarenta páginas, várias categorias, exceções por país e atualizações frequentes.

A pessoa do financeiro sabia navegar nisso porque fazia todos os dias.

O agente vai precisar saber também.

Aí pode fazer sentido usar RAG, fazendo o sistema buscar a parte relevante da política antes de o modelo analisar aquele pedido.

Em vez de confiar no que o modelo “lembra”, entregamos a ele a regra aplicável naquele momento.

Isso já melhora bastante a arquitetura.

Mas ainda existe outra pergunta:

o que esse agente pode fazer depois que termina a análise?

Porque ler um comprovante e transferir dinheiro são duas competências bem diferentes.

Não entregue o molho de chaves inteiro

Um agente que analisa reembolsos talvez precise consultar pedidos, acessar comprovantes e buscar políticas.

Até aí, tudo certo.

Isso não significa que ele precise conseguir liberar qualquer valor.

Na prática, podemos limitar as ferramentas e permissões disponíveis para ele.

É o que aparece em conceitos como tool scopes e permissions.

Em português normal: entregamos somente as chaves das portas que ele realmente precisa abrir.

Ele pode consultar.

Pode classificar.

Pode preparar.

Talvez consiga aprovar automaticamente uma faixa de baixo risco.

Acima de determinado valor ou diante de uma exceção, a ferramenta de pagamento simplesmente não está disponível sem outra autorização.

Isso é bem diferente de escrever no prompt:

“Por favor, nunca aprove valores elevados sem ter certeza.”

Uma instrução depende do comportamento do modelo.

Uma permissão bem desenhada depende da arquitetura.

Eu prefiro não pedir educação quando posso simplesmente trancar a porta.

E se descobrirmos que a aprovação não protege nada?

Melhor ainda.

Imagina que, depois de investigar, aparece isto:

A regra foi criada oito anos atrás por uma limitação do sistema antigo.

Essa limitação não existe mais.

A aprovação demora dois dias.

99,8% dos casos passam.

Não existe requisito regulatório.

Não existe mudança relevante de risco.

Ninguém consegue apontar uma única decisão que aquela etapa tenha mudado nos últimos meses.

Eu não construiria um agente para aprovar mais rápido.

Eu apagaria a aprovação.

Essa possibilidade ficou mais importante agora porque automatizar trabalho ficou muito mais barato.

E quando automatizar fica barato, aparece uma tentação estranha:

manter processos ruins porque agora conseguimos executá-los com tecnologia melhor.

Um fluxo com oito etapas desnecessárias não fica inteligente quando ganha um agente.

Fica só mais rápido.

Tem um tipo de contexto que não está no banco de dados

Antes de mexer num fluxo antigo, eu procuraria algumas coisas.

Quando essa etapa nasceu?

O que aconteceu antes dela existir?

Que tipo de caso ela intercepta?

O que já deu errado quando alguém pulou?

Existe alguma exceção que só quem trabalha ali conhece?

Essas perguntas podem parecer arqueologia organizacional.

Na prática, elas acabam descobrindo requisitos.

Às vezes a regra está numa política e pode ser recuperada pelo sistema.

Às vezes é objetiva e pode virar código.

Às vezes precisa continuar sob uma permissão específica.

E às vezes alguém diz:

“Quando aparece esse tipo de comprovante eu sempre olho uma coisa a mais. Anos atrás tivemos um problema enorme com isso.”

Essa frase é valiosa.

Não é necessariamente resistência de quem está com medo de ser automatizado.

Pode ser uma parte da arquitetura que nunca chegou à documentação.

Antes de remover a pessoa, eu quero descobrir o que ela sabe que o sistema ainda não sabe.

Depois disso, automatizar fica muito mais interessante.

Porque a pergunta deixa de ser:

“A IA consegue fazer essa etapa?”

Hoje a resposta para muita coisa é sim.

Eu prefiro outra:

“Se essa etapa desaparecer amanhã, o que precisa continuar existindo?”

Pode ser uma regra.

Uma política.

Uma permissão.

Um julgamento raro.

Ou absolutamente nada.

Nesse último caso, ótimo.

Derruba a cerca.

Só não automatiza a cerca primeiro.