Aula 3: Computação, Seus Domínios e Responsabilidade Profissional

Computação e Sociedade

Marcos M. Raimundo — Instituto de Computação, UNICAMP

2026-08-30

BART — um código que não protegeu quem o seguiu

O Caso BART (1972)

Três engenheiros do Bay Area Rapid Transport Project alertam, desde 1969, sobre falhas de segurança no sistema de trens automatizados.

“The response was ‘don’t make trouble.’”

Em 1971, contornam a hierarquia e levam o caso ao conselho diretor. A história vaza à imprensa — e eles são demitidos sem justa causa.

O IEEE Intervém — e Não Basta

Argumento do IEEE

“According to the IEEE’s professional code, engineers are responsible for the ‘safety, health and welfare of the public.’ […] the professional code is an implicit aspect of the employment contract.”

Aviso

Três semanas após o início da operação, o sistema tem um acidente. Os engenheiros aceitam um acordo — o emprego não voltou.

A Pergunta Que Abre a Aula

Nota

Se seguir o código profissional não protegeu quem o seguiu, para que serve um código de conduta?

O plano de hoje:

O que um código pode fazer.
Quais estruturas dão — ou deixam de dar — força real a um código: o conselho de profissão, a lei de proteção de dados, e a regulamentação da profissão.
O que nenhuma dessas estruturas garante, mesmo quando existem.

Pergunta provocadora — um argumento correto, mas sem poder de se fazer valer

O IEEE defendeu, numa carta ao tribunal, que seguir o código profissional deveria contar como cumprir uma obrigação implícita do contrato de trabalho — um argumento logicamente coerente. Mesmo assim, os engenheiros perderam o emprego e só receberam um acordo extrajudicial, sem que a Justiça validasse formalmente a tese do IEEE. O que esse desfecho sugere sobre a diferença entre um código estar “certo” no papel e um código ter força real?

Dica: pense no que faltou entre o IEEE ter um argumento coerente e esse argumento efetivamente proteger os três engenheiros — quem, ou o quê, tinha o poder de fazer a diferença?

□ Se o tribunal tivesse aceitado integralmente o argumento do IEEE, agir de acordo com o código profissional passaria a valer como cumprimento de uma obrigação contratual — tornando a demissão, em princípio, contestável como quebra de contrato, não como insubordinação.
□ Como os engenheiros aceitaram um acordo extrajudicial de indenização, isso significa que a Justiça reconheceu formalmente que a demissão foi ilegal e que a tese do IEEE prevaleceu como parte do contrato de trabalho.
□ Uma enfermeira que, depois de ser ignorada nos canais internos do hospital, leva ao conselho de administração uma preocupação de segurança do paciente, e é demitida em seguida, ocupa posição estruturalmente análoga à dos engenheiros do BART — mesmo numa profissão e época diferentes.
□ Se os engenheiros do BART nunca tivessem contornado a hierarquia e apenas repetido os mesmos memos internos indefinidamente, sem acionar o conselho ou a imprensa, a falha de segurança que causou o acidente de outubro de 1972 teria deixado de existir.

V/F — Um Código Sem Poder de Se Fazer Valer: Resposta

Dica

✔ Verdadeiro — é a lógica do próprio argumento do IEEE: se o código é parte do contrato, cumpri-lo é cumprir o contrato, não violá-lo.
✗ Falso — um acordo extrajudicial evita justamente uma decisão formal do tribunal sobre o mérito; aceitar indenização não é vitória jurídica da tese do IEEE.
✔ Verdadeiro — mesma estrutura institucional: alertar, ser ignorado, escalar, ser demitido — a profissão e a época mudam, o mecanismo não.
✗ Falso — a falha técnica existia independente de como os engenheiros agiram; contornar a hierarquia decidiu se foram demitidos, não se o sistema era inseguro.

Retomando: um argumento certo no papel não bastou porque faltava poder institucional de fazê-lo valer — exatamente a lacuna que os Blocos 2 a 4 vão examinar.

Os Códigos de Conduta, Concretamente

Pergunta provocadora — um código com muitas cláusulas: elas sempre convergem?

O código da ACM tem cláusulas em três partes diferentes — princípios éticos gerais, responsabilidades profissionais, liderança. Elas foram pensadas para se reforçar mutuamente. Mas será que uma ação pode cumprir uma cláusula e, ainda assim, violar outra do mesmo código?

Dica: pense num sistema que cumpre a letra do princípio 1.1 (“contribuir para a sociedade”) só no discurso institucional, mas nunca chega a fazer o que o princípio 2.5 pede (avaliação de riscos).

