◇ OpenCyber Academy
Profissionalizante · Capítulo 9 · Português

Capítulo 9 — Comunicação, ética e relatos

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 9 — Comunicação, ética e relatos

Mapa da aula

Aula 09 publicada. Mapa, exemplo, EX041.

flowchart TD
  N0["9.1 Públicos"]
  N1["9.2 Incerteza honesta"]
  N2["9.3 Pressão ética"]
  N3["9.4 Proteger as pessoas afetadas"]
  N4["9.5 Comunicação de incidentes"]
  N5["9.7b Conferir a mensagem antes do envio"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX041"]

Desenho lógico

flowchart LR
  N0["9.1 Públicos"]
  N1["9.2 Incerteza honesta"]
  N2["9.3 Pressão ética"]
  N3["9.4 Proteger as pessoas afetadas"]
  N4["9.5 Comunicação de incidentes"]
  N5["9.7b Conferir a mensagem antes do envio"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX041"]

[9.1 Públicos]
    |
    v
[9.2 Incerteza honesta]
    |
    v
[9.3 Pressão ética]
    |
    v
[9.4 Proteger as pessoas afetadas]
    |
    v
[9.5 Comunicação de incidentes]
    |
    v
[9.7b Conferir a mensagem antes do envio]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX041]

Objetivos de aprendizagem

Você vai (1) escrever constatações e relatórios para públicos diferentes; (2) declarar a incerteza com honestidade; (3) lidar com pressões éticas; (4) proteger as pessoas afetadas por falhas de IA; e (5) comunicar durante incidentes.

9.1 Públicos

Os engenheiros precisam dos passos de reprodução e das correções. Os gestores precisam do impacto, da prioridade e das decisões. Os clientes e o público precisam de informações claras, precisas e oportunas. Escreva separadamente para cada um, a partir dos mesmos fatos. Para a constatação dos retornos, os engenheiros receberam os identificadores dos testes e a configuração da ferramenta, os gestores o impacto e a decisão necessária, e os analistas de sinistros uma nota curta sobre o que tinha mudado para eles. Verifique se todas as versões concordam quanto aos fatos. Os engenheiros precisam dos identificadores dos testes e dos passos de reprodução, os gestores do risco e da decisão, e a equipe da linha de frente do que muda no seu trabalho. Escreva cada versão a partir das mesmas evidências.

9.2 Incerteza honesta

Diga o que testou, quantas vezes, o que encontrou e o que não testou. "0 de 90 tentativas tiveram sucesso (limite superior de 95% em torno de 3%) na homologação; envios em outros idiomas que não o inglês não foram testados" é honesto. "O ClaimChat é seguro" não é. A declaração de Sofia sobre o ClaimChat seguiu essa forma, nomeando os envios em outros idiomas não testados. Torne visíveis as partes não testadas, para que os leitores decidam se elas importam. Os leitores conseguem agir a partir de números e limites, mas não a partir de garantias tranquilizadoras. Quando pedirem uma resposta simples, dê os números e o que eles significam para a decisão e diga que testes adicionais reduziriam a incerteza, e a que custo.

9.3 Pressão ética

Pode ser que lhe peçam para suavizar as constatações antes de um lançamento. Mantenha os fatos inalterados; você pode acrescentar contexto e respostas da gestão. Se a pressão continuar, escale e registre. Seu dever inclui as pessoas de fora da organização que poderiam ser prejudicadas. A resposta de Sofia no exemplo resolvido abaixo é um exemplo: ela manteve a classificação, acrescentou a situação da correção e se ofereceu para atualizar depois da verificação. Registre o pedido e a sua resposta, com datas, para o caso de surgirem perguntas mais tarde. Contexto, como uma resposta da gestão, é bem-vindo; fatos alterados, não.

9.4 Proteger as pessoas afetadas

Considere quem arca com o dano: segurados honestos sinalizados por engano, clientes cujos dados vazam. Recomende formas de recurso: explicações, contestações, revisão humana rápida. O artigo 14 do Regulamento de IA da UE enfatiza uma supervisão humana capaz de compreender, interpretar e anular as saídas da IA em sistemas de alto risco. No FraudFlag, a recomendação de Sofia de revisão em até 48 horas e de uma mensagem neutra "em análise padrão" protege os segurados honestos. Pergunte que recurso a pessoa afetada tem sempre que uma constatação for relatada. Entre as pessoas afetadas estão segurados que nunca usam o ClaimChat. Considere o dano e o recurso delas antes de recomendar controles e diga o que lhes será informado.

9.5 Comunicação de incidentes

Informe rapidamente as pessoas certas, com o que se sabe, o que não se sabe e o horário da próxima atualização. Evite especulações. Coordene as mensagens externas por meio do responsável designado. Durante a tempestade do FraudFlag, as atualizações foram para os gestores de sinistros com o que se sabia, o que não se sabia e quando viria a próxima atualização. Mantenha um registro das mensagens enviadas e corrija na atualização seguinte qualquer mensagem que se revele errada. As atualizações devem ser regulares mesmo quando não há nada de novo, já que o silêncio preocupa mais as pessoas do que um progresso lento.

9.6 Exemplo resolvido (caso sintético da Meridian)

Antes do lançamento mais amplo do ClaimChat, um gestor pede a Sofia que classifique a constatação de divulgação como "baixa" porque ela "já foi corrigida". A correção foi implantada, mas ainda não verificada na bateria reservada. Sofia mantém a classificação, acrescenta "correção implantada; verificação prevista para sexta-feira" e se oferece para atualizar o relatório depois da verificação. Na sexta-feira, 0 de 20 testes de divulgação têm sucesso; ela altera a situação para "encerrada — verificada", com evidências. A classificação só mudou quando as evidências mudaram, e o relatório mostrou os dois estados. O pedido do gestor veio antes do lançamento mais amplo, quando a pressão era maior.

9.7 Erros e limites

Três erros são comuns: um único relatório para todos os públicos; certeza exagerada; e mudar os fatos sob pressão. Cada erro abala a confiança. Um único relatório para todos os públicos dá aos engenheiros detalhes de menos e aos gestores detalhes demais. Uma certeza exagerada, como chamar o ClaimChat de seguro, desmorona na primeira falha. Mudar os fatos sob pressão, o que Sofia se recusou a fazer, mina todos os relatórios seguintes. Verifique os três em cada relatório antes de enviá-lo. Corrija o que encontrar antes que o relatório saia da equipe. Um revisor que não esteve envolvido os percebe com mais facilidade do que o autor.

9.7b Conferir a mensagem antes do envio

Antes que um relatório sobre erros do FraudFlag saia da equipe, um colega que não esteve envolvido o lê procurando três coisas: se algum cliente poderia ser identificado, se a incerteza está declarada com honestidade e se a ação recomendada está clara. As alterações são feitas antes do envio. Registre quem revisou. Os comentários do revisor são registrados com o relatório, e qualquer divergência vai para a supervisora de Sofia antes do envio. Preste atenção especialmente a combinações como CEP e datas de sinistro, que juntas poderiam apontar para um único cliente mesmo quando nenhum nome aparece.

Exercícios

Síntese

Uma boa comunicação ajusta os fatos aos públicos, declara a incerteza com clareza, mantém-se firme sob pressão e não perde de vista as pessoas afetadas.

Continue estudando — capítulo 09 de 12

← Capítulo 08 (rascunho) · Índice de capítulos do curso · Capítulo 10 (rascunho) →