Todo sistema carrega pressupostos. A neutralidade é um mito conveniente.
Introdução
No mundo moderno, frequentemente encontramos afirmações estruturadas como silogismos aparentemente válidos, mas que conduzem a conclusões equivocadas ao ocultarem pressupostos não examinados. Visto que esses argumentos exibem aparência de rigor lógico, no entanto, evitam uma análise conceitual mais aprofundada.
Um exemplo recorrente encontra-se na afirmação de que a ciência é baseada em fatos. A partir dessa ideia, observa-se que a atribuição de valores não descreve adequadamente o que a ciência é ou como opera. Esse pensamento costuma ser tratada como evidente, raramente sendo submetida a exame crítico.
Seguindo a estrutura do silogismo clássico aristotélico, esse raciocínio pode ser formulado da seguinte forma:
Premissa maior: Tudo o que é baseado em fatos é verdadeiro e neutro.
Premissa menor: A ciência é baseada em fatos.
Conclusão: Logo, a ciência é verdadeira e neutra.
À primeira vista, o argumento parece coerente. Entretanto, revela-se falho por ocultar pressupostos fundamentais. Fatos não falam por si: eles são observados, selecionados, organizados e interpretados dentro de modelos teóricos específicos. A ciência, portanto, não se reduz a uma aglomeração de dados brutos, mas constitui uma prática interpretativa orientada por teorias, métodos e critérios previamente assumidos.
Esse falso silogismo, ao confundir fato com interpretação, assume a neutralidade como consequência automática. Contudo, mesmo quando a ciência trabalha com dados empíricos, há pressupostos filosóficos, metodológicos e culturais que determinam o que pode ser considerado “fato relevante”. Dessa forma, esse raciocínio enfraquece, diretamente, o conceito de neutralidade.
Ademais, essa argumentação desconsidera o papel estruturante das teorias científicas. Conforme sustenta o filósofo e historiador da ciência Thomas Kuhn, a ciência opera dentro de paradigmas que moldam não apenas suas teorias, mas também aquilo que pode ser reconhecido como fato. A observação científica é orientada por estruturas conceituais prévias. Em termos práticos, o que conta como “fato” emerge dentro de um paradigma teórico, e não de uma observação neutra da realidade.
Se a própria ciência, em seu nível mais elementar, não opera a partir de fatos brutos e neutros, mas dentro de paradigmas que orientam observação e interpretação. Desse jeito, torna-se difícil sustentar que a tecnologia, a qual nasce da aplicação prática desse conhecimento, possa ser considerada neutra.
A tecnologia não apenas herda os pressupostos da ciência que a fundamenta, ela também incorpora novas camadas decisórias: critérios de eficiência, métricas de sucesso, restrições econômicas, objetivos institucionais e escolhas de design. Cada sistema técnico é, portanto, o resultado de uma cadeia de interpretações e valores acumulados ao longo do processo.
O mesmo falso silogismo aplicado à ciência reaparece, portanto, sob outra forma: a ideia de que sistemas tecnológicos seriam neutros porque se basearem em dados, modelos ou fatos. Assim como na ciência, esse argumento ignora que dados são selecionados, modelos são construídos e sistemas são projetados para atender a finalidades específicas.
Nesse cenário, a neutralidade deixa de operar como constatação técnica e passa a funcionar como uma narrativa conveniente, isto é, uma maneira de ocultar escolhas humanas sob a aparência de inevitabilidade técnica. Trata-se de conveniente porque simplifica o discurso e dilui a responsabilidade. Ao afirmar que uma tecnologia é neutra, desloca-se o foco das decisões humanas para abstrações técnicas: o algoritmo, o sistema, a ferramenta.
Assim, a neutralidade tecnológica não constitui um dado técnico, mas sim de uma posição filosófica, muitas vezes assumida sem que reconheça sua própria identidade.
Sistemas não surgem do nada
Nenhum sistema nasce espontaneamente, visto que todo software é o resultado de uma cadeia contínua de decisões humanas. Antes do surgimento de um código, existe um recorte da realidade. Modelar um sistema é sempre um exercício de perda controlada, uma vez que se escolhe o que será representado, simplificado, além do que ficará excluído.
O que não é modelado não desaparece, apenas deixa de ser considerado pelo sistema. Essa exclusão não é um erro acidental, porém uma consequência inevitável de limites técnicos, temporais e conceituais. Em síntese, todo modelo pressupõe um ponto de vista.
Em um projeto inicial do qual participei, durante a construção de um modelo entidade-relacionamento, tornou-se evidente que o sistema não poderia abranger toda a complexidade do negócio. Determinadas regras foram deliberadamente excluídas em razão de restrições técnicas e temporais. A experiência demonstrou que modelar não significa representar a realidade tal como ela aparenta, mas escolher quais aspectos dela serão considerados pelo sistema
Antes de seguir para o código, há sempre decisões de natureza política, não no sentido partidário, mas no sentido estrutural e organizacional do termo. Os sistemas são construídos dentro de políticas organizacionais, e técnicas institucionais, pois essas bases orientam o que pode, o que deve e o que não deve ser feito. Isto envolvem políticas de segurança, versionamento, qualidade de código, acessibilidade, conformidade legal. Logo, a escolha de tecnologia não são detalhes operacionais, e sim critérios normativos e incorporados ao sistema.
Em muitos contextos contemporâneos, essas políticas já não ficam apenas registrada como documento, uma vez que elas são executadas automaticamente por meio de pipelines, validações e restrições técnicas. A política deixa de ser, apenas, declarada e passa a ser imposta pelo próprio sistema.
No campo da arquitetura de software, essa noção categórica torna ainda mais evidente. Segundo a abordagem de Clean Architecture e Domain-Driven Design, políticas é entendida como o conjunto de regras e decisões que definem como sistema deve se comportar independentemente da tecnologia. Trata-se da escolha que gera valor para o negócio e orienta o funcionamento do sistema no mundo real.
Mesmo no caso do desenvolvedor solitário, verifica-se que não existe neutralidade. Antes de abrir a IDE, já havia pressupostos, vieses e critérios em operação. Arquitetura é escolha. Modelagem é escolha. Priorizar desempenho em detrimento da explicabilidade é escolha. Automatizar uma decisão humana também é escolha.
Embora o discurso técnico se apoie em critérios em critérios aparentemente objetivos como eficiência, escalabilidade, acurácia; ainda, assim, estamos lidando com valores. Eficiência para quem? Acurácia em relação a quê? Escalabilidade a custo de quê?
A técnica não elimina a dimensão normativa do mundo. Ela apenas a encapsula.
A neutralidade como narrativa confortável
A ideia de neutralidade tecnológica não surge do nada. Ela herda uma concepção antiga, muito difundida na forma popular de compreender a ciência: a ideia de que a ciência parte de fatos brutos e produz conhecimento objetivo, livre de valores.
Foi exatamente essa concepção que Thomas Kuhn colocou em xeque. Ao estudar a história da ciência, o teórico demostrou que aquilo que uma comunidade científica reconhece como “fato” depende do paradigma no qual ela opera. O paradigma define quais problemas são relevantes, quais métodos são considerados válidos e quais resultados trazem sentidos significativos. Assim, o cientista não observa dados de forma neutra; ele os observa a partir de um modelo teórico prévio.
Quando esse aspecto é ignorado, estabelece-se um raciocínio simplificador: se a ciência é neutra por lidar com fatos, então a tecnologia, enquanto aplicação prática desse conhecimento, também seria neutra. Contudo, essa conclusão depende justamente daquilo que Kuhn demonstrou ser inverídico: a existência de fatos independentes de estruturas interpretativas.
No contexto tecnológico, a neutralidade passa a funcionar como uma narrativa operacionalmente conveniente. Sistemas são apresentados como se apenas executassem o que os dados indicam, quando, na prática, um sujeito já decidiu quais dados coletar, quais variáveis considerar, quais exceções ignorar e quais objetivos otimizar.
Para quem atua no desenvolvimento de software, essa situação deveria ser considerada normal, porque métricas não surgem espontaneamente; modelos não se treinam sozinhos; regras de negócio não emergem automaticamente dos dados. Todas essas dimensões são definidas, refinadas e priorizadas por pessoas e instituições.
Ao se afirma que “o sistema decidiu” ou que “o algoritmo apenas seguiu os dados”, cria-se uma distância artificial entre o resultado obtido e as decisões que o tornaram possível. O comportamento do sistema passa a parecer inevitável, quase natural. Portanto, essa inevitabilidade é construída, assim como nos paradigmas científicos descritos por Kuhn.
A neutralidade oferece conforto porque reduz a necessidade de justificar escolhas técnicas. Esse conforto transforma decisões em aparentes consequências e desloca o debate do campo dos valores para o campo da eficiência.
Essa interpretação não é inovadora. Já no final do século XX, o filósofo da tecnologia Langdon Winner argumentava que artefatos técnicos não são meros instrumentos neutros, mas estruturas que incorporam escolhas políticas e normativas. Para Winner, determinadas decisões deixam de ser explícitas porque se materializam na própria forma do artefato técnico, passando a operar independentemente da intenção consciente de seus usuários.
Desse modo, quando um sistema técnico impõe comportamentos, restringe possibilidades ou automatiza decisões, ele não está apenas executando uma função; está materializando escolhas realizadas em seu projeto. A narrativa da neutralidade surge precisamente nesse ponto: quando tais escolhas deixam de ser percebidas como decisões e passam a ser tratadas como propriedades naturais da tecnologia.
Esse conforto, no entanto, tem um custo: escolhas deixam de ser visíveis, prioridades deixam de ser discutidas e limitações passam a parecer propriedades intrínsecas do sistema.
Assim como paradigmas científicos moldam o que conta como fato, sistemas tecnológicos moldam o que conta como decisão legítima. A neutralidade não elimina os valores envolvidos; ela apenas os oculta sob uma camada técnica.
É a partir dessa ocultação que algoritmos passam a ser tratados como juízes imparciais.
Algoritmos não são juízes imparciais
Algoritmos não julgam, não avaliam e não compreendem. Eles executam regras, aplicam pesos e maximizam funções com objetivos previamente definidos. Toda decisão algorítmica responde, ainda que implicitamente, a uma pergunta simples: o que deve ser otimizado?
Essa pergunta não é feita pelo algoritmo, já que ela é estabelecida antes de sua existência.
Em sistemas de recomendação, por exemplo, não há neutralidade na noção de “relevância”. O que será priorizado: tempo de permanência, cliques, recorrência, diversidade ou conversão depende de critérios externos ao modelo. O algoritmo apenas ordena resultados de acordo com esses critérios. Trocar a métrica muda completamente o comportamento do sistema, ainda que o código permaneça o mesmo.
O mesmo ocorre em sistemas de scoring. Um score de crédito não “mede risco” de forma objetiva; ele operacionaliza uma definição específica de risco. Quais variáveis devem ter maior peso? Histórico recente ou de longo prazo? Penalizar falsos positivos ou falsos negativos? Essas escolhas não são resolvidas,apenas, por estatística ou aprendizado de máquina. Elas são decisões normativas formalizadas em lógica matemática.
Nesse contexto, os dados também não funcionam como espelhos da realidade. Eles são registros produzidos por sistemas anteriores, sob regras anteriores. Logs refletem interfaces, fluxos e incentivos já existentes. Dados históricos carregam a marca de decisões passadas inclusive das exclusões. Aquilo que não foi medido simplesmente não existe para o modelo.
Treinar um algoritmo com dados históricos não significa partir do zero, mas sim herdar uma trajetória de escolhas. O modelo aprende padrões, mas esses padrões não surgiram de forma natural: foram produzidos dentro de contextos sociais, econômicos e técnicos específicos.
A função objetivo consolida esse processo. Todo sistema algorítmico otimiza algo: minimizar erro, maximizar engajamento, reduzir custo, aumentar Throughput. Entretanto, otimizar uma métrica implica aceitar perdas em outras. Precisão pode vir à custa de explicabilidade. Performance pode sacrificar equidade; escalabilidade pode exigir simplificações agressivas.
Nota-se que os trade-offs não constituem falhas do sistema, uma vez que são consequências diretas das prioridades assumidas. O algoritmo não escolhe entre elas; ele apenas executa escolhas previamente estabelecidas.
A complexidade técnica frequentemente intensifica a ilusão de imparcialidade. Modelos extensos, pipelines distribuídos e sistemas opacos dificultam rastrear onde as decisões foram tomadas. Quanto menos visível a cadeia de escolhas, mais fácil se torna tratar o resultado como inevitável. Contudo, opacidade não produz neutralidade; apenas protege decisões de questionamento.
Muitas dessas escolhas aparecem disfarçadas de requisitos. “o negócio precisa maximizar lucro.”, “o sistema precisa reduzir risco.”, “o modelo precisa priorizar quem converte mais”. Tais afirmações podem ser legítimas, mas não são neutras; representam critérios valorativos traduzidos em código.
O problema não reside no fato de que sistemas possuam critérios, todo sistema necessita deles. O problema está em tratar esses critérios como propriedades naturais do algoritmo, e não como decisões humanas incorporadas à sua estrutura.
Algoritmos não são juízes imparciais porque não possuem critérios próprios. Eles executam critérios definidos por alguém, em determinado contexto e com objetivos específicos. A imparcialidade não desaparece porque o sistema é complexo ou matematicamente sofisticado, ela desaparece quando esquecemos ou fingimos esquecer, quem decidiu o que deveria ser otimizado.
Quando um sistema prioriza determinados comportamentos, penaliza outros ou automatiza decisões anteriormente humanas, isso não ocorre por acaso. Essas escolhas foram realizadas em algum ponto da cadeia de desenvolvimento, ainda que hoje estejam diluídas em código, métricas e modelos.
Se algoritmos apenas executam decisões, a questão central deixa de ser exclusivamente técnica e torna-se inevitavelmente humana: quem constrói, com quais pressupostos e sob quais responsabilidades?
É nesse ponto que o papel de quem constrói sistemas deixa de ser invisível.
O papel de quem constrói
Para quem atua no desenvolvimento de software, o mito da neutralidade oferece um refúgio confortável. Ele permite concentrar-se exclusivamente na implementação, tratando decisões de alto impacto como simples requisitos técnicos. O problema é que sistemas não operam apenas no plano do código; eles operam no mundo.
Toda escolha técnica carrega consequências que extrapolam o escopo imediato do sistema. Uma regra de priorização define quem será atendido primeiro. Um critério de corte determina quem ficará de fora. Um padrão adotado em escala transforma exceções em norma. Mesmo decisões aparentemente pequenas, com valores padrão, limites rígidos ou fluxos obrigatórios moldam comportamentos quando aplicadas repetidamente.
Isso não transforma desenvolvedores em árbitros morais absolutos, nem exige que cada linha de código seja acompanhada de um juízo ético explícito. Porém, exige reconhecimento de algo básico: construir sistemas é um ato humano situado, realizado dentro de contextos organizacionais, econômicos e culturais específicos.
Na prática, quem constrói sistemas raramente define sozinho os objetivos finais. Há pressões de negócio, prazos, métricas, restrições legais e limitações técnicas concretas. Ainda assim, sempre existe margem para decisão: como modelar, o que automatizar, o que tornar explícito, o que esconder atrás da abstração.
Assumir esse papel não significa paralisar o desenvolvimento em nome de reflexão constante. Significa apenas abandonar a ilusão de que a técnica nos isenta de responsabilidade. Contudo, confirma que a responsabilidade não surge apenas quando o sistema falha; ela existe desde o momento em que uma decisão é incorporada ao design.
Recusar a neutralidade não é assumir culpa por tudo. É assumir lucidez sobre o próprio ofício. É compreender que engenharia não consiste apenas em resolver problemas, como também em definir quais problemas merecem ser resolvidos e de que maneira.
Quando essa consciência está ausente, a técnica tende a se tornar autorreferente. Métricas internas passam a justificar decisões externas; eficiência transforma-se um fim e si mesma. O sistema funciona, mas sem nenhuma reflexão sobre os efeitos que produz no exterior do ambiente controlado do código.
Reconhecer o papel de quem constrói não torna a tecnologia menos eficiente. Torna-a mais honesta e, paradoxalmente, mais robusta, visto que decisões explicitadas podem ser questionadas, revisadas e corrigidas.
É nesse ponto que a responsabilidade técnica deixa de ser um peso e passa a ser um critério de maturidade.
Limite, responsabilidade e lucidez
Reconhecer que tecnologia não é neutra não implica rejeitá-la nem lhe atribuir intenções próprias. Implica, antes, recolocá-la dentro de seus limites reais. Sistemas técnicos não decidem por si mesmos; eles operam dentro de fronteiras definidas por modelos, métricas e objetivos previamente estabelecidos.
O problema surge cada vez que esses limites são esquecidos. Sempre que a técnica passa a ser tratada como instância final de decisão, e não como meio. Também, quando escolhas humanas incorporadas ao design são apresentadas como consequências inevitáveis da complexidade técnica.
A responsabilidade, nesse contexto, não se manifesta apenas quando algo dá errado. Ela existe desde o momento em que uma decisão é cristalizada em arquitetura, no código ou em um modelo. Toda abstração elimina possibilidades, qualquer processo de automação fixa comportamentos e cada métrica privilegiada desloca outras para a margem.
Assumir essa responsabilidade não significa exigir que profissionais de tecnologia antecipem todas as consequências de seus sistemas, pois isso seria irreal. Significa, apenas, reconhecer que construir sistemas é um ato situado, realizado sob condições específicas e orientado por valores, ainda que implícitos.
É nesse ponto que a noção de limite se torna fundamental: limite técnico, limite epistemológico e limite moral. A técnica não resolve, por si só, aquilo que não foi previamente decidido no plano humano. Ao exigir neutralidade da tecnologia equivale, na prática, a abdicar da reflexão sobre esses limites.
Lucidez, portanto, não significa paralisar a engenharia, mas impedir que ela se torne cega ao próprio impacto. Trata-se de manter visíveis as escolhas que o sistema incorpora e negar a narrativa confortável que transforma decisões em fatalidades técnicas.
Ao final, a questão não é se sistemas, algoritmos ou modelos são neutros, porque eles não são. A problemática é responder se os responsáveis que os constroem estão dispostos a reconhecer as escolhas envolvidas ou se prefere delegá-las a abstrações técnicas, tratando-as como inevitáveis.
A tecnologia amplia capacidades, assim como amplia consequências. Reconhecer isso não enfraquece o ofício técnico, mas sim é sinal de maturidade profissional.
A neutralidade é um mito conveniente. A responsabilidade, quando assumida com limite e lucidez, é o que permanece e é suficiente.
Referências (ABNT)
KUHN, Thomas S. A estrutura das revoluções científicas. 3. ed. Chicago: University of Chicago Press, 1996.
WINNER, Langdon. Do artifacts have politics? Daedalus, Cambridge, v. 109, n. 1, p. 121–136, 1980.
SCOTT, James C. Seeing like a state: how certain schemes to improve the human condition have failed. New Haven: Yale University Press, 1998.
LATOUR, Bruno. Science in action: how to follow scientists and engineers through society. Cambridge: Harvard University Press, 1987.
LATOUR, Bruno. Jamais fomos modernos. Rio de Janeiro: Editora 34, 1994.
O’NEIL, Cathy. Weapons of math destruction: how big data increases inequality and threatens democracy. New York: Crown Publishing Group, 2016.
EUBANKS, Virginia. Automating inequality: how high-tech tools profile, police, and punish the poor. New York: St. Martin’s Press, 2018.
GEBRU, Timnit et al. Datasheets for datasets. Communications of the ACM, New York, v. 64, n. 12, p. 86–92, 2021.
MARTIN, Robert C. Clean architecture: a craftsman’s guide to software structure and design. Boston: Prentice Hall, 2017.
EVANS, Eric. Domain-driven design: tackling complexity in the heart of software. Boston: Addison-Wesley, 2004.
Agradecimentos à Dayane pelo apoio na revisão do texto.