Quando um engenheiro de software define a função de perda de um modelo de machine learning, ele está, na prática, escolhendo qual comportamento humano será otimizado. Essa decisão, muitas vezes escondida em um notebook de Jupyter ou em uma configuração de pipeline de dados, pode ter consequências que vão muito além das métricas de negócio. O caso recente de um empresário que perdeu R$ 100 mil em 72 horas em plataformas de apostas on-line não é apenas mais uma estatística sobre ludopatia. É um sinal de alerta para quem constrói produtos digitais: a mesma arquitetura que entrega personalização eficiente pode ser usada para explorar vulnerabilidades humanas de forma sistemática.
Segundo o portal iG, o empresário Marcelo Silva (nome fictício) descreveu um padrão típico de escalada: começou com apostas pequenas, recebeu bônus promocionais personalizados e, em poucos dias, teve seu comportamento amplificado por notificações push e ofertas direcionadas. Não há acaso nesse processo. Cada etapa foi desenhada por times de produto que utilizam técnicas de gamificação, segmentação comportamental e modelos preditivos para maximizar o valor do jogador. Como engenheiro que já implementou sistemas de recomendação para e-commerce e plataformas de conteúdo, reconheço cada uma dessas peças. A diferença é que, aqui, o "produto" recomendado é uma aposta com alto potencial de ruína.
A arquitetura por trás do vício
Plataformas de apostas esportivas e cassinos on-line operam como qualquer empresa de tecnologia focada em monetização de usuários. Elas coletam dados de navegação, histórico de apostas, horários de acesso, dispositivos utilizados e padrões de clique para alimentar modelos de machine learning. Esses modelos têm um objetivo claro: prever qual usuário está mais propenso a apostar novamente, qual valor máximo ele está disposto a perder em uma sessão e qual tipo de oferta — odds melhoradas, cashback, "free bet" — o trará de volta ao site. A implementação típica envolve um motor de regras em tempo real acoplado a um modelo preditivo. O motor de regras define condições como "se perdeu três apostas seguidas, ofereça bônus de 50% no próximo depósito". O modelo ajusta dinamicamente o valor do bônus com base na elasticidade de demanda do usuário. Tudo orquestrado por sistemas de eventos assíncronos, semelhantes aos usados em plataformas de e-commerce para recomendar produtos. A diferença está no contexto e no impacto.
Em minha experiência liderando a implementação de um sistema de recomendação para um marketplace, aprendi que a escolha da métrica de otimização define o comportamento do sistema. Se otimizamos para LTV (Lifetime Value), o algoritmo tende a incentivar compras recorrentes, mesmo que isso signifique empurrar produtos que o usuário não precisa. Em plataformas de aposta, otimizar para LTV significa incentivar depósitos cada vez maiores e mais frequentes, explorando o viés de "perseguir perdas" (chasing losses). O algoritmo aprende a reconhecer sinais de vulnerabilidade — horários noturnos, aumento na frequência de depósitos, diminuição do valor médio por aposta — e ajusta as mecânicas de engajamento para maximizar a probabilidade de uma nova ação. Cada clique, cada recarga de saldo, cada aposta perdida ou ganha refina o perfil do jogador. Trata-se de um sistema de reforço positivo e negativo calibrado milimetricamente.
Dark patterns que todo engenheiro deveria conhecer
As plataformas de bets incorporam uma série de padrões de design que dificultam a saída do usuário. Como profissional de produto, sei que muitos desses padrões são testados A/B exaustivamente. Entre os mais comuns, destaco:
- Notificações push agressivas: enviadas em momentos de alta probabilidade de resposta — como após uma derrota ou em horários de baixa atividade. São personalizadas por algoritmos que analisam histórico de cliques e podem incluir mensagens como "Você quase ganhou! Tente novamente". A implementação técnica envolve filas de eventos e sistemas de recomendação que disparam notificações com base em janelas de tempo e estados emocionais inferidos.
- Bônus de recarga e cashback condicionais: ofertas que exigem um novo depósito para serem ativadas, muitas vezes com prazos curtos de expiração. A lógica de elegibilidade é implementada como regras no backend, mas a seleção de qual oferta exibir em tempo real é feita por um modelo de ML que considera o perfil de risco do usuário. Esse tipo de bônus explora o viés de aversão à perda, incentivando o jogador a tentar recuperar o que perdeu.
- Gamificação da experiência de perda: animações, sons e mensagens de "quase lá" ou "por pouco" que incentivam o jogador a tentar novamente. Do ponto de vista de engenharia, esses elementos são acionados por triggers baseados em eventos (por exemplo, após uma aposta perdida por margem estreita). São testes A/B constantes para maximizar o tempo de sessão.
Essas mecânicas não são acidentais. São o resultado de experimentação rigorosa e otimização contínua de métricas de retenção. Em produtos financeiramente viciantes, a retenção a curto prazo equivale a dano a longo prazo para o usuário. Ignorar essa natureza é um erro de design, não de uso.
Privacidade e LGPD: o que está em jogo
A Lei Geral de Proteção de Dados (LGPD) impõe limites ao uso de dados pessoais para finalidades que possam causar danos ao titular. A coleta e o processamento de dados comportamentais para induzir apostas compulsivas podem ser enquadrados como uso abusivo, especialmente se não houver transparência sobre como os algoritmos operam. No entanto, a fiscalização ainda é incipiente, e as plataformas muitas vezes se protegem com termos de serviço genéricos ou jurisdições estrangeiras. Para engenheiros que trabalham em produtos digitais, a questão prática é: como projetar sistemas que permitam auditoria e prestação de contas?
Uma abordagem que implementei em projetos anteriores é a criação de dashboards de monitoramento de padrões de uso excessivo — por exemplo, alertas quando um usuário faz mais de X depósitos em Y horas. Esses dashboards podem ser usados tanto por equipes de compliance quanto por sistemas automatizados de intervenção. Outra prática é implementar canais de autoexclusão que sejam efetivos, não apenas burocráticos. Um mecanismo de autoexclusão imediato, com confirmação por e-mail e sem possibilidade de reversão por um período mínimo de 30 dias, exige mudanças no backend de autenticação e na lógica de sessão, mas é perfeitamente viável. O que falta, muitas vezes, é a vontade do negócio de reduzir o próprio LTV em prol do bem-estar do usuário.
Também é possível utilizar modelos de IA para detectar sinais precoces de ludopatia, como aumento na frequência de depósitos ou padrões noturnos, e intervir com ofertas de limites de depósito ou pausas obrigatórias. No entanto, isso requer dados rotulados de qualidade, que são escassos. Sem labels, o modelo pode gerar falsos positivos (irritando jogadores casuais) ou falsos negativos (deixando de proteger os vulneráveis). O trade-off entre precisão e recall precisa ser discutido com a equipe de produto e com especialistas em saúde mental.
Decisões técnicas que fazem a diferença
A primeira e mais importante decisão está na escolha das métricas de otimização do modelo. Se a métrica primária for LTV, o algoritmo tenderá a explorar padrões de comportamento aditivo. Se, em vez disso, a empresa adotar métricas como "número máximo de sessões por semana" ou "limite de perda diária" combinadas com intervenções responsáveis, o modelo pode ser treinado para evitar picos nocivos. Essa decisão é estrutural: alterar a função de recompensa muda completamente o comportamento do sistema. Em um projeto que liderei para uma plataforma de conteúdo, trocamos a métrica de "tempo de sessão" por "número de conteúdos consumidos com avaliação positiva". O engajamento caiu 12%, mas a satisfação do usuário subiu 30%. O mesmo princípio se aplica a bets.
Outra decisão crítica é sobre quais dados utilizar na personalização. Usar dados de localização, horário de acesso e histórico financeiro (como valor de depósitos) amplifica a capacidade de predizer a vulnerabilidade do jogador. Mas coletar esses dados sem uma base legal clara ou sem consentimento informado específico para essa finalidade viola a LGPD. Times de engenharia devem trabalhar em conjunto com times jurídicos para definir políticas de dados que evitem o uso predatório, mesmo que isso reduza a eficácia do algoritmo. Em alguns casos, a minimização de dados — ou seja, coletar apenas o necessário para a funcionalidade principal — pode ser a abordagem mais ética e também a mais segura do ponto de vista regulatório.
Riscos e limitações de uma abordagem puramente técnica
Um erro comum é presumir que apenas o usuário é responsável pelo vício. Essa visão ignora o papel ativo da plataforma em condicionar o comportamento. Do ponto de vista técnico, o maior risco é que times de produto tratem a ludopatia como um problema de "mau uso" e não de design falho. Isso leva a medidas superficiais, como avisos genéricos de "jogue com responsabilidade", que não alteram os incentivos do sistema. Outra limitação é a dificuldade de detectar a ludopatia precocemente com modelos de ML. O padrão de jogo recreativo versus problemático pode ser sutil, especialmente nos primeiros meses de uso. Modelos supervisionados exigem dados rotulados de casos confirmados, que são escassos e muitas vezes obtidos apenas após o dano.
Há ainda o risco regulatório. Caso o Brasil avance com uma proibição mais severa de práticas abusivas — como a exigência de limites de depósito ou a proibição de bônus condicionais — empresas que não tiverem implementado controles de responsabilidade estarão expostas a multas e processos. Para engenheiros, isso significa que ignorar o tema não é mais uma opção: a conformidade deve ser incorporada desde a arquitetura do sistema, e não tratada como um checkbox posterior. Em suma, a ética em IA não é um conceito abstrato, mas uma decisão técnica de design de métricas e modelos.
Lições para quem constrói produtos digitais
O primeiro aprendizado é que a função objetivo de um sistema de recomendação define, na prática, que tipo de comportamento será incentivado. Engenheiros que escolhem essa função estão, conscientemente ou não, determinando o impacto social do produto. Portanto, essa escolha deve ser explícita e debatida em time, com participação de designers, cientistas de dados e, idealmente, especialistas em saúde mental. Em segundo lugar, a transparência algorítmica é um requisito de implementação, não um discurso de marketing. Ferramentas como SHAP ou LIME podem ser usadas para mostrar ao usuário por que uma oferta específica foi apresentada. Integrar explicações em tempo real é um desafio técnico factível e pode ser diferenciador. Por fim, a colaboração multidisciplinar é indispensável. Um exemplo prático é estabelecer um teto de depósito diário que não pode ser ultrapassado via alterações de perfil; essa lógica deve ser implementada no backend como uma restrição dura, não como uma sugestão.
O caso do empresário que perdeu R$ 100 mil em 72 horas não é apenas uma tragédia pessoal — é um sintoma de como produtos digitais mal projetados podem acelerar comportamentos destrutivos. A mesma arquitetura que entrega personalização eficiente pode ser usada para explorar vulnerabilidades humanas. Cabe a nós, engenheiros, decidir se seremos ferramentas de valor ou armadilhas de dependência. A escolha começa no design, na escolha das métricas e na coragem de dizer "não" quando a otimização a qualquer custo se torna inaceitável.