□ Uma empresa que divulga publicamente um compromisso com o princípio 1.1 da ACM (“todas as pessoas são interessadas na computação”), mas nunca implementa nenhuma medida concreta de avaliação de risco exigida pelo princípio 2.5, está cumprindo o código da ACM, porque 1.1 e 2.5 pertencem a partes independentes do texto.
□ Se a Parte 3 do código (liderança profissional) não existisse, um profissional sem cargo de gestão ainda estaria integralmente coberto pelas Partes 1 e 2 nas decisões técnicas do seu próprio trabalho.
□ A lógica do princípio 3.7 da ACM (“cuidado especial com sistemas integrados à infraestrutura da sociedade”) se aplicaria, por analogia, a um provedor de nuvem que hospeda a maior parte dos aplicativos bancários de um país, mesmo esse provedor nunca sendo mencionado como exemplo no texto do código.
□ Como o código da ACM é organizado em três partes numeradas, isso significa que, em qualquer conflito entre cláusulas de partes diferentes, a parte de número mais baixo (Parte 1) sempre tem precedência automática sobre as demais.

V/F — Um Código com Muitas Cláusulas: Resposta

Dica

✗ Falso — as partes do código não são independentes; cumprir a retórica de 1.1 sem a prática de 2.5 é o mesmo padrão de window-dressing que o Bloco 5 vai nomear.
✔ Verdadeiro — a Parte 3 acrescenta obrigações de quem lidera; não substitui as Partes 1 e 2, válidas para qualquer profissional.
✔ Verdadeiro — o critério do princípio é o grau de integração à infraestrutura social, não uma lista fechada de exemplos.
✗ Falso — a numeração é organizacional, não uma ordem de precedência em caso de conflito entre partes.

Retomando: as cláusulas de um mesmo código podem entrar em tensão entre si — cumprir uma na letra não garante cumprir outra na prática.

Código de Conduta: Definição

“Codes of conduct are codes in which organizations lay down guidelines for responsible behavior of their members.”

— Van de Poel & Royakkers (2011, p. 33)

Código Profissional

Formulado por associações (ex.: IEEE, NSPE, ACM)

Código Corporativo

Formulado pela própria empresa empregadora

Cláusulas Reais (NSPE, FEANI)

“Engineers shall perform services only in the areas of their competence.” — NSPE

> “Engineers shall hold paramount the safety, health, and welfare of the public.” — NSPE

> “Engineers shall maintain their relevant competences […] and only undertake tasks for which they are competent.” — FEANI

E na Computação, Especificamente?

Aviso

“Esta profissão ainda não é reconhecida oficialmente no Brasil […] não há um código de ética profissional formal.”

— Maciel & Viterbo (2020, p. 199)

Dois códigos de adesão voluntária, bem mais elaborados que NSPE/FEANI:

ACM — geral, cobre também hardware/infraestrutura/redes
IEEE-CS/ACM — voltado à Engenharia de Software

O Código de Ética da ACM — Estrutura

Parte	O que cobre
1. Princípios éticos gerais	Valores morais amplos
2. Responsabilidades profissionais	Qualidade, competência, conduta
3. Liderança profissional	Obrigações de quem gerencia

Fonte primária (acm.org/code-of-ethics) — não uma citação literal dos livros-texto.

ACM, Na Prática — Parte 1

“1.1 Contribute to society and to human well-being, acknowledging that all people are stakeholders in computing.”

Recomendador que amplifica desinformação afeta a sociedade, não só quem clica.

> “1.4 Be fair and take action not to discriminate.”

Testar taxas de erro por subgrupo, não só a acurácia agregada.

ACM, Na Prática — Parte 2

“2.1 Strive to achieve high quality […]”

Não lançar sabendo que a cobertura de testes é insuficiente, só por prazo de marketing.

> “2.5 Give comprehensive […] evaluations […] including analysis of possible risks.”

Documentar a taxa de erro por subgrupo de um sistema de reconhecimento facial antes de vender — não escondê-la.

ACM, Na Prática — Parte 3

“3.4 Articulate, apply, and support policies […] that reflect the principles of the Code.”

Um tech lead que institui canal seguro para levantar preocupação ética — não deixa só à boa vontade.

> “3.7 Recognize and take special care of systems that become integrated into the infrastructure of society.”

Um sistema de pagamento nacional (Pix) pede padrão de cuidado maior que um app de nicho.

O Código IEEE-CS/ACM — 8 Princípios

PUBLIC — interesse público acima de tudo (o que o BART invocou)

CLIENT AND EMPLOYER — interesses do cliente, consistentes com PUBLIC

PRODUCT · JUDGMENT · MANAGEMENT — padrão técnico, julgamento independente, gestão ética

PROFESSION · COLLEAGUES · SELF — reputação da profissão, colegas, aprendizado contínuo

De Volta ao Caso BART: o Princípio PUBLIC

“Software engineers shall act consistently with the public interest.”

Dica

É exatamente o princípio que o IEEE invocou na carta amicus curiae — décadas antes de este código de Engenharia de Software específico existir, mas com a mesma lógica central.

Três Objetivos Possíveis de um Código

Tipo	Objetivo
Aspiracional	Expressar valores ao mundo externo
Consultivo	Ajudar o julgamento moral em situações concretas
Disciplinar	Garantir conformidade de todos

