Aula 1: Computação como Sistema Sociotécnico
Computação e Sociedade
1 Challenger — um desastre “técnico”?
Em janeiro de 1985, o engenheiro Roger Boisjoly, da Morton Thiokol, alertou por escrito sobre um problema nos anéis de vedação (O-rings) do foguete Challenger: em baixas temperaturas, o material perde elasticidade e não veda mais a junta do foguete propulsor, deixando escapar gases quentes.
“I am really afraid that if we do not take immediate steps we will place both the flight and the launching pad in serious danger. The consequences would be catastrophic and human lives would be put at risk.” (Van de Poel & Royakkers, 2011, p. 7)
A recomendação técnica era clara: não lançar em temperatura baixa. Na véspera do lançamento de janeiro de 1986, sob pressão organizacional — risco político e financeiro de mais um atraso — quatro gerentes da Thiokol decidiram por voto, sem os engenheiros presentes, recomendar o lançamento. A manhã do lançamento estava quase 4°C abaixo do ponto de congelamento. O Challenger explodiu 73 segundos depois, matando os sete astronautas a bordo — incluindo a professora Christa McAuliffe, a primeira civil selecionada para ir ao espaço, o que tinha atraído atenção de mídia bem acima do normal para aquele lançamento.
A comissão presidencial que investigou o desastre não concluiu “o anel de vedação falhou” — concluiu:
“A Presidential Commission determined that the whole disaster was due to inadequate communication at NASA.” (p. 9)
E o desfecho institucional reforça o ponto: a Thiokol não perdeu o contrato com a NASA, mas a agência mudou como funcionava —
“Engineers were given more of a say in matters. In the future, they will have the power to halt a flight if they had their doubts.” (p. 9)
Se a causa raiz de um dos maiores desastres da história da engenharia não foi um erro técnico isolado, em que sentido isso ainda é um problema de engenharia? A resposta desta aula: porque engenharia — e computação — nunca foi só técnica.
2 Sistemas Sociotécnicos
Computação não é feita só de hardware e software. É um sistema sociotécnico: tecnologia, pessoas, organizações e cultura se influenciam mutuamente — nenhuma delas determina as outras isoladamente.
“We shape our tools and thereafter they shape us”, disse John Culkin numa entrevista com o teórico da mídia Marshall McLuhan (citado em Steen, 2022, p. 29).
Essa ideia de coformação mútua rejeita duas posições mais simples e mais confortáveis, que Steen (2022, p. 30) nomeia explicitamente:
“An instrumental view on technology is mistaken; we cannot use technologies as neutral instruments. A deterministic view is also erroneous; technologies do not determine our behaviours. Rather, the design and usage of technologies are embedded in a web of more or less intentional decisions, of both designers and users, and these decisions have effects on the ways in which people use these technologies.”
Ou seja: não é “a tecnologia é só uma ferramenta neutra, o problema é sempre humano” (visão instrumental), e não é “a tecnologia determina o comportamento, a sociedade só reage” (visão determinista). É uma teia de decisões — de quem projeta e de quem usa — que se afetam mutuamente.
O Challenger é exatamente essa tese em ação, num só caso: a cultura organizacional (medo político de mais um atraso, hierarquia que excluiu os engenheiros da votação) moldou a decisão técnica (lançar mesmo com o alerta). E a decisão técnica — via o desastre — depois remoldou a cultura organizacional: a resposta da NASA não foi só refazer a engenharia mecânica do anel de vedação, foi reestruturar o próprio fluxo de decisão (dois anos de programa parado, engenheiros com poder de veto). Não é uma linha reta de causa e efeito — é um laço:
A cultura da NASA moldou a decisão técnica, e o resultado material dessa decisão (a explosão) forçou a mudança na estrutura de poder organizacional da agência.
Imagine que a NASA, depois do desastre, tivesse trocado apenas o material do anel de vedação por um que não perde elasticidade no frio — mas mantido exatamente a mesma estrutura de decisão, com gerentes podendo votar sobre o lançamento sem os engenheiros presentes. Essa NASA hipotética ainda ilustraria a tese da coformação mútua discutida neste bloco, ou o caso se reduziria a um problema puramente técnico, já resolvido?
Dica: pense no laço cultura → decisão → desastre → cultura remoldada. Um conserto que altera só um elo do laço remove o laço por completo, ou deixa os outros elos intactos, prontos para se repetir?
- □ Se a NASA tivesse trocado apenas o material do anel de vedação, sem alterar a estrutura de decisão que excluiu os engenheiros da votação, o mecanismo de coformação mútua (cultura molda decisão, decisão causa desastre, desastre remolda cultura) deixaria de ser relevante para esse caso, porque o problema já teria sido resolvido no nível técnico.
- □ No limite em que uma decisão técnica pudesse ser tomada sem qualquer influência de pressão cultural, política ou financeira — só engenheiros, sem gerentes, decidindo por critérios puramente técnicos —, o elo específico “cultura molda decisão” do laço discutido nesta aula deixaria de se aplicar a essa decisão particular.
- □ Um protocolo hospitalar de segurança cuja adoção depende da cultura de uma equipe médica — e cujo resultado (bom ou mau) depois altera a autonomia que os enfermeiros têm para recusar um procedimento — ilustra o mesmo princípio de coformação mútua apresentado nesta aula, mesmo em um domínio bem distante de foguetes.
- □ Como a coformação mútua rejeita tanto a visão instrumental quanto a determinista, conclui-se que cultura organizacional e decisão técnica têm sempre o mesmo peso causal em qualquer situação, nunca uma pesando mais que a outra.
3 Tecnologia Não é Neutra
Se tecnologia não é neutra, como isso aparece concretamente, em objetos do dia a dia? Duas ilustrações do Cap. 3 de Steen (2022) — uma dramática, uma banal, para mostrar que a tese vale nos dois extremos.
Robert Moses ocupou cargos-chave no planejamento urbano de Nova York entre os anos 1920 e 1960. Ele mandou construir uma série de viadutos sobre as parkways deliberadamente baixos:
“These bridges were so low that they prevented buses from going underneath. Effectively, these bridges prevented poor people, who typically could not afford cars and depended on buses, mostly people of colour, from visiting the parks and beaches. Moses used technology to achieve racist outcomes.” (Winner, apud Steen, 2022, p. 29)
Os viadutos ficavam nas parkways de Long Island que davam acesso a Jones Beach — a praia pública mais famosa da região. A altura de um viaduto de concreto — um detalhe de engenharia civil, aparentemente neutro — foi o mecanismo de uma política de exclusão racial. Nenhuma lei segregacionista escrita, nenhuma linha de código, nenhum algoritmo: só concreto. A tese vale igualmente, ou mais, para sistemas computacionais.
A segunda ilustração é deliberadamente banal, para mostrar que o fenômeno não exige um vilão nem uma intenção política explícita — só projeto (Steen, 2022, pp. 29–30):
“Shavers for men used to have screws, which suggests that men are able to do maintenance or repairs. Shavers for women, in contrast, have no screws, which suggests that they are unable to maintain or repair these devices. […] These features are referred to as scripts or affordances; these prescribe, to a smaller or larger extent, what people can and cannot do with these products.”
Um parafuso — ou a ausência dele — carrega uma suposição sobre quem tem permissão (ou capacidade) de abrir, entender e reparar um objeto. Em software, a mesma lógica aparece em toda parte: uma opção de configuração escondida, uma API fechada, um formato de arquivo proprietário são scripts — decisões de projeto que prescrevem o que o usuário pode e não pode fazer, silenciosamente.
O historiador da tecnologia Melvin Kranzberg resumiu isso numa frase (citada em Steen, 2022, p. 30):
“Technology is neither good nor bad; nor is it neutral.”
Se mesmo uma decisão “banal” de projeto — um parafuso — embute uma visão de mundo sobre gênero, a pergunta que importa deixa de ser só “a tecnologia é boa ou má” e passa a ser quem estava na sala quando a decisão foi tomada. A falta de diversidade entre quem projeta é o que permite que vieses, muitas vezes inconscientes, se tornem “detalhes” codificados no produto final — um fio que a Aula 9 (gênero e diversidade em computação) retoma com mais profundidade.
Suponha que ficasse provado, com documentos, que Robert Moses nunca pensou em raça ao definir a altura dos viadutos — que a medida foi só uma escolha de economia de concreto, sem qualquer intenção discriminatória. Isso enfraqueceria a conclusão de que “a tecnologia não é neutra”?
Dica: volte ao exemplo do parafuso do barbeador — ele já respondeu essa pergunta para um caso bem mais banal do que o dos viadutos.
- □ Se ficasse provado que Robert Moses nunca teve qualquer intenção racial ao definir a altura dos viadutos, a conclusão de que essa decisão de engenharia produziu exclusão racial deixaria de ser sustentável.
- □ No limite em que um objeto fosse projetado sem absolutamente nenhuma decisão implícita sobre quem pode usá-lo, repará-lo ou entendê-lo — nenhum script/affordance embutido —, a tese de Kranzberg de que “tecnologia não é neutra” deixaria de ter, nesse objeto específico, um mecanismo concreto para se apoiar.
- □ A mesma lógica do parafuso (aparelho masculino com parafuso visível x aparelho feminino selado) se aplicaria a um aplicativo bancário cujo menu de configurações avançadas (câmbio, API, taxas detalhadas) vem escondido por padrão para contas de pessoa física, mas visível por padrão para contas empresariais — mesmo sem nenhuma declaração explícita de que pessoas físicas “não sabem” usar essas opções.
- □ Como Kranzberg afirma que a tecnologia nunca é neutra, conclui-se que toda decisão de projeto é sempre fruto de uma intenção consciente e deliberada de quem a projetou.
4 O Mapa de Atores do Desenvolvimento Tecnológico
Se tecnologia não é neutra e não se desenvolve isolada da sociedade, quem, concretamente, participa dessa formação mútua? Van de Poel & Royakkers (2011, §1.6, p. 25) chamam de ator qualquer pessoa ou grupo que pode decidir como agir e agir sobre essa decisão:
“We use the term actor here for any person or group that can make a decision how to act and that can act on that decision.”
Quatro categorias de ator aparecem tipicamente no desenvolvimento tecnológico:
- Desenvolvedores e produtores — empresas de engenharia, laboratórios, universidades.
- Usuários — quem usa a tecnologia e formula exigências sobre seu funcionamento.
- Reguladores — governos e agências que formulam regras (segurança, concorrência).
- Outros atores — associações profissionais, sindicatos, grupos de interesse.
Distinto de ator: interessado (stakeholder) é quem tem interesse no resultado, mas não necessariamente pode influenciá-lo:
“Stakeholders are actors that have an interest (‘a stake’) in the development of a technology, but who cannot necessarily influence the direction of technological development.” (p. 26)
(Diagrama acima recriado a partir da Figura 1.6 de Van de Poel & Royakkers, 2011, p. 26 — “Technological development map of actors” — com a adição da seta para interessados, que não está na figura original mas foi discutida no texto que a segue.)
Os interesses desses atores frequentemente conflitam, então não há acordo automático sobre a direção “certa” do desenvolvimento tecnológico. E mesmo quando todos concordam, o resultado pode ser imprevisível — o caso do Teflon é o exemplo do livro: descoberto por acidente em 1938 (um químico da DuPont tentando desenvolver um refrigerante), décadas depois seu uso mais difundido — frigideiras antiaderentes — trouxe uma preocupação de saúde (o composto PFOA, “likely carcinogenic” segundo a EPA em 2005) que ninguém em 1938 tinha meios de prever. Esse é o dilema de Collingridge: não se pode prever as consequências no início do desenvolvimento tecnológico, mas quando elas aparecem, a tecnologia já está tão entranhada na sociedade que é difícil mudar de direção.
Uma resposta institucional a esse dilema, que vale nomear mesmo sem detalhar (Van de Poel & Royakkers, 2011, p. 28):
“The idea behind Constructive Technology Assessment (CTA) is that TA-like efforts are to be carried out parallel to the process of technological development and are fed back to the development and design process of technology. […] CTA aims at broadening the design process, both in terms of actors involved and in terms of interests, considerations and values taken into account in technological development.”
Ou seja: se prever o futuro é impossível e mudar o fim é tarde demais, a resposta é mudar o meio do processo, continuamente — em duas frentes:
- Expande-se a mesa — mais atores e stakeholders dentro do processo de design desde o início, não só ao final.
- Expandem-se os valores — considerações sociais avaliadas em paralelo ao desenvolvimento técnico, não depois dele.
Não é uma vacina contra o dilema de Collingridge — é uma forma de conviver com ele, corrigindo a rota mais cedo.
O dilema de Collingridge diz que não se pode prever, no início, as consequências de uma tecnologia — e que, quando elas aparecem, é tarde demais para mudar de direção com facilidade. Isso significa que ninguém pode ser responsabilizado por uma consequência que só apareceu décadas depois, como o PFOA do Teflon?
Dica: separe duas perguntas diferentes — “era possível prever?” e “algum ator tinha meios de investigar e não investigou?”.
- □ Se, em 1938, já existissem testes toxicológicos capazes de detectar o risco do PFOA e a DuPont tivesse optado por não realizá-los antes de comercializar o Teflon, o caso deixaria de ilustrar o dilema de Collingridge como apresentado na aula e passaria a ilustrar um problema diferente — omissão evitável, não imprevisibilidade genuína.
- □ No limite em que fosse possível prever, no momento em que uma tecnologia é criada, todas as suas consequências futuras com certeza absoluta, o dilema de Collingridge deixaria de se aplicar a essa tecnologia.
- □ A mesma estrutura do dilema de Collingridge (impossível prever no início, caro corrigir depois) se aplicaria à adoção em massa de um pesticida agrícola cujo efeito sobre populações de abelhas só se torna visível depois de décadas de uso disseminado no campo.
- □ Como o Constructive Technology Assessment (CTA) busca ampliar quem participa do processo de design e quais valores são considerados, conclui-se que sua adoção elimina por completo o risco de consequências imprevistas de uma nova tecnologia.
5 Feedback Loop e Responsabilidade
Um exemplo contemporâneo de computação, para fechar. Algoritmos de redes sociais otimizados para tempo de tela usam, nas palavras de Steen (2022, p. 32):
“decades of knowledge from the domain of gambling and slot machines. With buzzing sounds and flashing icons, they grab our attention as often as possible. With infinite scrolling and seductive suggestions (‘watch next’), they hold our attention as long as possible.”
Não é acusação abstrata — tem nome de quem trabalhou por dentro e saiu para denunciar:
“Former Google designer Tristan Harris is one of the people who helped to expose such practices. We are vulnerable to how these designs activate our behavioural impulses. Our brains have evolved to be activated by novel or interesting sensory input.” (Steen, 2022, p. 32)
O comportamento capturado gera os dados que retreinam o algoritmo, que fica melhor em capturar atenção — um feedback loop não-técnico entre projeto de produto e comportamento humano em massa:
Nenhuma linha de código isolada “causa” o resultado — ele emerge do ciclo contínuo: o código molda o comportamento, que gera dados, que reescrevem o código.
Isso nos leva de volta à pergunta de responsabilidade que o Challenger já tinha levantado. Van de Poel & Royakkers (2011, p. 28) chegam a uma conclusão quase contraintuitiva:
“In one sense, it diminishes the responsibility of engineers because it makes clear that engineers are just one of the many actors involved in technology development and cannot alone determine technological development and its social consequences. In another sense, however, it extends the responsibility of engineers because they have to take into account a range of stakeholders and their interests.”
O contexto social diminui a responsabilidade individual (você é só um entre muitos atores; o desenvolvedor isolado não determina todas as consequências sociais do produto) e, ao mesmo tempo, amplia essa responsabilidade (você precisa considerar interessados que não estão na sala). Não são a mesma pergunta, e confundir uma com a outra é o erro mais comum ao discutir “de quem é a culpa” quando um sistema falha: não ser o único culpado não significa estar isento de responsabilidade moral sobre o que se projeta.
Ponte para a Aula 2
Falta uma ferramenta: se ninguém decide isoladamente, e as consequências são difíceis de prever, como raciocinar sistematicamente sobre o que é certo fazer dentro dessa teia sociotécnica? É o assunto da Aula 2 — as principais correntes da ética normativa (consequencialismo, deontologia, ética das virtudes) e o Ciclo Ético como método de deliberação.
Um designer implementou a rolagem infinita e as notificações “puxa-atenção” só porque seu gerente exigiu uma métrica de tempo de tela. Ele não escolheu a métrica, só a implementou. O contexto sociotécnico discutido nesta aula “diminui” ou “amplia” a responsabilidade moral desse designer específico — ou as duas coisas ao mesmo tempo?
Dica: volte à citação de Van de Poel & Royakkers (p. 28) — ela não escolhe um lado, afirma os dois sentidos ao mesmo tempo.
- □ Se o feedback loop do algoritmo fosse interrompido em um único ponto — o sistema parasse de coletar dados de engajamento para retreinamento —, o ciclo descrito na aula (projeto → comportamento → dados → retreinamento → projeto) deixaria de se realimentar, mesmo que o design inicial do produto (rolagem infinita, notificações) permanecesse intacto.
- □ No limite em que um único desenvolvedor tomasse, sozinho, toda e qualquer decisão de projeto de uma rede social usada por bilhões de pessoas — sem gerentes, investidores ou reguladores envolvidos —, a parte da tese de Van de Poel & Royakkers que diz que o contexto social “diminui” a responsabilidade individual (por você ser só um entre muitos atores) deixaria de se aplicar a esse desenvolvedor específico.
- □ A mesma lógica do paradoxo da responsabilidade (o contexto ao mesmo tempo diminui e amplia a responsabilidade individual) se aplicaria a um médico que segue um protocolo hospitalar padronizado, mas que também precisa considerar necessidades específicas de pacientes que o protocolo não previu.
- □ Como a aula mostra que o desenvolvedor individual é “apenas um entre muitos atores” no desenvolvimento tecnológico, conclui-se que nenhuma responsabilidade moral recai sobre designers individuais quando uma rede social causa dano social em larga escala.
6 Exercícios
6.1 Questões discursivas
Explique, com suas próprias palavras, a diferença entre a visão instrumental, a visão determinista e a tese da coformação mútua sobre tecnologia. Use o caso do Challenger (ou um exemplo próprio, de fora da aula) para mostrar como a coformação mútua aparece na prática, no laço entre decisão técnica e cultura organizacional.
A aula usa dois exemplos para mostrar que a tecnologia não é neutra — as pontes de Robert Moses (dramático) e os parafusos dos barbeadores (banal). Escolha um objeto ou sistema de software do seu cotidiano (fora dos exemplos da aula) e identifique um script/affordance embutido em seu projeto: quem esse projeto inclui ou exclui, e se foi necessária uma intenção deliberada para isso acontecer.
Usando o mapa de atores (desenvolvedores, usuários, reguladores, outros atores), a distinção entre ator e interessado (stakeholder), e o dilema de Collingridge, escolha uma tecnologia atual (pode ser inteligência artificial, redes sociais, ou outra de sua escolha) e discuta: quais atores provavelmente estavam “na sala” nas decisões de projeto, quais interessados prováveis ficaram de fora, e como um processo de Constructive Technology Assessment (CTA) poderia ter mudado o resultado.
6.2 Questões de Verdadeiro/Falso
Cada bloco de 4 itens trata do mesmo tema. A questão só é considerada correta se todos os 4 itens forem julgados corretamente (deixar em branco tem penalidade de 20% da nota da questão).
6.3 Aviso
As questões de Verdadeiro/Falso e discursivas ficam sem solução neste arquivo — são para resolução autônoma do aluno, fora do horário de aula.