Dados contra viés: uma falsa dicotomia?
O título da fonte que originou esta reflexão é provocador e necessário: "Quem decide: nós ou os dados?". Vivemos, sem dúvida, um momento de culto aos dados. Empresas inteiras se reestruturam em torno de uma suposta "cultura data-driven", engenheiros de software são pressionados a instrumentar cada clique e arquitetos de sistemas desenham pipelines para capturar cada interação. A premissa é sedutora: se temos dados suficientes e o algoritmo certo, chegaremos a decisões mais objetivas, eliminando o viés humano falho. Mas, na prática, a resposta é menos confortável. A decisão nunca é exclusivamente dos dados; ela é, no máximo, uma decisão moldada por quem desenhou o sistema, por quem escolheu quais dados coletar e por quem definiu o que é "sucesso". O professor Guilherme Victorino, da NOVA IMS, acerta ao levantar a dúvida se, com tantos dados, estamos decidindo melhor ou apenas de forma diferente. Minha experiência em arquitetura de sistemas e segurança me leva a crer que, muitas vezes, trocamos um conjunto de vieses (humanos, explícitos) por outro conjunto (os vieses corporificados nos dados e nos modelos), sem a devida transparência. A verdadeira questão não é se os dados decidem, mas se confiamos no contexto em que eles foram gerados e processados.
O viés na fundação do dado
Há um erro conceitual comum entre profissionais de produto e tecnologia: achar que "dados" são entidades neutras, extraídas da realidade como minério de uma mina. Não são. Dados são construções. A escolha de quais eventos registrar, como normalizá-los e quais métricas derivar já é uma decisão profundamente carregada de intenção e, inevitbalmente, de viés. Quando um engenheiro de dados define que uma "sessão" de usuário termina após 30 minutos de inatividade, ele está impondo uma regra arbitrária. Quando uma equipe de produto decide medir "engajamento" pelo tempo gasto no aplicativo, está privilegiando quantidade sobre qualidade. Essas decisões, tomadas no nível da infraestrutura de dados, são invisíveis para a maioria dos tomadores de decisão que, depois, olharão para um dashboard.
Na prática, o viés não está apenas no algoritmo de machine learning; ele está na camada de coleta. Passei por um projeto em que monitorávamos o desempenho de uma plataforma de e-commerce. Os dados mostravam uma queda abrupta nas vendas de uma categoria específica. A conclusão "data-driven" apressada foi que o produto não tinha mais apelo. Ao examinar os dados brutos e a configuração dos pipelines, descobrimos que um script de ingestão de dados havia falhado silenciosamente por três dias para aquela categoria específica. A decisão baseada em "dados" era, na verdade, uma decisão baseada em ruído de infraestrutura. Este é um lembrete incômodo: antes de perguntar o que os dados dizem, precisamos garantir que eles estão contando alguma história.
Decisão informada vs. decisão delegada
Outra nuance que o debate entre "nós e os dados" frequentemente ignora é a diferença entre decisão informada e decisão delegada. Decisão informada é o ideal: o profissional usa os dados como um dos insumos para seu julgamento, pesando incertezas, contexto de negócio e intuição baseada em experiência. Decisão delegada é quando a organização se apoia cegamente no output de um modelo ou de um KPI, sem espaço para contestação.
Em produtos digitais, especialmente aqueles com sistemas de recomendação ou automação, essa linha é tênue. Um sistema de moderação de conteúdo que usa IA pode ser treinado com um dataset que reflete um viés histórico de uma equipe de revisão. Se a decisão final for simplesmente "o que o modelo disse", a empresa está delegando a decisão a um reflexo imperfeito do seu próprio passado. No contexto de segurança da informação, isso é crítico. Um SIEM (Security Information and Event Management) que gera alertas baseados em regras pode perder ataques criativos, mas se o time delegar a decisão de ignorar alertas de baixa severidade com base unicamente no volume, estará criando uma cegueira artificial supervisionada. O profissional técnico precisa ter autonomia e capacidade de veto sobre o que os dados sugerem, exatamente por entender as limitações daquela fonte de informação.
Quando os números escondem a realidade
A métrica de sucesso de um sistema de recomendação é geralmente o CTR (Click-Through Rate). Tudo bem, medir cliques é fácil em infraestrutura de nuvem. Mas se o modelo é otimizado exclusivamente para maximizar cliques, ele rapidamente aprenderá a recomendar conteúdo barulhento, sensacionalista ou campanhas enganosas, que geram cliques mas não geram valor real. O dado "clicou" é verdadeiro; a decisão de negócio ("recomendar mais disso") baseada nesse dado é, em muitos casos, ruim.
Já vi equipes de produto celebrarem um aumento de 20% no CTR de um novo algoritmo, enquanto a taxa de retenção de longo prazo caía. O motivo? Os usuários clicavam, se frustravam com o conteúdo raso, e perdiam confiança na plataforma. Estavam "decidindo" com base no dado mais barulhento, ignorando a métrica de valor real. O alerta aqui é sobre a escolha da variável alvo. Não basta ter dados; é preciso ter os dados certos, e isso exige um modelo mental de negócio que nenhuma pipeline de dados substitui.
O falso dilema da objetividade
Um dos grandes riscos de acreditar que "os dados decidem" é a falsa sensação de objetividade. Na minha trajetória com arquitetura de sistemas, lidei com situações onde o time de operações apresentava um dashboard com latências excelentes, enquanto o time de produto mostrava reclamações de usuários sobre lentidão. Ambos tinham dados. Os dados de operações mediam a latência do servidor; os dados de produto mediam a latência percebida pelo cliente (que incluía tempo de renderização no navegador, latência de rede do cliente e bloqueios de script). Quem estava errado? Ninguém. Os dados estavam corretos dentro do seu domínio. A questão é que a decisão sobre onde investir para melhorar a experiência só viria de uma conversa técnica que reconciliasse as duas métricas, e não de uma planilha.
DevOps e DataOps: a trincheira da intenção
Em ambientes de DevOps e DataOps, o ciclo de feedback é curto. Cada alteração na infraestrutura de dados, cada novo campo em um log estruturado, cada modelo de ML colocado em produção carrega uma intenção. Quando configuramos um pipeline de CI/CD, decidimos o que testar. Quando escrevemos uma query no BigQuery, decidimos quais colunas unir. Esse ato de decidir, minuto a minuto, molda o que a organização vai "saber" sobre si mesma e seus clientes. Ignorar essa subjetividade na fundação técnica é o caminho mais rápido para uma cultura de decisão frágil.
Veja o caso de modelos de linguagem como os que usamos para gerar e classificar conteúdo hoje. Eles são treinados em grandes volumes de texto — um reflexo da produção humana online, com todos os seus vieses, ruídos e contradições. Decidir que um LLM é a fonte da verdade para resumir um relatório técnico ou para recomendar uma estratégia de código é uma decisão sua, não dos dados. Os dados (o corpus de treinamento) não "decidiram" nada; eles são o reflexo inercial de uma época. Quem decide é o profissional que definiu o prompt, que fez o fine-tuning e que validou o output.
Implicações para o mercado de trabalho e a carreira técnica
Essa reflexão não é acadêmica; ela tem implicações diretas para quem trabalha com tecnologia. A habilidade mais valiosa não será necessariamente saber operar uma ferramenta de BI ou um framework de ML, será a capacidade de questionar os dados. O engenheiro de software que sabe quando um teste de hipótese é inadequado para o volume de amostras, o arquiteto de dados que pergunta "de onde vieram esses dados?" antes de modelar o schema, o líder técnico que desafia uma decisão do modelo com base no contexto de negócio — esses profissionais estão blindados contra a armadilha da falsa objetividade.
No mercado, vejo uma polarização perigosa. De um lado, profissionais que abraçam cegamente o "data-driven" como mantra; do outro, os que rejeitam qualquer dado por desconfiança. O equilíbrio, como em tantos outros aspectos da engenharia, está em um ceticismo construtivo. Tratar dados como testemunhas, não como juízes. Uma testemunha pode estar enganada, pode ter uma visão parcial, pode mentir — mas ignorar seu depoimento é burrice. O trabalho do profissional senior é fazer a contraprova: cruzar fontes, checar a sanidade do pipeline e, finalmente, assumir a responsabilidade pela decisão.
Onde entra a privacidade e a transparência?
Para o leitor que trabalha com privacidade em produto, o debate "nós vs dados" é ainda mais urgente. Se seus algoritmos decidem a pontuação de crédito de um cliente ou o preço de um seguro, e a decisão é atribuída a um modelo de caixa-preta, você está, na prática, criando um sistema sem responsabilidade. As leis de proteção de dados (como a LGPD) exigem transparência e a possibilidade de revisão humana. Isso não é só compliance; é uma barreira contra a alienação da decisão. Quando o sistema decide, mas o humano não consegue explicar o porquê, a responsabilidade legal cai sobre a empresa — e sobre os engenheiros que desenharam o sistema.
Construir um sistema auditável não é apenas uma boa prática; é uma decisão arquitetural. Logar versões de modelo, armazenar features usadas em cada predição e permitir que um humano sobreponha a decisão automatizada são investimentos que protegem a organização contra os erros de um modelo enviesado. Aqui, a decisão continua sendo nossa — escolhemos se queremos ou não construir a infraestrutura para garantir que nossos dados não decidam sozinhos.
Conclusão: a responsabilidade é técnica e ética
Voltando à pergunta inicial: "Quem decide: nós ou os dados?". Decidimos nós, sempre. Os dados são um artefato, uma ferramenta poderosa, mas inerte. A armadilha está em querer externalizar a responsabilidade da decisão para um algoritmo ou para números em uma tela. Na engenharia de software, na IA aplicada e na gestão de produtos, o profissional de valor é aquele que não se refugia nos dados para justificar uma escolha, mas que os usa para iluminar o caminho, ciente de que a lanterna tem um alcance limitado e uma lente deformada. Construir infraestrutura, modelos e processos que reconheçam essa limitação é o que separa a boa engenharia da mera automação. Porque, no fim, a decisão sobre o que construir e por que construir — essa sempre foi, e sempre será, exclusivamente nossa.