NSPE, FEANI, ACM, IEEE-CS/ACM: todos consultivos. Nenhum é disciplinar de fato — falta uma estrutura institucional com poder de fiscalizar (Bloco 3).

Julgue V ou F: ACM e IEEE-CS, Dois Códigos, Dois Focos

Dica

Julgue V ou F — a questão só conta se acertar os 4 itens:

□ Como o código da ACM é “mais geral” e o do IEEE-CS/ACM é “voltado à Engenharia de Software”, um profissional que só desenvolve software está coberto pelo IEEE-CS/ACM e por isso não precisa se preocupar com o código da ACM.
□ Se a Informática brasileira tivesse, hoje, um conselho profissional próprio, isso automaticamente tornaria o código da ACM disciplinar para quem atua no Brasil.
□ No caso BART, se os engenheiros estivessem sob um código sem cláusula de confidencialidade (como o IEEE-CS/ACM), o princípio PUBLIC ainda daria suporte à decisão de levar a preocupação ao conselho diretor.
□ Um princípio como o 3.7 da ACM se aplicaria, por analogia, a um sistema de identificação digital nacional, mesmo esse não sendo um “produto de software” no sentido de um aplicativo comercial.

Julgue V ou F: ACM e IEEE-CS — Resposta

Dica

✗ Falso — os dois códigos não são substitutos um do outro; “mais geral” significa escopo mais amplo, não que a ACM deixe de se aplicar a quem desenvolve software.
✗ Falso — um conselho brasileiro teria poder legal sobre o exercício no Brasil, mas não converteria automaticamente um código internacional voluntário em disciplinar.
✔ Verdadeiro — PUBLIC foi exatamente o princípio invocado no caso real; a ausência de cláusula de confidencialidade só remove uma obrigação concorrente.
✔ Verdadeiro — o critério do princípio é o grau de integração à infraestrutura social, não o tipo de produto.

Pergunta provocadora — consultivo, mas não disciplinar: o que isso muda na prática?

Vimos que NSPE, FEANI, ACM e IEEE-CS/ACM são todos consultivos, mas nenhum é disciplinar de fato. Se um profissional violar abertamente uma cláusula de qualquer um desses códigos, o que exatamente acontece com ele, hoje, só por causa disso?

Dica: separe duas perguntas — “o código diz que isso é errado” e “existe alguém com poder de impedir esse profissional de continuar exercendo a profissão por causa disso”.

□ Um engenheiro de software que viola abertamente o princípio PUBLIC do código IEEE-CS/ACM, mas nunca causou dano concreto a ninguém, ainda pode continuar exercendo a profissão livremente, porque nenhuma das quatro entidades (NSPE, FEANI, ACM, IEEE-CS/ACM) tem poder de revogar seu direito de trabalhar.
□ Se a ACM decidisse, unilateralmente, expulsar um sócio por violar o código, essa expulsão teria, por si só, o mesmo efeito prático sobre a carreira dele que uma cassação de registro pelo CREA tem sobre um engenheiro civil.
□ A mesma lógica “consultivo, não disciplinar” se aplicaria a um código de ética interno de uma ONG sem qualquer vínculo com órgão fiscalizador externo — ele pode orientar decisões dos voluntários, mas não impede, por si só, que alguém continue atuando na área depois de violá-lo.
□ Como o texto afirma que “a maioria dos códigos profissionais de engenharia é consultiva”, isso implica que nenhum código de engenharia, em nenhum país, jamais teve algum componente disciplinar.

V/F — Consultivo, mas Não Disciplinar: Resposta

Dica

✔ Verdadeiro — sem conselho, nenhuma das quatro entidades tem poder legal de impedir o exercício da profissão; só resta a consequência reputacional dentro da comunidade.
✗ Falso — filiação voluntária à ACM não é pré-condição legal para exercer a profissão em lugar nenhum; perdê-la não equivale a perder um registro exigido por lei.
✔ Verdadeiro — mesma estrutura fora da engenharia: código sem fiscalização externa orienta, mas não expulsa ninguém do mercado.
✗ Falso — “a maioria” não é “todos”; o próprio contraste do bloco é com códigos corporativos, mais frequentemente disciplinares.

Retomando: é exatamente essa lacuna — poder legal de excluir do exercício — que o próximo bloco examina.

Formas Judicializadas de Regular a Atuação

O Que um Conselho de Profissão de Fato Faz

“Estes códigos são elaborados pelos respectivos Conselhos que representam e fiscalizam o exercício de cada profissão.”

— Maciel & Viterbo (2020, p. 199)

Três funções: registra · fiscaliza · poder legal de impedir o exercício por quem não é registrado.

A Lei Que Dá Força ao Conselho

Lei 5.194/1966, Art. 6º

“Exerce ilegalmente a profissão de engenheiro […] a pessoa física ou jurídica que […] não possua registro nos Conselhos Regionais.”

Dica

Sem essa lei por trás, “disciplinar” no papel não teria força — ficaria no nível dos códigos do Bloco 2.

