A neutralidade dos dados é uma ilusão: como a IA exige Justiça desde a arquitetura

Quando um sistema de recomendação de currículos é treinado com dados históricos de contratações de uma empresa de tecnologia, ele não “aprende” a selecionar os melhores candidatos. Ele aprende a replicar o padrão que existia — inclusive os vieses de gênero, raciais e socioeconômicos que moldaram aquelas contratações. Esse não é um problema teórico de debates de mesa redonda. É um problema de arquitetura de sistemas, de escolha de features e de métricas de sucesso que muitas vezes são definidas por engenheiros que não pensaram nas consequências distributivas dos seus modelos.

A crônica de Cláudia Mendes Silva, publicada no Observador, toca num ponto que deveria ser central em qualquer discussão sobre inteligência artificial aplicada: o perigo não é que a IA “não veja” o gênero, mas sim que nós, como sociedade e como profissionais de tecnologia, deixemos de ver a desigualdade porque ela passou a falar a linguagem “limpa” dos dados. Um banco de dados anonimizado parece neutro, mas carrega o peso de décadas de discriminação estrutural. Se um modelo preditivo for treinado com esses dados sem correções, ele perpetuará — e até amplificará — as injustiças.

Como engenheiro de software que trabalhou com pipelines de dados em larga escala e modelos de machine learning em produção, posso afirmar: a neutralidade é uma decisão de design, nunca um atributo intrínseco dos dados. E essa decisão impacta diretamente a qualidade do produto, a confiança do usuário e, em muitos casos, a legalidade do sistema.

O viés não está no algoritmo, está no pipeline

A primeira lição que aprendi na prática é que a fonte mais comum de viés não é o modelo em si — regressão logística, árvore de decisão ou rede neural —, mas sim o pipeline de dados que alimenta o treinamento. Dados históricos refletem o mundo como ele é, não como deveria ser. Se uma base de currículos tem 80% de candidatos homens para cargos de liderança, o modelo aprenderá que “liderança” está associada a características masculinas, mesmo que nenhuma feature explícita de gênero esteja presente.

Para mitigar isso, já utilizamos técnicas como reamostragem (oversampling de grupos sub-representados) e ponderação de instâncias durante o treinamento. Mas há um trade-off importante: forçar a equalização estatística pode reduzir a acurácia geral do modelo em nome da justiça distributiva. Decidir onde colocar esse slider é uma escolha de engenharia que deve ser discutida com stakeholders de produto, compliance e, idealmente, com representantes das comunidades afetadas. Ignorar essa etapa é construir um sistema injusto por omissão.

A falsa promessa da anonimização

Outra armadilha comum é acreditar que anonimizar dados resolve o problema. Na prática, a anonimização remove identificadores diretos, mas mantém correlações indiretas que podem funcionar como proxies para gênero ou raça. Por exemplo, o CEP, a faixa salarial ou o cargo podem estar altamente correlacionados com raça em determinadas regiões. Um modelo que usa essas variáveis como features pode discriminar mesmo sem saber a raça do indivíduo. É o que chamamos de “viés indireto” — e detectá-lo exige análise exploratória profunda e testes de fairness específicos, como métricas de disparate impact ou equal opportunity.

Em projetos de sistemas de crédito que arquitetei, incluímos uma etapa obrigatória de auditoria de proxies. Ela consiste em treinar um modelo auxiliar que tenta prever a variável sensível a partir das features disponíveis. Se o modelo auxiliar conseguir prever gênero com alta acurácia, sabemos que há vazamento de informação — e precisamos repensar a engenharia das features. Esse tipo de controle técnico é simples de implementar, mas muitas vezes omitido por falta de consciência ou de prazos apertados.

Métricas de justiça: um campo minado de trade-offs

No universo de fairness em machine learning, não existe uma definição universal de “justiça”. As principais métricas — demographic parity, equal opportunity, equalized odds — podem entrar em conflito direto. Um modelo que garante a mesma taxa de aprovação entre grupos (demographic parity) pode, ao mesmo tempo, violar o princípio de que pessoas igualmente qualificadas devem ter a mesma chance (equal opportunity). Escolher qual métrica priorizar é, novamente, uma decisão de produto, não de matemática.

Em um sistema de triagem de currículos que liderei, optamos por equal opportunity como métrica principal, porque o cliente (uma empresa de RH) queria garantir que candidatos com os mesmos skills tivessem a mesma chance de serem chamados para entrevista, independentemente de gênero. O custo foi uma pequena queda na precisão geral — cerca de 2% —, mas o ganho em equidade e em conformidade com regulamentações futuras (como a Lei de IA da União Europeia) compensou amplamente. O ponto aqui é: não existe almoço grátis. É preciso medir, documentar e comunicar os trade-offs para a liderança.

Engenharia de features como ato político

Muitos engenheiros tratam a escolha de features como uma questão puramente técnica — a feature mais preditiva é a melhor. Mas features são representações de como interpretamos o mundo. Se um modelo de aprovação de crédito usa “histórico de pagamentos de aluguel” como feature, ele pode penalizar grupos que historicamente tiveram menos acesso a contratos formais de aluguel (como minorias). Incluir ou excluir uma feature é um ato político que define quem será beneficiado ou prejudicado pelo sistema.

