Capítulo 10 — Ética e segurança na engenharia
Mapa da aula
Aula 10 publicada. Mapa, exemplo, EX028.
flowchart TD
N0["10.1 Deveres profissionais"]
N1["10.2 Safety e security"]
N2["10.3 Testes autorizados e divulgação"]
N3["10.4 Lei e regulação"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX028"]
Desenho lógico
flowchart LR
N0["10.1 Deveres profissionais"]
N1["10.2 Safety e security"]
N2["10.3 Testes autorizados e divulgação"]
N3["10.4 Lei e regulação"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX028"]
[10.1 Deveres profissionais]
|
v
[10.2 Safety e security]
|
v
[10.3 Testes autorizados e divulgação]
|
v
[10.4 Lei e regulação]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX028]
Objetivos de aprendizagem
Você vai (1) aplicar a ética profissional da engenharia a sistemas de IA; (2) distinguir safety (dano acidental) de security (dano intencional) e mostrar como elas interagem; (3) aplicar regras para testes autorizados e divulgação responsável; e (4) reconhecer deveres legais, como os previstos no AI Act da UE para sistemas de alto risco.
10.1 Deveres profissionais
Os códigos de ética da engenharia colocam em primeiro lugar a segurança, a saúde e o bem-estar do público, exigem honestidade sobre capacidades e limites e exigem competência. Para a IA, isso significa não exagerar o que um modelo consegue fazer, documentar os modos de falha conhecidos e recusar a implantação quando o risco é inaceitável. Esses deveres valem nos momentos comuns, não só nos dramáticos: um slide que arredonda uma taxa de 9% de defeitos perdidos na madrugada para 'cerca de 2%', uma demonstração que esconde as condições em que o modelo falha, ou um prazo que tenta a equipe a pular a revisão de segurança. A competência inclui conhecer os limites da própria especialidade e pedir ajuda, por exemplo a um engenheiro de segurança ferroviária, quando uma decisão fica fora deles.
10.2 Safety e security
A engenharia de safety trata de falhas acidentais; a security trata de ataques deliberados. Na IA elas interagem: uma entrada adversarial pode causar uma falha de safety (um defeito no trilho que passa despercebido), e um mecanismo de safety (um recurso à inspeção manual) pode ser abusado para causar negação de serviço. O NIST AI RMF (AI 100-1) lista safe e secure and resilient entre as características de uma IA confiável e enfatiza geri-las em conjunto. Geri-las em conjunto significa uma única análise de perigos que pergunta tanto o que pode falhar quanto o que alguém pode fazer falhar. Recorrer à inspeção manual é seguro contra acidentes, mas um atacante que consiga acioná-lo repetidamente poderia esgotar os inspetores e atrasar o trabalho real.
10.3 Testes autorizados e divulgação
Teste apenas sistemas que sejam seus ou que você tenha permissão por escrito para testar, dentro de um escopo e de um prazo definidos. Nunca execute ataques contra serviços públicos de IA sem autorização; os termos de serviço frequentemente os proíbem. Quando encontrar uma vulnerabilidade no produto de outra pessoa, relate-a em particular ao fornecedor e combine um prazo antes de publicar (divulgação coordenada). Mantenha os dados de teste sintéticos ou devidamente governados; nunca extraia nem publique dados pessoais. A permissão por escrito nomeia quem pode testar, o quê, quando e por quais métodos.
10.4 Lei e regulação
O Regulamento (UE) 2024/1689 (o AI Act) classifica alguns sistemas de IA como de alto risco — inclusive componentes de segurança de infraestrutura crítica — e exige gestão de riscos, governança de dados, documentação técnica, registro em logs, supervisão humana e exatidão, robustez e cibersegurança (Artigo 15). As obrigações se aplicam em etapas de 2025 a 2027. Engenheiros devem saber se seu sistema pode cair numa categoria regulada e envolver especialistas jurídicos; este livro dá orientação, não aconselhamento jurídico. Mesmo antes do parecer jurídico, um engenheiro pode preparar a evidência de que um sistema regulado precisaria: um registro de riscos, a documentação dos conjuntos de dados, logs de decisões e registros de revisão humana. Esses registros são boa prática de qualquer forma, e reuni-los cedo evita reconstruir depois, sob prazo, a história de um sistema.
10.5 Exemplo resolvido (caso sintético da NRS)
Um gestor pediu a Sam que elevasse o limiar de alerta do TrackEye para reduzir alarmes falsos antes de uma demonstração. Sam calculou que os falsos negativos subiriam de 2% para 5% nos dados diurnos. Sam documentou o compromisso, recusou-se a mudar o limiar de produção sem uma revisão de safety e propôs uma configuração apenas para a demonstração, claramente identificada como tal. Sam também observou que o TrackEye, por ser um componente de segurança da infraestrutura ferroviária, pode ser de alto risco segundo o AI Act, e sinalizou isso para revisão jurídica. A configuração de demonstração atendeu ao objetivo do gestor sem tocar no sistema que inspeciona a via real.
10.6 Erros e limites
Três erros são comuns: tratar a ética como separada das decisões técnicas; testar serviços de IA de terceiros sem permissão; e esconder compromissos de safety em mudanças de configuração. Uma ética separada do trabalho técnico tende a aparecer só em documentos de política, enquanto as decisões reais são tomadas em limiares e planos de teste. Testar um serviço público de IA sem permissão pode violar a lei mesmo com boas intenções. Uma mudança de limiar que troca em silêncio defeitos não detectados por menos alarmes é uma decisão de safety tomada sem as pessoas responsáveis pela safety; a regra de Sam é que qualquer mudança que afete as taxas de defeitos perdidos passe por revisão, com seus números declarados.
Exercícios
- EX028 — Safety vs. security. Dê um exemplo em que um ataque de security causa uma falha de safety na NRS e um em que um mecanismo de safety é abusado. Rubrica: 3 = ambos plausíveis; 2 = um; 1 = confuso; 0 = nenhuma.
- EX029 — Divulgação. Você descobre que o modelo hospedado de um fornecedor vaza prompts de outros clientes. Liste os passos que você segue. Rubrica: 3 = parar, preservar evidência mínima, relato privado, prazo combinado, nenhuma publicação de dados; 2 = parcial; 1 = vago; 0 = publicar ou explorar.
- EX030 — AI Act. Cite quatro obrigações para sistemas de IA de alto risco. Rubrica: 3 = quatro entre gestão de riscos, governança de dados, documentação, registro em logs, transparência, supervisão humana, exatidão/robustez/cibersegurança; 2 = três; 1 = uma ou duas; 0 = nenhuma.
Síntese
A ética na engenharia de IA é concreta: limites honestos, safety e security geridas em conjunto, testes autorizados, divulgação coordenada e consciência dos deveres legais para sistemas de alto risco.
Continue estudando — capítulo 10 de 50
← Capítulo 09 (rascunho) · Índice de capítulos do curso · Capítulo 11 (rascunho) →