LGPD/GDPR: Outra Forma de Regulação Judicializada

Em vez de licenciar quem exerce, regula diretamente como a atuação deve ocorrer — qualquer um que trate dados pessoais, com multas reais.

Os Seis Princípios do Art. 6º da LGPD

Finalidade · Adequação e Necessidade · Livre Acesso e Transparência

Segurança e Prevenção · Não Discriminação · Responsabilização

Lei 13.709/2018, Art. 6º — fonte primária/legal, não citação literal dos livros-texto.

Checklist Prática

Para que finalidade específica? Só esse dado, ou mais?
O titular saberia, em linguagem simples, o que é feito com o dado dele?

3. Se exposto, que dano causaria a uma pessoa real? 4. Algum proxy poderia discriminar um grupo sem intenção? 5. A equipe conseguiria provar conformidade, se pedissem hoje?

Conselho e LGPD: Dois Mecanismos, Um Gênero

	Conselho	LGPD/GDPR
Regula	Quem exerce	Como os dados são tratados
Aplica-se a	Só a profissão regulamentada	Qualquer um que trate dados
A Informática tem?	Não	Parcialmente

Dica

Regulação judicializada parcial — por um mecanismo, não pelo outro.

Julgue V ou F: Conselho e LGPD, Duas Regulações Judicializadas

Dica

Julgue V ou F — a questão só conta se acertar os 4 itens:

□ Como tanto o conselho de profissão quanto a LGPD são formas de regulação com força de lei, as duas regulam exatamente o mesmo aspecto da atuação profissional, só com nomes diferentes.
□ Se o Brasil criasse hoje um conselho de profissão para a Informática, a LGPD se tornaria redundante e poderia ser revogada sem perda de proteção ao cidadão.
□ Uma pessoa física sem qualquer vínculo profissional formal com Informática, que trata dados pessoais de terceiros de forma amadora, ainda está sujeita aos princípios do Art. 6º da LGPD.
□ O princípio da “necessidade” (Art. 6º, III) se aplicaria a um sistema de recomendação que coleta o histórico completo de navegação para uma funcionalidade que só precisaria da categoria do último produto visto.

Julgue V ou F: Conselho e LGPD — Resposta

Dica

✗ Falso — regulam aspectos diferentes: quem exerce vs. como qualquer um deve tratar dados.
✗ Falso — a LGPD regula qualquer agente, registrado ou não, dentro ou fora da Informática — os mecanismos não se sobrepõem completamente.
✔ Verdadeiro — a LGPD regula a atividade de tratamento de dados, não exige registro em conselho nenhum.
✔ Verdadeiro — é exatamente o tipo de caso que o princípio de necessidade/minimização visa coibir.

Pergunta provocadora — dois mecanismos de força legal: quando um supre a ausência do outro?

A Informática não tem conselho de profissão, mas já tem a LGPD. Isso significa que, na prática, um profissional de computação no Brasil já está sob alguma forma de regulação judicializada — só que parcial. Em que situações concretas essa parcialidade importa, e em quais ela não faz diferença?

Dica: pense em um profissional de computação cujo trabalho nunca envolve dado pessoal nenhum — o que exatamente protege (ou não protege) esse profissional, hoje?

□ Um profissional de computação que constrói exclusivamente sistemas internos de simulação numérica, sem qualquer dado pessoal envolvido, está, hoje, totalmente fora do alcance de qualquer regulação judicializada discutida neste bloco.
□ No limite em que uma organização deixasse de tratar qualquer dado pessoal (usando só dados sintéticos ou completamente anônimos e irreversíveis), ela deixaria de estar sujeita aos princípios do Art. 6º da LGPD sobre esse tratamento específico, mesmo continuando sujeita a outras leis gerais.
□ A mesma lógica de “regular o comportamento, e não a identidade de quem o exerce” que caracteriza a LGPD também descreve como leis de defesa do consumidor regulam a relação entre qualquer empresa e seus clientes, independentemente de existir ou não um conselho profissional de vendedores.
□ Como o Brasil tem uma lei geral de proteção de dados desde 2018, isso resolve, na prática, a mesma lacuna que a ausência de um conselho de profissão deixa em aberto — afinal, ambas são formas de regulação com força de lei.

V/F — Dois Mecanismos de Força Legal: Resposta

Dica

✔ Verdadeiro — sem dado pessoal envolvido, a LGPD simplesmente não se aplica, e não há conselho para preencher essa lacuna.
✔ Verdadeiro — sem dado pessoal identificável, o objeto de regulação desses princípios específicos deixa de existir.
✔ Verdadeiro — mesma lógica de regular comportamento/atividade, transposta para outro domínio, independente de licenciamento.
✗ Falso — os dois mecanismos regulam coisas diferentes; a LGPD não substitui o que um conselho faria sobre competência técnica mínima.

Retomando: a Informática tem hoje regulação judicializada parcial — por um mecanismo (dados), não pelo outro (registro/fiscalização de quem exerce).

Regular ou Não a Informática — no Brasil e no Mundo

