Soluções · Serviços financeiros
Numa organização financeira, um agente útil não dá conselhos e não aprova nada: lê documentos e transações, enquadra-os numa categoria de um conjunto fixo, diz quão seguro está e pode responder «não sei». O resto — a decisão, a aprovação, a política — fica com as pessoas.
Oferta, com condiçõesNão escrevemos «entregue», porque não temos um agente deste tipo em produção אצל um cliente do setor financeiro. O que temos, e mostramos exatamente como tal, é uma conduta própria de ingestão que corre com os nossos dados: cinco módulos Python, 1.526 linhas, que leem notificações bancárias por e-mail e extratos em PDF, classificam cada transação através de ferramentas e escrevem-na em PostgreSQL com deduplicação, além de quatro fluxos de automação para webhooks de três processadores de pagamentos. O estado real, dito na mesma frase: o repositório não está sob git, os diretórios `tests/` e `webhook-server/` estão vazios, e a correspondência aproximada de nomes de contrapartida usa uma heurística de n-gramas marcada no código como «a substituir por um serviço de embeddings antes da produção». A parte de plataforma financeira em produção — fluxo de pedido, contrato, gráfico de pagamentos, auditoria — é um trabalho separado, com as suas provas, e aí escrevemos «entregue».
Os pedidos de agentes AI em serviços financeiros vêm quase sempre na forma de «responder aos clientes a perguntas sobre os nossos produtos». É um pedido legítimo, mas não é aí que se ganha tempo. O tempo perde-se noutro lado: alguém abre diariamente dezenas de notificações bancárias e de extratos, olha para uma descrição do tipo uma cadeia de maiúsculas com um código e decide se é um recebimento de um cliente, um salário, um imposto, uma prestação a um credor ou uma despesa operacional. Esse trabalho é repetitivo, aborrecido e, precisamente por isso, cheio de erros.
Um modelo linguístico é bom nisso, com uma condição: não lhe ser pedido para escrever uma resposta em texto livre. Se lhe pedir uma frase, você vai fazer o parsing, e o parsing vai sair errado. No nosso pipeline, o modelo não escreve: recebe sete ferramentas e tem de chamar exatamente uma — recebimento de um cliente, salário, imposto, pagamento a um credor, despesa operacional, comissão bancária ou desconhecido. Cada ferramenta pede, além do nome da contraparte ou da categoria, um score de confiança entre 0 e 1. «Desconhecido» pede um motivo escrito. A saída é uma estrutura, não uma opinião.
A segunda regra é que nada entra duas vezes. Cada transação extraída de uma notificação ou de um extrato recebe um identificador externo calculado como um prefixo de 16 caracteres de uma impressão SHA-256 sobre os seus campos, a coluna é única na tabela, e a inserção faz-se com `ON CONFLICT (external_id) DO NOTHING`. A consequência prática: a caixa de correio pode ser lida quantas vezes quiser, e o saldo não duplica. Sem esta regra, qualquer pipeline de ingestão financeira acaba, na terceira semana, a produzir duplicados que alguém limpa manualmente.
O que um agente assim não faz, e por que é importante escrever isso na página: não aprova um pagamento, não toma uma decisão de crédito, não dá recomendações de investimento e não responde ao cliente em nome da instituição. O score de confiança que devolve é a avaliação do modelo sobre si próprio, não uma medição de exatidão feita por nós — essa distinção é a diferença entre uma ferramenta e uma ilusão de controlo.
Qué incluye
As notificações são lidas da caixa de correio por IMAP, os extratos a partir de PDF. Cada transação recebe um identificador externo da fingerprint SHA-256 sobre os seus campos, a coluna `external_id` é `NOT NULL UNIQUE` na tabela, e a inserção é feita com `ON CONFLICT (external_id) DO NOTHING`, com registo separado para a linha inserida e para a ignorada como duplicado. A releitura da mesma caixa não produz nenhum duplicado.
Sete ferramentas, não texto livre: recebimento de um cliente, salário, imposto, pagamento a um credor, despesa operacional, comissão bancária, desconhecido. O modelo tem de chamar apenas uma. As primeiras seis pedem obrigatoriamente, além do nome ou categoria, um score de confiança entre 0,0 e 1,0, declarado no esquema da ferramenta; a sétima pede um motivo. O modelo usado é declarado no código, não escondido na configuração.
Um classificador que não pode dizer «não sei» vai classificar mal, com alta confiança, precisamente as transações invulgares — ou seja, as que importam. Por isso a ferramenta de desconhecido está tão disponível como as outras e pede um motivo escrito, que vai para a linha. As linhas desconhecidas são a lista de trabalho do humano, não uma falha do sistema.
A mesma empresa aparece nos extratos com três grafias. Por cima da classificação existe uma correspondência por semelhança cosseno entre vetores. Dizemos exatamente o que são esses vetores hoje: uma heurística de n-gramas de caracteres, escrita no código com o comentário de que para produção deve ser substituída por uma chamada real a um serviço de embeddings. Funciona para variações de escrita; não é uma correspondência semântica.
Quatro fluxos de automatização, um para cada um dos três processadores de pagamentos e um de reconciliação diária, com 7 a 10 nós cada. A ideia de arquitetura é que as fontes diferentes — e-mail, PDF, webhook — não produzem três tabelas que depois têm de ser conciliadas, mas sim linhas na mesma tabela, com a mesma regra de desduplicação.
As chamadas passam por um gateway próprio em `api.megapromoting.com/v1`, com 44 modelos configurados, cada um com custo por token e limite de contexto. A chave de projeto tem lista branca de modelos, orçamento e período, pode ser rodada mantendo o histórico, e o consumo é consolidado diariamente por utilizador × chave × modelo. O detalhe que surpreende toda a gente: os modelos de raciocínio produzem passos internos que o sistema de seguimento não vê, mas o fornecedor fatura-os — portanto, o orçamento bruto por chave é definido abaixo do teto desejado.
Para os passos que não exigem um modelo grande — a extração de campos de um formato conhecido, a correspondência de nomes, as verificações de coerência — não é preciso qualquer fornecedor externo; é código normal. O modelo é chamado apenas para a etapa de enquadramento. Quando a tua política proíbe a saída de dados, a questão é o que é enviado ao modelo, não se usa IA: pode enviar-se a descrição da transação sem os identificadores da conta.
Não aprova um pagamento e não executa uma transferência. Não toma a decisão de concessão de crédito — as regras, os limiares e a aprovação são da política da instituição. Não dá recomendações de investimento e não responde ao cliente em teu nome sem um fluxo separado de aprovação. E não te garante a exatidão: o score de confiança é a saída do modelo sobre si próprio, não uma medição independente.
Traseul
A primeira entrega não é um agente, mas sim uma lista: as categorias em que pode enquadrar, que campos obrigatórios pede cada uma, e o que significa «desconhecido» no teu caso. Se a lista não se puder escrever numa página, a tarefa não é adequada para um agente — e é mais barato saber isso agora.
A leitura de e-mail, PDF ou webhook, a extração de campos, o cálculo do identificador externo e a escrita na base são feitos e verificados sem qualquer chamada a um modelo. Entregamos um pipeline que ingere corretamente e não duplica. Se esta etapa não for sólida, um modelo por cima dela apenas produz erros mais convincentes.
Por cima do pipeline que funciona, colocamos as ferramentas de classificação e executamos num conjunto de transações reais tuas, com o resultado correto definido pela pessoa que hoje faz o trabalho. Entregamos a tabela com os acordos e desacordos, não uma afirmação sobre a exatidão. O limiar a partir do qual a linha vai para uma pessoa é escolhido a partir dessa tabela.
Chave de projeto com lista branca de modelos e orçamento, consolidação diária do consumo, registo com a ferramenta chamada e a pontuação, e um gate que envia para uma pessoa tudo o que está abaixo do limiar ou é desconhecido. Entregamos os acessos, o documento de entrada em funcionamento e a lista escrita do que o agente faz sozinho e do que não faz.
Os dados
As regras diferem de setor para setor. Estas são as que se aplicam nos serviços financeiros.
Un caso
A situação
As notificações bancárias e os extratos mensais chegavam a uma caixa de correio e eram lidos por uma pessoa, que os classificava por categorias. A primeira versão evidente — um script que lê a caixa e escreve na base — tem um problema que só se vê na terceira semana: em qualquer reinício ou releitura, as mesmas transações entram de novo.
Qué construimos
Escrevi cinco módulos, 1.526 linhas de Python: dois analisadores de notificações via IMAP, um extrator de extratos PDF, o classificador por ferramentas e a escrita em PostgreSQL. A regra central é o identificador externo — um prefixo de 16 caracteres de uma impressão SHA-256 sobre os campos da transação — com a coluna única na tabela e inserção `ON CONFLICT DO NOTHING`. A classificação não devolve texto: o modelo chama uma das sete ferramentas, com pontuação de confiança obrigatória, e «desconhecido» exige motivo.
Qué salió
A caixa de correio pode ser relida a qualquer momento, e as linhas já processadas são ignoradas e assinaladas como duplicado no registo. As transações que o modelo não consegue enquadrar surgem como lista de trabalho, com o motivo ao lado, em vez de serem empurradas para uma categoria para parecer que tudo correu bem.
Qué no dice el caso
É um pipeline interno, não um sistema entregue a um cliente financeiro: não está sob git, os diretórios de teste estão vazios, e o correspondência aproximada de nomes usa uma heurística de n-gramas que o código marca explicitamente como provisória. Descrevi-o aqui porque mostra o método, não porque seja um produto.
Perguntas
Não, e isso não é uma limitação técnica que iremos ultrapassar na próxima versão. A aprovação é uma decisão com consequências jurídicas, que pertence a uma pessoa autorizada da instituição. O agente prepara: enquadra, preenche, assinala o que não corresponde. Um sistema que aprova sozinho teria de poder responder perante um controlador, e uma pontuação de confiança não é uma resposta.
Não pela pontuação de confiança — essa é a avaliação que o modelo faz de si próprio, não uma medição. Sabe-se pela comparação com as decisões da pessoa que faz o trabalho hoje, num conjunto de transações reais, feita antes de pôr algo em regime automático. O resultado dessa comparação é uma tabela que entregamos, incluindo as linhas em que o agente errou.
Chame a ferramenta de «desconhecido» e escreva o motivo. A linha vai para a lista de trabalho do operador, não para uma categoria escolhida ao acaso só para parecer que o sistema funcionou. Um classificador sem saída de «não sei» erra exatamente onde o erro custa: nas transações invulgares.
Não. Cada transação tem um identificador externo calculado como fingerprint sobre os seus campos, a coluna é única, e a inserção usa `ON CONFLICT (external_id) DO NOTHING`. A linha ignorada é registada no log como duplicada, portanto vê-se que foi relida.
Para a etapa de enquadramento, sim: a descrição da transação e o montante vão para o modelo escolhido, através do nosso gateway, com chave de projeto, lista branca de modelos e orçamento. Os restantes passos — leitura, extração, deduplicação, correspondência de nomes — são código comum e não saem para lado nenhum. O que pode sair é definido por escrito antes, não se descobre pelos logs depois.
Sim, é um dos módulos da pipeline. O que importa saber é que um extrato em PDF é um formato frágil: lê-se de acordo com a estrutura que o respetivo banco produz, e quando o banco altera o modelo, o módulo tem de ser ajustado. Por isso, escreve-se com verificações que falham de forma ruidosa, não que adivinham.
Porque a nossa regra exige pelo menos duas implementações próprias para escrever «entregue», e a pipeline descrita aqui corre com os nossos dados, não em produção אצל um cliente do setor financeiro. Também tem lacunas que nomeamos: não está em git, não tem testes, e a correspondência de nomes usa uma heurística marcada no código como provisória. Quando pudermos citar duas implementações em clientes, mudamos a palavra.
Três coisas: a lista fechada das categorias em que pode classificar, um conjunto de transações reais com a resposta correta dada pela pessoa que faz hoje o trabalho, e a decisão escrita sobre que campos podem sair da vossa rede. Sem o terceiro ponto não começamos, porque é o único que não se pode corrigir depois.
Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.