Quando o algoritmo de matching vira um vetor de ataque
Li o relato da Deutsche Welle sobre brasileiros que foram atraídos por um cidadão alemão via aplicativo de relacionamento e, ao chegar na Alemanha, foram submetidos a trabalho forçado, agressões e privação de liberdade. A primeira reação de qualquer engenheiro de software é buscar o bug na aplicação. Mas aqui o bug não está no código — está no design de confiança que construímos nas plataformas.
O caso ilustra um fenômeno que venho observando há anos: aplicativos de relacionamento, em sua busca implacável por engajamento e retenção, abrem mão de mecanismos robustos de verificação de identidade. O trade-off é conhecido: quanto mais barreiras na onboarding, menor a taxa de conversão. Quanto menos atrito, maior o número de usuários ativos diários — e maior a superfície de ataque para agentes maliciosos.
A plataforma Romeo, mencionada na reportagem, não é exceção. Como muitos concorrentes, ela prioriza a experiência fluida de descoberta sobre a garantia de que cada perfil corresponde a uma pessoa real. O problema estrutural é que, para cada usuário legítimo que encontra um parceiro, existe um predador calculando como explorar a confiança construída dentro do ecossistema digital.
A arquitetura da confiança cega
Quando projeto sistemas de produto, costumo pensar em três camadas de verificação: identidade declarada (o que o usuário diz sobre si), identidade verificada (o que podemos confirmar com documentos ou dados biométricos) e identidade reputacional (o que a rede valida ao longo do tempo). A maioria dos aplicativos de relacionamento opera apenas na primeira camada.
O alemão mencionado no caso não precisou fraudar nenhum sistema sofisticado. Bastou criar um perfil atraente, trocar mensagens por semanas ou meses e construir uma narrativa de oportunidade. O vetor de ataque não foi uma vulnerabilidade técnica — foi a própria dinâmica social que a plataforma incentiva: conexões rápidas baseadas em interesse mútuo, sem camadas de verificação que atrasem o matching.
Para engenheiros de produto, isso levanta uma questão incômoda: até que ponto estamos projetando sistemas que deliberadamente ignoram sinais de risco para não impactar métricas de crescimento? Cada feature de segurança adicionada — verificação por documento, selfie com código dinâmico, vinculação a conta bancária — reduz a taxa de cadastro em algum percentual. E em startups pressionadas por crescimento, esse custo é frequentemente considerado inaceitável.
Os sinais de risco que o sistema ignora
Do ponto de vista de engenharia de dados, o caso é interessante porque existem múltiplos indicadores que um sistema de detecção de anomalias poderia capturar. O perfil do alemão propunha mudança de país em estágio inicial da conversa. Ele oferecia custeio de passagens e moradia — um padrão que foge completamente ao comportamento médio de usuários em apps de relacionamento.
Um modelo supervisionado treinado em dados históricos de denúncias provavelmente classificaria esse padrão como suspeito. O problema é que a imensa maioria das plataformas não coleta esses dados de forma estruturada, não treina modelos para essa finalidade específica e, quando treina, o faz com conjuntos de dados enviesados que sub-representam crimes transnacionais.
Além disso, há um problema de granularidade temporal. O grooming digital — termo que uso para descrever a construção gradual de confiança para exploração posterior — ocorre ao longo de semanas ou meses. Sistemas de moderação modernos são excelentes para detectar spam ou conteúdo explícito em tempo real, mas péssimos para identificar padrões relacionais de longo prazo que culminam em dano. É uma limitação fundamental dos modelos atuais de segurança em plataformas.
A economia política da moderação
Vale a pena examinar os incentivos econômicos. Uma equipe de segurança em uma plataforma de relacionamento típica custa caro: engenheiros de machine learning, moderadores humanos fluentes em múltiplos idiomas, infraestrutura de armazenamento e processamento de denúncias. Para uma empresa que fatura com assinaturas e publicidade, cada real gasto em segurança é um real que deixa de ser investido em features que geram receita.
O resultado é um equilíbrio de Nash perverso: nenhuma plataforma individualmente tem incentivo para investir em segurança mais do que o mínimo legal exigido, porque isso a colocaria em desvantagem competitiva. Usuários escolhem a plataforma com mais usuários e menos atrito, não a mais segura. Até que um escândalo force mudanças regulatórias que afetem todas igualmente.
A Europa, com o Digital Services Act, está começando a mudar esse cenário. A regulação exige que plataformas avaliem riscos sistêmicos — incluindo riscos de exploração humana — e implementem medidas proporcionais. Na prática, isso significa que uma plataforma como o Romeo precisaria demonstrar que está ativamente mitigando o tipo de abuso documentado na reportagem. Mas o DSA ainda é recente, e a fiscalização, incipiente.
O que a engenharia de produto pode fazer
Não sou ingênuo a ponto de acreditar que tecnologia resolve problemas estruturais de exploração humana. A pobreza, a desigualdade de oportunidades e a vulnerabilidade econômica são os verdadeiros preditores de quem será vítima de aliciamento. Mas, como engenheiros, podemos construir sistemas que não facilitem o crime.
Algumas abordagens técnicas que implementaria em produto:
- Verificação federada de identidade: integrar-se a sistemas como o eID europeu ou o Gov.br brasileiro permitiria confirmar que um usuário é quem diz ser, sem depender de selfies ou documentos enviados manualmente. O custo de implementação é alto, mas o benefício de redução de fraudes é mensurável.
- Análise de padrões de conversação: modelos de NLP podem detectar menções prematuras a viagens, dinheiro, moradia ou documentação. Não para bloquear automaticamente, mas para sinalizar perfis para revisão humana. O falso positivo precisa ser tratado com cuidado para não prejudicar interações legítimas.
- Período de aquecimento de matching: impedir que perfis recém-criados enviem mensagens para muitos usuários simultaneamente ou proponham encontros presenciais antes de um número mínimo de interações. É uma restrição que impacta a experiência, mas reduz o vetor de ataque de criação em massa de perfis.
- Criptografia com acesso a metadados para autoridades: em casos de investigação já instaurada, a plataforma precisa ser capaz de fornecer logs de interação para autoridades policiais, respeitando a privacidade dos demais usuários. Isso exige arquitetura de dados que separe metadados de conteúdo, com trilhas de auditoria claras.
Nenhuma dessas medidas é infalível. Um predador determinado pode construir um perfil legítimo ao longo de meses antes de agir. Mas cada barreira adicional aumenta o custo do ataque e reduz a escala de vítimas potenciais.
Um chamado para repensar métricas de sucesso
Enquanto as plataformas continuarem sendo avaliadas por número de matches, mensagens enviadas e tempo de sessão, a segurança será uma variável secundária. O caso dos brasileiros na Alemanha deveria servir como alerta para times de produto repensarem seus OKRs.
Uma métrica que sugiro é o índice de denúncias confirmadas por denúncias totais. Se a plataforma recebe 10 mil denúncias por mês, mas apenas 2% resultam em ação efetiva (remoção de perfil, bloqueio de IP), isso indica que o sistema de moderação está operando com limiares muito altos. Ajustar o modelo para capturar mais denúncias verdadeiras — mesmo ao custo de aumentar falsos positivos — pode salvar vidas.
Outra métrica: tempo entre criação de perfil e primeira denúncia. Se perfis maliciosos conseguem operar por semanas antes de qualquer sinalização, o sistema de detecção proativa está falhando. Modelos de machine learning que identificam perfis suspeitos em minutos após o cadastro já são viáveis tecnicamente.
No fim, a questão não é técnica, mas de prioridade. Temos os algoritmos, a infraestrutura e os dados para detectar padrões de aliciamento. O que falta é a vontade de implementá-los — e de aceitar o impacto nas métricas de crescimento que isso inevitavelmente causará.
Para os profissionais de tecnologia que leem este blog, fica a reflexão: quando você estiver na próxima sprint planning, pergunte ao seu product manager qual é a taxa de denúncias confirmadas da plataforma. Se ele não souber responder, talvez seja hora de adicionar segurança ao backlog — não como feature, mas como requisito fundamental do sistema que você está construindo.