Pergunta provocadora — regulamentar a Informática: o que cada argumento resolve, e o que não resolve?

O próprio livro lista desvantagens reais de regulamentar a profissão — custo, perda de multidisciplinaridade, fiscalização que não garante qualidade. Nenhuma dessas desvantagens, isoladamente, é um argumento definitivo contra regulamentar. O que, então, cada uma delas realmente mostra sobre o que um conselho de profissão consegue e não consegue resolver?

Dica: separe “problemas que um conselho resolveria” de “problemas que continuariam existindo mesmo com um conselho”.

□ Se a Informática brasileira tivesse sido regulamentada já nos anos 1970, quando o movimento começou, isso teria impedido, sozinho, o crescimento posterior da área para mais de mil cursos de graduação em 2016.
□ No limite em que um conselho de Informática cobrasse a mesma anuidade que hoje é cobrada por profissionais autônomos sem filiação nenhuma (ou seja, custo adicional zero), a crítica de “aumento de custo” listada pelo livro deixaria de se aplicar a esse conselho hipotético.
□ A crítica de que “conselhos não têm meios para evitar a precarização do trabalho, papel que cabe aos sindicatos” se aplicaria igualmente a um cenário em que a Informática fosse regulamentada, mas os profissionais não tivessem nenhum sindicato atuante no setor — nesse caso, nem o conselho nem nenhuma outra estrutura cobriria essa função.
□ Como o livro reconhece “vantagens e desvantagens” da regulamentação sem tomar partido explícito, isso significa que a decisão de regulamentar ou não a Informática é, do ponto de vista do próprio livro, uma questão puramente técnica, sem nenhuma dimensão de valores ou de quem ganha e quem perde com a escolha.

V/F — Regulamentar a Informática: Resposta

Dica

✗ Falso — regulamentação da profissão e expansão de cursos de graduação são mecanismos independentes; nada na fonte liga um ao outro dessa forma.
✔ Verdadeiro — a crítica é especificamente sobre custo; sem custo adicional, ela deixa de se aplicar a esse conselho hipotético.
✔ Verdadeiro — extensão limpa da divisão de papéis “conselho ≠ sindicato” para um cenário em que nenhum dos dois cobre a lacuna.
✗ Falso — as vantagens/desvantagens listadas são, precisamente, sobre quem ganha e quem perde com a escolha — uma questão distributiva, não neutra.

Retomando: cada desvantagem aponta para um problema real que um conselho não resolveria por si só — não para a conclusão de que regulamentar é, sozinho, bom ou mau.

Mapeando a Formação da Computação no Brasil

1940s: primeiros computadores digitais eletrônicos no mundo. No Brasil, a história da Computação na universidade é “bem curta” (Maciel & Viterbo, 2020, p. 12).

1968 — UFBA cria o primeiro Bacharelado do país (Processamento de Dados). 1969 — Unicamp cria seu Bacharelado em Ciência da Computação.

2016: 1288 cursos de graduação, 133 mil ingressantes, 42 mil concluintes naquele ano só.

De quase inexistente em 1950 a mais de mil cursos em 2016 — rápido o bastante para a questão da regulamentação profissional já se tornar relevante nos anos 1970, só 20 anos após os primeiros computadores chegarem ao país.

Quantas Profissões o Brasil Regula, De Fato?

Informática: Regular ou Não? Prós e Contras Reais

“Há […] grupos que defendem […] um modelo semelhante a dos engenheiros, mas há outros que veem vantagens […] que o exercício profissional em Informática continue livre.”

Desvantagens de regular (listadas pelo livro):

Custo (anuidades) + proliferação de diplomados sem mais qualidade
Reduz a multidisciplinaridade histórica da área
Não resolve precarização, PJ, ou terceirização
Fiscalização por diploma não garante competência real

E em Outros Países? Estados Unidos

2013: NCEES cria exame de licenciamento (PE) para Software Engineering.

Aviso

2019: descontinuado. Só 81 candidatos em 5 aplicações — desinteresse voluntário, não proibição.

Canadá: Título Protegido, Tensão Real

“Engineer” é título legalmente protegido por reguladores provinciais (ex.: APEGA).

Importante

2024: Alberta abre exceção legal para “software engineer” sem licença da APEGA.

Reino Unido: Uma Terceira Via

Títulos de engenharia protegidos por carta régia — mas o CITP (British Computer Society) é voluntário, sem licença compulsória.

Dica

Meio-termo entre “regulamentação plena” e “nada” — nem Brasil, nem EUA adotaram isso para computação.

Não é uma Esquisitice Brasileira

EUA: exame morreu por desinteresse. Canadá: tensão aguda, província recuando. Reino Unido: via voluntária, meio-termo.

Nota

É uma versão local de uma pergunta sem resposta óbvia em nenhum lugar do mundo.

O Elo Fica Completo

Só códigos voluntários (ACM, IEEE-CS/ACM) para computação no Brasil — nenhum disciplinar, por falta de conselho.