Na minha experiência, a melhor prática é criar um comitê de revisão de features que inclua pessoas de áreas de negócio, direito e, quando possível, representantes dos usuários finais. Esse comitê avalia não apenas a correlação preditiva, mas também o potencial de viés indireto e o impacto social de cada feature. Esse processo é custoso e atrasa o time-to-market, mas evita correções emergenciais depois que o modelo está em produção — correções que costumam ser muito mais caras e danosas à reputação.

Implicações práticas para equipes de engenharia e produto

Se você trabalha com sistemas de IA aplicada, precisa incorporar fairness como requisito não-funcional desde a fase de definição do problema, e não como uma “camada de correção” no final. Isso significa:

• Incluir no contrato de SLA não apenas métricas de acurácia e latência, mas também métricas de equidade (por exemplo, diferença máxima aceitável na taxa de falsos positivos entre grupos).
• Automatizar testes de fairness no pipeline de CI/CD, executando a cada novo treinamento do modelo. Ferramentas como o Fairlearn (Microsoft) e o AI Fairness 360 (IBM) podem ser integradas com relativa facilidade.
• Documentar todas as decisões de design relacionadas a viés — desde a escolha das fontes de dados até a seleção da métrica de justiça — em um “model card” ou “datasheet” do sistema. Essa documentação é essencial para auditorias futuras e para transparência com usuários finais.

Além disso, a diversidade das equipes que constroem esses sistemas é um fator crítico. Equipes homogêneas tendem a ter menos sensibilidade para detectar potenciais vieses. Não estou falando de tokenismo, mas de incluir profissionais de diferentes origens, gêneros e experiências de vida no processo de design e revisão. Como engenheiro de sistemas, percebo que times diversos identificam muito mais rapidamente os pontos cegos nos dados e nas features.

Riscos de ignorar a urgência da justiça

O maior risco é o regulatório. A Lei de IA da União Europeia, aprovada em 2024, classifica sistemas de IA usados em recrutamento, crédito e seguro como “alto risco”. Esses sistemas precisarão passar por avaliações de conformidade que incluem análises de viés e transparência algorítmica. Empresas que não se prepararem agora poderão ter seus produtos bloqueados em mercados importantes, além de enfrentarem multas significativas.

Mas o risco reputacional é ainda mais imediato. Casos como o do sistema de recrutamento da Amazon — que penalizava currículos de mulheres — mostram que a opinião pública e a imprensa estão atentas. Um produto digital que é percebido como injusto perde usuários, gera crises de PR e pode afundar uma startup em estágio inicial. A justiça, portanto, não é apenas um imperativo ético — é uma vantagem competitiva sustentável.

Limitações que precisamos reconhecer

Não quero vender a ideia de que existe uma solução técnica perfeita. A própria definição de justiça é contestável e local — o que é justo para uma cultura pode não ser para outra. Além disso, os métodos de mitigação de viés têm limitações: podem reduzir a acurácia, aumentar o custo computacional e, em alguns cenários, criar novas formas de injustiça. O que defendo é que esses trade-offs sejam explícitos, mensuráveis e decididos de forma democrática, não escondidos atrás de uma suposta neutralidade dos dados.

Em um projeto recente de sistema de recomendação de conteúdo educacional, enfrentamos um dilema: o algoritmo tendia a recomendar cursos de STEM para meninos e cursos de humanas para meninas, porque os dados históricos de consumo mostravam essa tendência. Poderíamos, para “corrigir”, randomizar as recomendações — mas isso prejudicaria a experiência de todos. Optamos por criar um modelo com restrições de fairness que garantisse que, para cada perfil de habilidade, as recomendações fossem independentes de gênero. O resultado foi uma redução de 5% na taxa de clique geral, mas um aumento de 15% na diversidade de cursos consumidos pelas meninas. Para o produto, esse trade-off valeu a pena.

Perspectiva pessoal: o que eu levo dessa discussão

Depois de mais de uma década construindo sistemas de software complexos, aprendi que as decisões técnicas mais impactantes raramente são puramente técnicas. Elas envolvem valores, prioridades e visões de mundo. A afirmação de que “a IA não torna a igualdade irrelevante, torna a justiça mais urgente” é um daqueles insights que deveriam estar na parede de todo engenheiro de machine learning. Não podemos delegar a justiça ao algoritmo — ela precisa ser projetada, medida e mantida ativamente, assim como a escalabilidade ou a segurança.

Convido você, leitor, a olhar para o próximo sistema de IA que sua equipe for construir com um novo par de olhos: questione os dados, as features, as métricas. Pergunte quem está sendo beneficiado e quem está sendo prejudicado. E lembre-se de que a linguagem limpa dos dados pode estar escondendo as mesmas desigualdades que a tecnologia prometia resolver. Nossa responsabilidade como engenheiros é não deixar que isso aconteça.