O que reconciliar 100 bilhões de transações ensinou sobre confiar em IA em produção
VP de Finance Systems da Moniepoint defende que governança de dados, não benchmark de acurácia, é o que torna um sistema de IA confiável em escala. A comunidade do Hacker News recebeu a tese com ceticismo.
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:
| Teste | A pergunta | Sinal de alerta | |---|---|---| | Triangulação | Mostre a mesma métrica (receita ou MAU) em três dashboards: Finanças, Produto e Board | Se os números divergem e o time gasta dez minutos explicando por que a lógica é diferente, é um 'problema de verdade', não de IA | | Semântica | Quem é dono da definição de 'usuário ativo' ou 'receita'? | Se a resposta é 'depende' ou 'todo mundo mais ou menos sabe', não há governança, há 'opiniões de dados', e IA treinada em opinião é motor de alucinação em alta velocidade | | Post-mortem | Conte a última vez em que seu dado esteve errado. Como você pegou e qual foi a cadeia de custódia da correção? | Quem diz que 'nosso dado nunca está errado' ou não escalou de verdade ou não está olhando |
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
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