A única regulação judicializada que hoje alcança a atuação em computação é parcial: a LGPD regula o tratamento de dados, não define quem pode se chamar “profissional de Computação”.

Julgue V ou F: Regular ou Não a Informática, no Brasil e no Mundo

Dica

Julgue V ou F — a questão só conta se acertar os 4 itens:

□ Se o exame PE para Software Engineering nos EUA tivesse atraído adesão voluntária maciça, isso teria, sozinho, tornado “software engineer” um título legalmente protegido nos Estados Unidos.
□ A decisão de Alberta, em 2024, de abrir uma exceção legal para o uso do título “software engineer” sem licença é evidência de que a proteção de título de engenharia no Canadá está ficando mais rígida com o tempo, não mais flexível.
□ O modelo do Chartered IT Professional (CITP) britânico, por ser título voluntário sem licença compulsória, tem, na prática, o mesmo status regulatório dos códigos consultivos da ACM e do IEEE-CS/ACM.
□ Como EUA, Canadá e Reino Unido lidam com “software engineer” de formas diferentes entre si, isso significa que pelo menos um desses três países resolveu definitivamente a questão de regular ou não a Informática.

Julgue V ou F: Regular ou Não — Resposta

Dica

✗ Falso — proteção legal de título depende de legislação, não da popularidade de um exame voluntário; o exame morreu por baixa demanda, não por falta de força legal.
✗ Falso — é o oposto: a exceção de Alberta é um afrouxamento pontual, não um endurecimento.
✔ Verdadeiro — os três são mecanismos voluntários, sem poder de exclusão do mercado; a diferença é de prestígio, não de força legal.
✗ Falso — nenhum dos três resolveu a questão de forma limpa: é uma pergunta sem resposta óbvia em qualquer lugar.

Pergunta provocadora — três países, três desfechos: o que muda a “força” de uma proteção de título?

Nos três países, a “força” da proteção do título de engenheiro parece vir de fontes diferentes — adesão voluntária, poder legal, ou nada disso. O que, exatamente, diferencia um exame que morre por desinteresse (EUA) de um título protegido que ainda assim precisa abrir exceções (Canadá)?

Dica: pense se a “força” de uma regra vem de quantas pessoas escolhem segui-la voluntariamente, ou de haver ou não sanção legal por não seguir.

□ Se o Reino Unido exigisse o CITP como licença obrigatória para atuar em TI (em vez de título voluntário), a distinção entre “regulamentação plena” e a “terceira via” que a aula descreve deixaria de fazer sentido para esse país — o CITP passaria a funcionar como os títulos protegidos de Chartered Engineer.
□ No limite em que a APEGA (Alberta) decidisse, ao contrário do que fez em 2024, proibir completamente o uso de “software engineer” mesmo fora de contextos de engenharia regulamentada (ex.: em cargos internos de empresas de tecnologia sem responsabilidade legal formal), essa seria uma ampliação, não uma redução, do escopo da proteção de título.
□ A tensão entre “proteção de título forte, mas questionada na prática” que aparece no caso canadense se repetiria, em princípio, em qualquer profissão brasileira regulamentada (ex.: arquitetura, cujo título também é protegido por lei) se uma nova especialidade técnica surgisse rapidamente sem estar prevista na lei original.
□ Como o Reino Unido optou por um título voluntário (CITP) em vez de regulamentação plena, e isso não impediu o desenvolvimento da indústria de software britânica, conclui-se que qualquer forma de regulamentação plena necessariamente atrapalharia o desenvolvimento de uma indústria de tecnologia.

V/F — Três Países, Três Desfechos: Resposta

Dica

✔ Verdadeiro — tornar o CITP obrigatório colapsaria a “via intermediária” na categoria de regulamentação plena.
✔ Verdadeiro — é o sentido oposto ao de 2024: mais restrição, não menos, sobre o uso do título.
✔ Verdadeiro — mesma tensão institucional (especialidade nova vs. lei antiga), transferida para qualquer profissão regulamentada no Brasil.
✗ Falso — um único caso não sustenta uma afirmação causal universal; a fonte só diz que nenhum país resolveu isso de forma limpa.

Retomando: a “força” de uma regra vem de sanção legal, não de adesão voluntária — e nenhum dos três países escapou dessa tensão.

Os Limites Conhecidos dos Códigos

Autointeresse e Window-Dressing

“Codes of conduct are a form of self-regulation. […] to avoid government regulation or to silence dissident voices.”

Caso: John Tozer (1989)

Engenheiro australiano criticou publicamente uma decisão de saneamento — foi expulso da ACEA e perdeu contratos que exigiam essa filiação.

Google na China: Quando o Lema Não Basta

Lema: “Don’t be Evil”. Prática: concorda em censurar buscas (“Grande Firewall”).

Importante

“Self-censorship […] conflicts deeply with our core principles.” — o próprio VP do Google.

Callback ao Bloco 3: Código Bonito vs. Lei Com Dentes

