Governando a decisão, não o código

Prévia grátis 7 min de leitura

Um auditor faz uma pergunta simples: "Me mostre quem aprovou colocar este modelo em produção, e o que essa pessoa olhou antes de dizer sim". O time tem o modelo. Tem o código. Tem uma thread no Slack em que alguém escreveu "parece bom, pode subir". O que ele não tem é nada que sobreviva à saída da empresa de quem escreveu essa mensagem. A aprovação existiu uma vez, como um fato sobre um momento. Agora ela existe só como uma lembrança que ninguém consegue apresentar quando pedem.

O curso anterior, o curso de nível Sênior "Aposentando sistemas legados", passou sete lições numa versão deste problema apontada para o código. Ele trocou memória por instrumentação, uma thread perdida no Slack por um registro de decisões e "alguém vai lembrar dos passos" por um runbook. Esse curso e os dois anteriores, "Upgrades Rails sem downtime" e "Migrations de larga escala: gh-ost", ensinaram a mudar um sistema de produção com segurança.

Nenhum dos três ensinou quem pode decidir que um sistema está seguro para mudar. Eles não trataram do que precisa estar escrito antes que essa decisão conte como tomada. Também não trataram de como uma organização prova o seu processo a alguém de fora do time que o construiu. Essa é outra disciplina: governança. Este curso dá um nome a ela.

O que é um sistema de gestão

"Sistema de gestão" soa como software, e não é. É um conjunto de políticas, papéis e processos repetíveis que uma organização mantém, no papel e na prática. O objetivo é continuar tomando certo tipo de decisão corretamente enquanto as pessoas entram e saem do time. A ISO 9001 é um sistema de gestão para qualidade. A ISO 27001 é um para segurança da informação. A ISO/IEC 42001, publicada em dezembro de 2023, é um sistema de gestão para IA, e a primeira norma internacional do tipo.

A distinção que importa: uma norma de sistema de gestão certifica um processo, e nunca um produto. A certificação ISO 42001 nunca diz "este modelo é seguro". Um modelo pode ser retreinado amanhã, e a certificação não diz nada de novo sobre ele. O que ela diz é "esta organização tem um processo repetível, documentado e auditado para decidir o que conta como seguro, para este modelo e para todos os que vierem depois". É uma afirmação mais estreita do que parece, e mais duradoura. O modelo muda o tempo todo; o que é auditado é o processo que a organização usa para governá-lo.

Dimensão Certificação de produto Certificação de sistema de gestão
O que afirma "Este modelo específico passou." "O processo de decisão da organização é documentado e seguido."
Durabilidade Deixa de valer quando o modelo é retreinado. Continua valendo enquanto os modelos mudam, desde que o processo rode.
Unidade verificada Um artefato, um momento. Um processo, verificado repetidamente.

Por que certificar um processo em vez de um modelo

O comportamento de um modelo é um alvo móvel. Pense em novos dados de treino, um ajuste fino, uma mudança de prompt, uma atualização silenciosa de um fornecedor numa API hospedada que você chama. Qualquer afirmação pontual sobre um modelo específico fica velha em um ciclo de release.

O que uma organização consegue manter constante é como ela decide. Quem precisa aprovar antes que um modelo chegue à produção? Que evidência essa aprovação exige? Como os problemas são investigados e corrigidos, e como o conjunto é verificado e melhorado com regularidade? A ISO 42001 audita essa engrenagem, e nenhum modelo específico que roda dentro dela. É a mesma lógica de auditar o processo de aprovação de despesas de uma empresa em vez de reaprovar cada relatório de despesa à mão.

O formato: Plan-Do-Check-Act, cláusulas 4 a 10

