Esse julgamento da Meta não é só mais uma notícia do mundo corporativo. Pra quem programa, é um caso sério sobre como decisões de arquitetura e design de produto podem virar problema jurídico — e ético. Vou destrinchar o que está em jogo tecnicamente, por que esse valor de US$ 193 bilhões foi escolhido, e o que devs que constroem sistemas de engajamento precisam aprender com isso agora.
O que está acontecendo no julgamento da Meta
Segundo o Olhardigital.com.br, uma coalizão de estados dos EUA vai pedir US$ 193 bilhões (cerca de R$ 1,05 trilhão) à Meta em um julgamento que começa na próxima terça-feira (18), em Oakland, Califórnia, com duração prevista de seis semanas.
A acusação central é grave: a Meta teria desenvolvido intencionalmente o Facebook e o Instagram para tornar crianças dependentes das redes sociais. Isso não é especulação — são alegações com base em documentos internos vazados por Frances Haugen em 2021, mostrando que a empresa sabia dos efeitos negativos em adolescentes e escolheu não agir.
Se a Meta perder, além da indenização, um juiz poderá determinar mudanças estruturais no funcionamento dos dois apps. E aqui é onde a coisa fica interessante pra nós, devs: estamos falando de obrigar uma empresa a reconstruir features que foram deliberadamente projetadas para reter usuários.
Por que US$ 193 bilhões e não US$ 1,4 trilhão?
Muita gente viu o número de US$ 1,4 trilhão circulando e achou que era o pedido oficial. Não é. Numa audiência na quinta-feira passada (13), o advogado dos estados foi explícito:
“Não pedimos US$ 1,4 trilhão. A Meta calculou essa cifra para causar impacto.”
Do ponto de vista técnico-jurídico, isso faz todo sentido. US$ 1,4 trilhão é um valor que ultrapassa o PIB de vários países e dificilmente seria levado a sério por um juiz. US$ 193 bilhões ainda é estratosférico, mas é plausível porque representa indenização por danos a uma escala populacional enorme — milhões de menores afetados ao longo de anos.
A lição aqui, mesmo pra quem não é advogado: âncoras numéricas infladas prejudicam a credibilidade do pedido. A Meta usou isso a favor dela ao vazar o número absurdo. Cuidado com isso quando estiver estimando impacto em projetos técnicos também — métricas infladas destroem a confiança do stakeholder.
A arquitetura técnica por trás da “viciação”
O que os estados estão efetivamente acusando é que a Meta construiu um sistema de recomendação otimizado para uma métrica errada: tempo de tela em vez de bem-estar do usuário. Isso não é força de expressão — é literalmente o que acontece quando você define a função objetivo do seu modelo.
Na engenharia de sistemas de recomendação modernos, o pipeline básico é:
- Coleta de sinais comportamentais: scroll, pausas, tempo na tela, cliques, comentários, shares.
- Treinamento do modelo: geralmente um modelo de classificação ou ranking (tipo DNN, transformers ou modelos multi-tower) que prevê “probabilidade de engajamento”.
- Serving: ranqueamento em tempo real do feed, escolhendo o conteúdo com maior score previsto.
- Feedback loop: o usuário engaja, gera mais sinal, o modelo aprende a repetir o padrão.
O problema ético surge no passo 3. Quando você otimiza cegamente para “engajamento”, o modelo aprende que conteúdo polarizado, emocionalmente carregado e até depressivo gera mais cliques. Você literalmente treina o sistema a empurrar conteúdo ruim para o usuário. É um anti-padrão de design conhecido como engagement最大化 (engagement maximization) sem guardrails.
Na Prática: um exemplo minimalista do problema
Vou mostrar um pseudo-código em Python pra ilustrar como uma função de ranqueamento “ingênua” pode gerar efeitos adversos. Esse padrão aparece em feeds, sistemas de notificação, sugestões de vídeos — qualquer lugar que ranqueia conteúdo.
import random
from typing import List, Dict
class ContentItem:
def __init__(self, id, emotional_intensity, dwell_time_pred, age_appropriate):
self.id = id
self.emotional_intensity = emotional_intensity # 0.0 a 1.0
self.dwell_time_pred = dwell_time_pred # tempo previsto na tela
self.age_appropriate = age_appropriate # bool
def rank_feed_naive(user_age: int, candidates: List[ContentItem]) -> List[ContentItem]:
"""Versão 'ingênua' — só maximiza tempo na tela."""
return sorted(
candidates,
key=lambda c: c.dwell_time_pred,
reverse=True
)
def rank_feed_responsible(user_age: int, candidates: List[ContentItem]) -> List[ContentItem]:
"""Versão com guardrails — exemplo do que deveria existir."""
scored = []
for c in candidates:
score = c.dwell_time_pred
# Penaliza conteúdo emocionalmente carregado pra menores
if user_age < 18 and c.emotional_intensity > 0.7:
score *= 0.3
# Bloqueia conteúdo inapropriado
if user_age < 16 and not c.age_appropriate:
continue
scored.append((score, c))
return [c for _, c in sorted(scored, key=lambda x: x[0], reverse=True)]
A diferença é simples, mas profunda. A versão rank_feed_naive é o que sistemas como Instagram e TikTok fizeram durante anos. A versão rank_feed_responsible é o mínimo que devs sérios deveriam implementar — e que, claramente, a Meta não fez (ou fez tarde demais).
O detalhe importante: isso não é uma feature “extra”. É uma decisão de modelagem. Se o seu loss function é só engajamento, você está programando o vício.
Comparativo: quem faz melhor (ou menos pior)?
| Plataforma | Métrica principal | Guardrails conhecidos |
|---|---|---|
| Meta (FB/IG) | Time spent, interações | Adicionados depois de pressão pública; auditorias independentes questionadas |
| TikTok | Time spent, watch-through rate | Limite de 60 min para menores (opt-in), mas fácil de burlar |
| YouTube | Watch time, satisfação | Take a Break, limitadores, modo restrito |
| Bluesky | Algoritmo opt-in (Choose Your Algorithm) | Modelo aberto, comunidades podem criar seus próprios ranqueadores |
| Mastodon | Cronológico por padrão | Sem algoritmo de recomendação agressivo por padrão |
Reparem: as plataformas que tiveram mais problemas são justamente as que escolheram feed algorítmico sobre feed cronológico, e que otimizam para tempo de tela como métrica primária. Mastodon e Bluesky mostram que existe outra abordagem. O design não é acidente — é decisão.
Erros Comuns que devs cometem em produtos de engajamento
Na minha experiência construindo e auditando sistemas assim, esses são os deslizes mais frequentes — alguns dos quais podem, daqui pra frente, virar processo judicial:
1. Tratar “engagement” como sinônimo de “valor para o usuário”
Um vídeo que faz o usuário ficar 3 horas rolando o feed pode ter destruído a saúde mental dele. Engajamento é métrica de produto, não de valor.
2. A/B testar features viciantes sem comitê de ética
Se sua empresa testa “notificações push a cada 5 minutos” e mede só retenção, você está fazendo experimentação antiética. Toda empresa de tech deveria ter um processo de review para features de alto impacto psicológico.
3. Vazar dados de pesquisas internas que mostram dano
Foi exatamente o que aconteceu com a Meta. Se sua empresa descobre que uma feature causa dano, documentar isso sem agir é criar evidência para processo. Cuidado com o que fica em e-mails, Slack e Notion.
4. Implementar dark patterns em nome de “engajamento”
Confirmações duplas, cancelamento escondido, scrolls infinitos sem fim visível, badges que fingem urgência — tudo isso é litigável. A União Europeia já multa pesado por isso via Digital Services Act.
5. Confundir personalização com manipulação
Personalização é mostrar conteúdo relevante. Manipulação é esconder o botão de sair, inflar métricas pra gerar FOMO, ou empurrar notificações no horário que você sabe que o usuário é mais vulnerável. A linha é tênue e cada vez mais regulada.
O que muda pra quem trabalha com tech depois desse julgamento?
Se a Meta perder e for obrigada a mudar a arquitetura do feed, isso cria um precedente global. Empresas menores que estão construindo produtos similares — redes sociais, apps de namoro, jogos com mecânicas de retenção — vão precisar revisar seus modelos. Profissionais que entendem por que um sistema é desenhado de determinada forma e conseguem auditar eticamente serão cada vez mais valorizados.
Na minha rotina de consultoria, já atendo clientes pedindo auditoria de “engagement loops” antes de lançar produto. Isso é tendência real, não modismo.
FAQ — Perguntas que devs realmente fazem
O valor de US$ 193 bilhões tem chance real de ser pago?
Improvável que seja pago integralmente, mesmo que a Meta perca. Historicamente, tribunais reduzem indenizatórias. Mas o precedente é o que importa — abre porta para outras ações coletivas, especialmente em estados e países que copiam a legislação americana.
Como esse caso afeta devs que trabalham na Meta agora?
Diretamente, é um risco de reputação no currículo. Indiretamente, pode mudar os OKRs e métricas que você recebe. Prepare-se para defender por que determinada feature foi implementada — e tenha registro de decisões técnicas documentadas.
Vale a pena implementar guardrails mesmo sem pressão regulatória?
Vale. Além de reduzir risco jurídico, produtos com métricas responsáveis têm usuários mais leais e menor churn de longo prazo. É investimento, não custo.
Esse tipo de processo pode chegar ao Brasil?
Já está chegando. O PL 2630/2020 (PL das Fake News) tem dispositivos sobre transparência algorítmica. Processos coletivos por vício digital em menores também já existem em varas de infância e juventude.
Existe certificação ou framework pra auditar ética algorítmica?
Sim. Vale conhecer o OECD AI Principles, o ISO/IEC 23894 e a AI Bill of Rights americana. São referências técnicas, não checklist mágico.
Esse julgamento da Meta vai entrar pra história como o momento em que o mundo tech começou a tratar design de engajamento como responsabilidade legal. Pra nós, devs, é hora de parar de tratar ética como afterthought e começar a codar com isso desde a primeira linha.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.