Código de ética interno vago custa reputação só se exposto.

Lei de proteção de dados com sanções reais custa dinheiro e liberdade de ação independentemente de exposição pública.

Dica

É exatamente essa diferença que motiva, historicamente, autorregulação usada como substituto retórico de regulação real.

Vagueza: o Caso da “Lealdade”

Lealdade Acrítica

“Placing the interests of the employer […] above any other consideration.”

Lealdade Crítica

“Giving due regard to the interest of the employer, insofar as […] the employee’s […] ethics [allow].”

Os engenheiros do BART foram “desleais” só sob a leitura acrítica.

Os Códigos Discordam Entre Si

Código	Confidencialidade?	Em risco ao público
NSPE	Sim	Informar autoridades
FEANI	Sim	Silente
IEEE	Não	Encoraja falar publicamente

Aviso

O mesmo dilema do whistleblower das Aulas 1–2 — agora como um ponto em que os próprios códigos não concordam.

Pode-se Viver pelo Código?

BART, reaberto: seguir o código pode conflitar diretamente com a sobrevivência no emprego.

Dica

Isso não invalida os códigos — mostra que são ponto de partida, não substituto, do julgamento moral nem da regulação de fato.

Julgue V ou F: Autorregulação e Seus Limites

Dica

Julgue V ou F — a questão só conta se acertar os 4 itens:

□ Se o código da ACM fosse reescrito com sanções disciplinares explícitas, mas nenhum conselho existisse para aplicá-las, a crítica de autointeresse/window-dressing deixaria de se aplicar a ele.
□ O caso Tozer ilustra o mesmo tipo de risco que um profissional de Informática correria ao denunciar publicamente uma falha de segurança em vez de seguir só os canais internos.
□ Se uma empresa apoiasse publicamente uma lei de proteção de dados com multas pesadas e mantivesse um código de ética interno vago, isso eliminaria por completo a possibilidade de suas práticas reais serem piores do que o código sugere.
□ Como códigos às vezes servem para evitar regulação governamental, toda empresa que mantém um código de conduta está, necessariamente, tentando evitar ser regulada por lei.

Julgue V ou F: Autorregulação — Resposta

Dica

✗ Falso — a crítica depende de haver ou não fiscalização institucional independente, não do texto ter ou não sanções escritas no papel.
✔ Verdadeiro — em ambos, um código é usado para silenciar dissenso legítimo em nome da “lealdade”, em vez de proteger quem alerta sobre um risco real.
✗ Falso — apoiar uma lei externa não elimina a possibilidade de o código interno continuar sendo window-dressing: são mecanismos independentes.
✗ Falso — a própria fonte qualifica com “sometimes”; autointeresse é uma motivação possível entre várias, não universal.

Pergunta provocadora — se um código não pode ser “vivido” à risca, ele ainda vale alguma coisa?

A aula mostrou três limites diferentes de códigos de conduta — autointeresse/window-dressing, vagueza/contradição entre códigos, e a impossibilidade de proteger de fato quem os segue (BART). Será que esses três limites, somados, significam que um código de conduta é dispensável na prática?

Dica: pense na diferença entre “um código não resolve X por si só” e “um código não serve para nada”.

□ Como os três limites (autointeresse, vagueza, impossibilidade de proteção) mostram que nenhum código, isoladamente, garante um resultado ético, a conclusão lógica é que um profissional que ignora completamente os códigos de conduta está na mesma posição moral de um que os usa como ponto de partida para o julgamento.
□ No limite em que um código de conduta fosse escrito de forma perfeitamente precisa, sem nenhuma cláusula vaga e sem qualquer conflito entre suas próprias cláusulas, a crítica de autointeresse/window-dressing discutida no início do bloco deixaria de poder se aplicar a esse código.
□ A tensão entre “lealdade crítica” e “lealdade acrítica” discutida a partir do caso NSPE se aplicaria, em princípio, a uma cientista de dados que precisa decidir entre seguir uma diretriz da empresa que ela julga tecnicamente equivocada e alertar sua liderança sobre o problema, mesmo sem nenhuma cláusula de código escrita cobrindo essa situação específica.
□ Como a aula conclui que nenhum dos limites (autointeresse, vagueza, falta de proteção) é suficiente para declarar os códigos indesejáveis, isso significa que a crítica correta a fazer a um código de conduta real é sempre sobre defeitos de redação do próprio texto, nunca sobre a ausência de estrutura institucional (conselho, lei) por trás dele.

V/F — Vale Alguma Coisa um Código Que Não Pode Ser Vivido à Risca?: Resposta

Dica

✗ Falso — a própria conclusão da aula é o oposto: código como ponto de partida não é o mesmo que ignorá-lo por completo.
✗ Falso — precisão textual e autointeresse são dimensões independentes; um código muito preciso ainda pode ser usado retoricamente sem fiscalização real por trás.
✔ Verdadeiro — a distinção crítica/acrítica é uma ferramenta de raciocínio geral, aplicável mesmo sem cláusula escrita cobrindo o caso.
✗ Falso — o fio condutor dos Blocos 3–4 é justamente que a estrutura institucional por trás do código (conselho, lei) importa tanto quanto — ou mais que — a redação do texto.