A ISO 42001 segue o mesmo esqueleto de outras normas ISO modernas de sistema de gestão, entre elas a ISO 27001. Ela é construída em torno de um ciclo Plan-Do-Check-Act: planejar o que fazer e por quê, fazer, verificar se funcionou e agir sobre o que encontrar. Esse ciclo se distribui em sete cláusulas numeradas:

  • Cláusula 4, contexto da organização: o que a organização faz com IA, quem é afetado, o que está no escopo.
  • Cláusula 5, liderança: a alta direção se compromete, os papéis são atribuídos, uma política de IA é escrita.
  • Cláusula 6, planejamento: avaliação de riscos e oportunidades, e objetivos.
  • Cláusula 7, apoio: recursos, competência, conscientização, informação documentada.
  • Cláusula 8, operação: rodar o ciclo de vida do sistema de IA no dia a dia. A maior parte do trabalho concreto de engenharia deste curso está aqui.
  • Cláusula 9, avaliação de desempenho: auditoria interna e análise crítica pela direção.
  • Cláusula 10, melhoria: não conformidade, ação corretiva, melhoria contínua.

Ao lado das cláusulas fica o Anexo A: uma lista de referência de controles agrupados em áreas nomeadas. Ele cobre coisas como a política de IA, papéis, recursos e avaliação de impacto de sistemas de IA. Também cobre práticas de ciclo de vida, como governança de dados e contratação de terceiros. O Anexo B traz orientação de implementação para os mesmos controles.

Uma organização não precisa adotar todos os controles do Anexo A. Ela documenta quais se aplicam, e por quê, numa Declaração de Aplicabilidade, o mesmo padrão que a ISO 27001 usa para o próprio Anexo A. Este curso trata a ISO 27001 como a norma irmã cujo formato de Anexo A a ISO 42001 empresta. O curso de nível Sênior "Conformidade: ISO 27001" cobre os controles dela em profundidade.

Duas normas companheiras, citadas uma vez e deixadas de lado

Outros dois documentos ISO aparecem o tempo todo no material sobre a ISO 42001. Este curso os nomeia uma vez para que você os reconheça, sem ensinar o conteúdo deles.

A ISO/IEC 23894 é orientação sobre gestão de riscos de IA: como pensar o risco que um sistema de IA traz para a organização. A ISO/IEC 42005 é orientação sobre avaliação de impacto de sistemas de IA. É uma pergunta relacionada, mas diferente, sobre efeitos nas pessoas em vez de efeitos no negócio, e a próxima lição traça uma linha firme em volta dela. Nenhuma das duas é uma norma certificável de sistema de gestão; as duas alimentam o jeito como uma organização cumpre os requisitos da ISO 42001.

GDPR, LGPD e o AI Act europeu aparecem neste curso só de passagem. Os cursos de nível Sênior "Conformidade: GDPR a fundo", "Conformidade: LGPD a fundo" e "Conformidade: o AI Act europeu" os ensinam direito.

O que você vai estudar

  • Lição 2: liderança, a política de IA e o inventário de sistemas de IA, o artefato do qual todo o resto deste curso depende.
  • Lição 3: avaliação de risco contra avaliação de impacto de IA, e por que confundir as duas é o erro mais comum de quem adota esta norma.
  • Lição 4: controles de ciclo de vida: governança de dados, decisões de design documentadas, testes antes do release, supervisão humana.
  • Lição 5: registros operacionais, a trilha de evidências que transforma uma afirmação num fato auditável, e a verificação no portão de release que os lê.
  • Lição 6: auditoria interna, análise crítica pela direção, não conformidade, ação corretiva e melhoria contínua, a metade Check e Act do ciclo.
  • Lição 7: montar um pequeno sistema de gestão de IA num código Rails, e onde o próximo curso continua.

Uma coisa para levar para a lição 2

A thread do Slack que abriu esta lição tinha uma decisão enterrada nela. Ela só não estava registrada em nenhum lugar que um sistema de gestão reconheça como evidência. A lição 2 começa pelo artefato que fecha essa lacuna para a pergunta mais básica de todas. A pergunta não é se a decisão foi boa. É se alguém sabe que este sistema de IA existe.

Aula 1 de 7 · grátis

Continue com a aula 2

A política de IA e o inventário de sistemas

Trata das obrigações da liderança na cláusula 5, da política de IA e do inventário de sistemas de IA.

Com uma conta grátis você também tem os quizzes, seu progresso e suas anotações, e a discussão.

Digite para buscar...