Capítulo 10 — Ética e prática autorizada
Mapa da aula
Aula 10 publicada. Mapa, exemplo, EX028.
flowchart TD
N0["10.1 Princípios"]
N1["10.2 Autorização"]
N2["10.3 Divulgação coordenada"]
N3["10.4 Equidade e safety"]
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 Princípios"]
N1["10.2 Autorização"]
N2["10.3 Divulgação coordenada"]
N3["10.4 Equidade e safety"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX028"]
[10.1 Princípios]
|
v
[10.2 Autorização]
|
v
[10.3 Divulgação coordenada]
|
v
[10.4 Equidade e safety]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX028]
Objetivos de aprendizagem
Você vai (1) aplicar princípios éticos ao trabalho de segurança de IA; (2) explicar por que a autorização é necessária antes de testar; (3) seguir a divulgação coordenada; e (4) reconhecer questões de equidade, privacidade e safety levantadas por sistemas de IA.
10.1 Princípios
Respeito às pessoas, evitar danos, honestidade, equidade e responsabilização orientam o trabalho de segurança. Em segurança de IA, os danos incluem violações de privacidade, resultados discriminatórios, conselhos inseguros e mau uso de capacidades. Esses princípios se convertem em escolhas concretas. Evitar danos significa testar com registros sintéticos, não com pacientes reais. Honestidade significa relatar resultados com seus limites. Equidade significa verificar se as previsões do NoShow tratam grupos de forma diferente. Responsabilização significa registrar quem autorizou cada teste e quem tomou cada decisão, para que a responsabilidade fique clara se algo der errado. As notas de laboratório de Rina registram cada uma dessas escolhas.
10.2 Autorização
Testar sistemas sem permissão pode ser ilegal e pode prejudicar usuários reais. Obtenha sempre uma autorização por escrito do dono do sistema que defina escopo, métodos, período e contatos. Serviços públicos de IA têm termos de uso; não os ataque fora de programas que o permitam explicitamente (como escopos publicados de bug bounty). A autorização de Rina para o trabalho na LCH nomeia os sistemas (cópias isoladas do Ask Lumen, do NoShow e do DocSort), os métodos permitidos, as datas e o contato a quem ligar se algo inesperado acontecer. Ela leva uma cópia em toda sessão de testes.
10.3 Divulgação coordenada
Se você encontrar uma vulnerabilidade, relate-a em privado ao dono, dê um prazo razoável para a correção e publique apenas detalhes que ajudem os defensores. Não acesse mais dados do que o necessário para demonstrar o problema. No caso de Rina, o problema do número de telefone foi demonstrado com um único exemplo sintético, e não verificando muitos números reais. O relatório dela descreveu o comportamento, as condições e uma correção sugerida, e ela o manteve confidencial até que a LCH confirmasse a correção, o que aconteceu antes do fim do semestre.
10.4 Equidade e safety
Sistemas de IA podem tratar grupos de forma diferente. O NoShow, por exemplo, poderia classificar alguns pacientes mais abaixo para lembretes por causa de atributos correlacionados com a renda. O NIST AI RMF lista justo, com vieses prejudiciais gerenciados entre as características de uma IA confiável, ao lado de seguro e resiliente e com privacidade reforçada. O AI Act da UE impõe obrigações a sistemas de alto risco, incluindo alguns usos ligados à saúde; a classificação jurídica exige orientação especializada. Uma verificação de equidade para o NoShow compararia as taxas de erro entre grupos, por exemplo se pacientes de alguns códigos postais são mais vezes previstos, erroneamente, como faltosos.
10.5 Exemplo resolvido (caso sintético da LCH)
Um colega propôs testar um chatbot comercial de saúde "para ver se ele vaza dados". Rina explicou que, sem autorização, isso seria antiético e possivelmente ilegal, e sugeriu construir, em vez disso, uma réplica sintética no laboratório do curso. Em outra ocasião, num teste autorizado da LCH, Rina descobriu que o Ask Lumen podia revelar se um número de telefone pertencia a um paciente cadastrado; ela o relatou pelo processo da LCH com evidência mínima, e o problema foi corrigido antes do fim do semestre. Evidência mínima significou um número de telefone sintético, e não uma lista de números reais.
10.6 Erros e limites
Três erros são comuns: "só dar uma olhada" em sistemas não autorizados; coletar mais dados pessoais do que o necessário para um relatório; e ignorar a equidade como "não sendo segurança". "Só dar uma olhada" num sistema não autorizado pode violar a lei e prejudicar usuários, qualquer que seja a intenção. Coletar mais dados pessoais do que o necessário transforma um relatório de segurança num risco de privacidade por si só. Ignorar a equidade deixa passar danos que afetam os pacientes tão diretamente quanto um vazamento de dados, como o NoShow dar a alguns grupos menos lembretes por causa de atributos correlacionados com a renda. A prática de Rina trata os três desde a concepção.
Exercícios
- EX028 — Autorização. Liste cinco elementos de uma autorização de testes. Rubrica: 3 = escopo, métodos, janela de tempo, tratamento de dados, contatos/condições de parada; 2 = quatro; 1 = dois; 0 = nenhum.
- EX029 — Divulgação. Descreva os passos de divulgação de Rina no problema do número de telefone. Rubrica: 3 = relato privado, evidência mínima, verificação da correção, nenhum dado público; 2 = parcial; 1 = vago; 0 = divulgação pública primeiro.
- EX030 — Equidade. Explique como o NoShow poderia gerar resultados injustos. Rubrica: 3 = proxies de características protegidas afetam lembretes/agendamento; 2 = parcial; 1 = vago; 0 = nenhum.
Síntese
A prática ética em segurança de IA significa testes autorizados, divulgação cuidadosa, dados mínimos e atenção à equidade e à safety, além dos ataques.
Continue estudando — capítulo 10 de 40
← Capítulo 09 (rascunho) · Índice de capítulos do curso · Capítulo 11 (rascunho) →