Retomando: os limites não tornam os códigos dispensáveis — mostram que são ponto de partida, não substituto, do julgamento moral.

Fechamento: um Caso Para Aplicar, e Ponte

Pergunta provocadora — sem código específico, sem estrutura nenhuma?

Snowden não era necessariamente um “engenheiro” filiado a nenhum conselho ou associação profissional formal. Nenhum código profissional tradicional (nem ACM, nem IEEE-CS/ACM) foi escrito pensando especificamente em alguém na posição dele. Isso significa que o caso está fora do alcance de qualquer código de conduta? Ou o princípio ACM 1.1 — “contribute to society and to human well-being, acknowledging that all people are stakeholders in computing” — já basta para orientar uma resposta, mesmo sem um código específico para vigilância em massa?

Dica: pense se “não ter um código específico para o seu cargo” é o mesmo que “não ter nenhum princípio ético relevante disponível”.

□ O princípio ACM 1.1 (“contribute to society […] all people are stakeholders in computing”), originalmente pensado para decisões de produto de software, se estenderia, por analogia de escopo, ao caso de um prestador de serviços de infraestrutura de TI que decide expor um programa de vigilância em massa ao público.
□ No limite em que absolutamente nenhum princípio de nenhum código de conduta de computação mencionasse, ainda que indiretamente, valores como privacidade ou interesse público, o processo de deliberação de Landon & Landon (ou o Ciclo Ético) ainda teria uma forma de estruturar uma decisão sobre o caso Snowden.
□ Como nenhum código profissional tradicional foi escrito pensando especificamente na posição de Snowden, isso significa que a pergunta sobre se ele agiu eticamente não pode ser respondida com nenhum rigor, restando só opinião pessoal sem qualquer estrutura.
□ Se Snowden fosse formalmente filiado a um conselho profissional disciplinar (hipótese contrária ao caso real), isso teria, por si só, tornado a pergunta ética sobre sua ação irrelevante, substituída inteiramente por uma pergunta puramente disciplinar/legal.

V/F — Sem Código Específico, Sem Estrutura Nenhuma?: Resposta

Dica

✔ Verdadeiro — o critério do princípio é o grau de impacto social do sistema, não uma lista fechada de casos previstos no texto.
✔ Verdadeiro — os dois processos estruturam fatos, interessados, alternativas e consequências independentemente de existir um código específico.
✗ Falso — ausência de código específico não é ausência de estrutura de deliberação; é exatamente o que Landon & Landon/Ciclo Ético fornecem.
✗ Falso — um conselho disciplinar decide consequências institucionais e legais; não substitui a pergunta ética sobre se a ação foi correta.

Retomando: faltar um código específico não deixa o caso sem nenhuma estrutura — a deliberação (Ciclo Ético, Landon & Landon) continua disponível mesmo ali.

O Caso Snowden

“‘Ele é patriota ou traidor?’ e ‘o que é mais importante para a sociedade: segurança ou privacidade?’ […] Ou seja, uma questão ética!”

— Maciel & Viterbo (2020, p. 209)

Dica

Snowden não estava filiado a nenhum conselho ou associação profissional formal. O princípio ACM 1.1 (“all people are stakeholders in computing”) ainda se aplica aqui?

Dois Processos de Deliberação, Duas Tradições

Nota

Observação nossa, não dos autores — tradições independentes, não se citam. Diferença notável: falta uma Fase 5 (reflexão) equivalente em Landon & Landon.

O Que Fica Desta Aula

1. O que um código pode fazer? Expressar valores (aspiracional), orientar julgamento em situações concretas (consultivo, como ACM e IEEE-CS/ACM), ou disciplinar condutas (raro em códigos profissionais, mais comum em corporativos).

2. Quais estruturas dão força real a isso? Um conselho de profissão (registro + fiscalização + poder legal) torna um código disciplinar de fato — a Informática não tem um no Brasil. A LGPD faz algo análogo, mas regula o tratamento de dados, não quem pode exercer a profissão — regulação judicializada parcial, por um mecanismo, não pelo outro.

3. O que nenhuma dessas estruturas garante? Autointeresse disfarçado (window-dressing, e código como substituto de regulação real, casos Tozer e Google), vagueza e contradições entre códigos, e a impossibilidade de proteger de fato quem os segue (BART) — ponto de partida, não substituto, do julgamento moral.

Por isso a deliberação estruturada — Ciclo Ético ou o processo de Landon & Landon — continua indispensável, mesmo onde código, conselho e lei já existem.

Ponte para a Aula 4: engenharia de software como prática sociotécnica — papéis, comunicação (Lei de Conway), requisitos como processo social. Só depois, na Aula 5, a Parte 2 do curso, Computação e Seus Impactos, começando pelo custo material e ambiental da infraestrutura digital.