A semana passou e, no noticiário carioca, um caso chamou a atenção: um homem foi indiciado por estelionato sentimental depois de usar um aplicativo de namoro para aplicar golpes em ao menos sete mulheres, recebendo valores via Pix. A história é triste, envolve quebra de confiança e prejuízo financeiro real. Mas, como engenheiro de software que já lidou com sistemas de pagamento, autenticação e plataformas sociais ao longo de 15 anos, o que me salta aos olhos não é a malícia do indivíduo — ela sempre existiu. O que me preocupa é como a arquitetura técnica dos produtos digitais que usamos diariamente está configurada para ser conivente com esse tipo de crime.
Não estou falando de culpa penal, mas de responsabilidade de design. Quando uma plataforma de namoro permite que perfis maliciosos criem contas sem verificação robusta, e quando o sistema de pagamento instantâneo do país opera com transferências irreversíveis e sem qualquer ancoragem contextual, estamos diante de um ecossistema que facilita a fraude em escala. A pergunta que todo engenheiro de produto deveria fazer é: como tornar a confiança um elemento programável e não apenas uma expectativa romântica?
O problema não é o aplicativo, é a falta de engenharia de confiança
Muitos colegas desenvolvedores reagem a notícias como essa com um encolher de ombros: "não é culpa da tecnologia, é culpa de quem caiu no golpe". Essa visão é, no mínimo, ingênua. Uma plataforma que movimenta milhões de interações humanas por dia coleta dados comportamentais, de localização, de padrões de mensagem e de conexões. Esses dados podem e devem ser usados para proteger os usuários — mas raramente o são. O motivo? Métricas de negócio focadas em engajamento diário, número de matches e tempo de sessão são priorizadas em detrimento de métricas de segurança. O resultado prático: o estelionato sentimental não é um bug, é um subproduto de um sistema que valoriza a quantidade de interações sobre a qualidade da confiança.
Do ponto de vista técnico, o golpe clássico segue um padrão que deveria ser facilmente detectável por um sistema de heurísticas simples: perfil recém-criado, sem verificação de foto ou documento, poucas conexões mútuas, mensagens com conteúdo emocional intenso e rápido direcionamento para fora da plataforma (WhatsApp, Telegram), seguido de um pedido de transferência financeira emergencial. Se você treinar um modelo de machine learning com esses sinais, a taxa de falso positivo pode ser gerenciável — mas a maioria dos apps de namoro ainda opera com regras de negócio ultrapassadas, como bloquear apenas palavras-chave explícitas.
A anatomia técnica de um golpe sentimental
Vamos detalhar o fluxo técnico que permite o crime. O golpista se cadastra no aplicativo com dados fictícios e, em muitos casos, fotos roubadas de redes sociais ou geradas por inteligência artificial. A plataforma, na ânsia de não criar atrito no onboarding, exige apenas um número de telefone — e olhe lá. Sem validação de identidade forte, sem comprovação de que aquela pessoa real existe, o perfil entra em circulação. Em segundos, o algoritmo de matching já o apresentou a dezenas de pessoas.
Após estabelecer conexão emocional, o golpista pede para migrar a conversa para um canal não monitorado — o que é um sinal clássico de alerta, mas nem sempre endereçado pelo app. Quando a vítima aceita, a plataforma perde completamente a visibilidade do que acontece. Dali em diante, o crime se consolida com um pedido de Pix. O sistema financeiro — lindo em sua eficiência — processa a transação em segundos, sem qualquer análise de risco contextual. Não há nenhum mecanismo que relacione aquele CPF de destino a um perfil de namoro recém-criado. O dinheiro some e a investigação, quando acontece, é posterior e reativa.
Em uma arquitetura ideal, o fluxo de pagamento deveria ser um evento a mais no sistema de detecção de anomalias da plataforma de namoro. Mas isso exigiria que a empresa de namoro e a instituição financeira ou fintech compartilhassem dados — o que levanta questões sérias de privacidade. É um trade-off clássico de engenharia de produto.
Machine learning como barreira — e seus limites
Treinei equipes que implementaram sistemas de detecção de fraude em marketplaces, e o princípio é o mesmo. Podemos usar um classificador binário alimentado por features como: idade da conta, número de matches por dia, velocidade da conversa (tempo entre match e pedido de saída da plataforma), frequência de palavras emocionais, e até análise de sentimento. Ferramentas como BERT ou modelos de linguagem ajustados conseguem identificar padrões de persuasão forçada em mensagens com alta acurácia.
Mas há riscos. O maior deles é o falso positivo: bloquear ou sinalizar um perfil legítimo que apenas tem uma conversa intensa e genuína pode gerar frustração e abandono da plataforma. Por isso, muitos times de produto preferem uma abordagem de "nudge", como exibir um alerta: "Esta conversa apresenta padrões similares a golpes. Confirme se você conhece essa pessoa pessoalmente antes de enviar dinheiro." Esse tipo de intervenção pode reduzir danos sem comprometer a experiência. A questão é que poucas empresas investem nisso, porque o custo de implementação e o impacto no funil de engajamento assustam os gestores.
Outro limite técnico: a latência. Decisões em tempo real exigem inferência rápida — normalmente sub-100ms em produção. Dependendo da arquitetura de infraestrutura, isso pode demandar investimento em GPU e otimização de modelos. Em um mundo pós-moderno de startups enxutas, esse investimento raramente compete com a construção de novas features de gamificação.
O trade-off entre privacidade e segurança
Um ponto que frequentemente é levantado é o dilema entre proteger os usuários e invadir sua privacidade. Se a plataforma começar a monitorar conversas off-app, ou a exigir verificação documental completa, a sensação de vigilância pode afastar usuários. Há ainda a questão legal: a Lei Geral de Proteção de Dados (LGPD) impõe limites claros ao processamento de dados sensíveis, como orientação sexual, crenças e relações interpessoais.
Contudo, existe um meio-termo que muitas plataformas ignoram: a verificação opcional, com recompensa. Oferecer selo de "perfil verificado" para quem enviar selfie com documento, ou usar reconhecimento facial, já reduz drasticamente a probabilidade de golpistas usarem a conta. Isso não é novidade — redes sociais e apps de pagamento fazem isso há anos. Por que apps de namoro resistem? Porque cada etapa de verificação aumenta o abandono no funil de cadastro. É um trade-off cruel entre crescimento e segurança.
Minha opinião técnica, baseada em experiências de arquitetura de sistemas: a verificação deveria ser obrigatória para realizar qualquer ação financeira ou de compartilhamento de dados pessoais dentro da plataforma. O app não precisa saber o CPF de todos desde o início — pode exigir no momento em que o usuário tenta enviar uma foto, um endereço ou iniciar uma conversa fora do app. Isso limita o dano sem comprometer a descoberta inicial. A engenharia de máquina de estados pode tornar essa experiência fluida.
Responsabilidade das plataformas e o papel do engenheiro de produto
O caso com sete vítimas indica que o golpista agiu repetidamente sem ser barrado. Isso significa que a plataforma não tinha nenhum mecanismo de reputação do dispositivo, de travamento de pagamento suspeito, ou de alerta para vítimas potenciais. Em um sistema distribuído bem projetado, quando um mesmo perfil (ou mesmo dispositivo) é reportado por múltiplas usuárias, um gatilho automático deveria pausar aquela conta e forçar revalidação.
O engenheiro de software que trabalha com produtos digitais tem uma responsabilidade que vai além de cumprir requisitos do Product Owner. Precisamos questionar ativamente as métricas de sucesso. Se o time está otimizando "número de matches por dia", podemos estar criando incentivos perversos. Cabe a nós sugerir métricas de "matches seguros" — por exemplo, interações que não geraram denúncia em 48h. Isso envolve instrumentação dos sistemas, coleta de feedback e loops de aprendizado supervisionado.
Há também oportunidades técnicas para construir APIs de prevenção. Imagina um serviço que, ao receber um pedido de Pix, consulta uma base anonimizada de denúncias de estelionato e devolve um risco 0-1. Os bancos e fintechs poderiam integrar isso em tempo real. Já existem sistemas similares para cheques sem fundo e fraudes de cartão — por que não para transferências baseadas em relacionamento? Falta coordenação entre os players do ecossistema, e isso é um problema de engenharia e de governança.
Além do código: o futuro da confiança em plataformas sociais
Estamos caminhando para um mundo onde cada vez mais relações importantes começam digitalmente. Isso não vai parar. O que pode mudar é o nível de maturidade técnica das plataformas em tratar a confiança como um ativo que precisa ser projetado, testado e mantido. Assim como sistema crítico aviônico ou financeiro não pode falhar, plataformas que intermediem afeto e dinheiro precisam de tolerância a abusos.
Se eu estivesse liderando um squads de engenharia em um app de namoro hoje, minhas prioridades seriam: (1) implementar verificação opcional gamificada; (2) criar um pipeline de ML para detecção de padrões de golpe, com explainabilidade para o usuário; (3) estabelecer contratos de dados com provedores de pagamento para análise contextual em tempo real; (4) e, principalmente, colocar no roadmap uma métrica de "fraude evitada" que tenha tanto peso quanto "novos registros".
A fórmula Tinder + confiança + Pix não precisa ser a receita do estelionato. Em vez de culpar as vítimas ou romantizar o crime, temos a obrigação técnica de construir sistemas que dificultem a ação dos maus atores. Como engenheiros, não somos apenas construtores de features — somos arquitetos de confiança. E essa confiança tem que ser programada, testada e monitorada. O código é a nossa ferramenta. Usemos bem.