O que reconciliar 100 bilhões de transações ensinou sobre confiar em IA em produção

Wole Olorunleke, VP de Finance Systems da Moniepoint, publicou um texto sobre o que aprendeu construindo os sistemas que reconciliam mais de 100 bilhões de transações da fintech na Nigéria e no Reino Unido. A tese central: a confiabilidade de um sistema de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → em produção não vem do modelo, vem da governança dos dados que estão embaixo dele. O texto nasceu de um painel no evento AI Everything MEA, no Cairo, onde ele era o único operador entre investidores e um jornalista.

O ângulo interessa a quem constrói software no Brasil por um motivo concreto: fintechs, bancos digitais e qualquer produto que rode scoring de crédito, previsão de churn ou análise de fraude sobre dados transacionais enfrentam exatamente o problema descrito, com ou sem IA generativa envolvida.

O problema do 'usuário ativo' que quebra o modelo

O exemplo que abre o texto é o mais didático. Numa instituição financeira, o sistema debita automaticamente a tarifa de SMS no início do mês e credita juros para o período (se as condições forem atendidas). São transações geradas pelo próprio sistema: o cliente não abriu o app, não transferiu, não comprou nada.

Se a definição de 'usuário ativo mensal' (MAU) for 'qualquer cliente com ao menos uma transação', esses clientes dormentes aparecem como ativos. O resultado, segundo Olorunleke:

• Marketing reporta MAU alto para o board.
• Produto vê baixo engajamento, porque o ticket médio despenca ao misturar ativos reais com dormentes.
• Finanças vê um terceiro cenário, já que rastreia atividade que gera receita, e nenhuma das duas transações gera.

Três times. O mesmo dado subjacente. Três histórias diferentes.

O ponto que importa para IA: se você treina churn, scoring de crédito ou personalização em cima desse dado, o modelo herda a confusão. Ele trata um cliente dormente com débito de SMS como se transacionasse todo dia. Nas palavras do autor, "não é um problema de modelo. O modelo está fazendo exatamente o que você mandou. É um problema de governança."

Governança que nasceu de restrição, não de estratégia

O relato mais útil do texto é que a Moniepoint não desenhou governança por visão de futuro, e sim por limitação operacional. Na Nigéria, segundo o autor, a maioria dos bancos não tem APIs capazes de suportar o volume que a fintech processa, então extratos precisavam ser carregados manualmente no sistema de reconciliação.

Isso cria um problema de confiança imediato: se quem sobe o extrato é quem aprova, não há verificação. A solução foi um sistema maker-checker, em que quem carrega não pode ser quem aprova. A partir daí, o princípio se espalhou por toda a arquitetura.

O conceito que sustenta o resto é a cadeia de custódia completa (chain of custody) de cada transação. Quando o sistema reconcilia automaticamente, ele registra não só o match, mas qual pipeline tomou a decisão, com qual lógica e quem construiu esse pipeline. Se um engenheiro de dados criou a lógica de tagging e ela classificou uma transação de determinado jeito, dá para rastrear de volta: este resultado existe por causa deste pipeline, feito por esta pessoa, com esta lógica.

É esse desenho, nascido da precariedade de infraestrutura, que hoje coincide com o que reguladores pedem em governança de IA, rastreabilidade e supervisão humana.

Por que a camada conversacional só funciona com governança embaixo

Outro trecho concreto: quando o time financeiro cresceu, a solução default foi 'todo mundo aprende SQL↳SQL64 conteúdosSQL Server – Como evitar SQL Injection?Data · mai 2019Azure SQL DB Managed InstanceData · abr 2019SQL Server – Como evitar SQL Injection? Pare de utilizar Query Dinâmica como EXEC(@Query)Data · abr 2019Ver tudo em Data →'. Funcionou por um tempo, e depois virou o mesmo problema do MAU multiplicado, dez analistas escrevendo queries com lógica ligeiramente diferente contra os mesmos dados e chegando a números ligeiramente diferentes. Profissionais de finanças viraram táticos, gastando horas com joins e descobrindo qual das três tabelas tinha a receita certa, em vez de estratégicos.

A resposta não foi ensinar SQL para mais gente, e sim construir uma camada onde o dado já está governado e definido. Em cima disso, uma interface conversacional em que alguém pergunta "qual a receita deste mês por entidade?" em linguagem natural e recebe uma resposta confiável. O autor é enfático:

A governança não é uma feature da IA. A governança é o que torna a IA possível. Sem ela, uma interface conversacional é só um chatbot escrevendo SQL ruim mais rápido.

O 'audit do operador': três perguntas para testar governança

A parte mais aproveitável para quem avalia (ou constrói) um sistema de IA sobre dados são as três perguntas que Olorunleke propõe, com o alerta de ignorar o pitch deck e o benchmark de acurácia:

O autor admite que a própria Moniepoint não terminou a jornada: as capacidades de IA nasceram em silos (o time de Finance Systems entre os primeiros), funcionam em produção e processam dinheiro real, mas não compõem entre si. Agora vem o trabalho mais difícil, centralizar definições e padrões num framework de dados corporativo. A frase que ele disse no painel: "a maioria das empresas vende a Fase 3 vivendo na Fase 1. Nós estamos firmemente na Fase 2: construindo a fundação."

A comunidade não comprou a narrativa

O thread no Hacker News foi majoritariamente cético, o que vale registrar como contraponto (é opinião de leitor, não fato apurado).

Boa parte das reações atacou a forma antes do conteúdo, a começar pelo scroll customizado do site. No thread, marcwieserdev foi direto: "I loaded the site, saw the scroll, closed the page. I won't read your content, you have no credibility to my eyes because of your horrible UX↳UX33 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025UX, IA e Front-End: quando experiência, inteligência e código se encontram para criar o futuro digitalProduto & UX · jul 2025Novidades em UX/UI para 2025: O futuro do design de experiências digitaisProduto & UX · abr 2025Ver tudo em Produto & UX →."

A crítica mais substantiva veio de oefrha, que questionou a coerência técnica do argumento sobre rastreabilidade:

AI writing aggregate SQL queries ("what is this month's revenue by entity?") is completely reliable because every tx is traceable, but wouldn't be reliable if every tx is not traceable, seriously?

oefrha

Nem todos descartaram a tese. pjc50 achou o argumento válido: "The underlying thesis is interesting too as a financial pitch to increase traceability. Some subtle digs at the .. less honest methodologies sometimes used in front of investors."

O que fica para o dev brasileiro

Retirando o barulho sobre o design da página, o núcleo do texto sobrevive a um recorte prático: antes de plugar qualquer modelo em cima de dados transacionais, vale rodar o 'teste da triangulação' internamente e verificar se três áreas chegam ao mesmo número a partir da mesma fonte. Um pipeline de scoring ou antifraude que herda definições conflitantes de 'ativo', 'receita' ou 'cliente' não tem problema de modelo, tem problema de dado, e nenhum tuning resolve isso.

O que fica em aberto é justamente o que a comunidade cobrou: a rastreabilidade determinística descrita (registrar pipeline, lógica e autor de cada match) é boa engenharia de dados, mas não é exclusiva de IA nem prova, por si só, que os modelos em cima dela sejam confiáveis. É uma condição necessária, não suficiente.

Fontes: Hacker News · Reações no Hacker News