Gap Analysis gratuito
O Anexo A da ISO 42001 contém os controles selecionáveis para o Sistema de Gestão de IA. Diferente das Cláusulas 4–10 (que são todas obrigatórias), os controles do Anexo A são aplicáveis conforme o contexto da organização e os riscos identificados na Cláusula 6. A organização deve justificar na Declaração de Aplicabilidade (SoA) quais controles aplica e quais exclui — e por quê.
Como usar esta página: clique em cada categoria para expandir os controles. Para cada controle, veja o que ele exige, como implementar e o que o auditor vai perguntar.
A organização deve estabelecer, documentar e comunicar uma política que defina como a IA será usada de forma responsável — incluindo valores, princípios e restrições. A política deve ser específica para IA, não apenas uma extensão da política de TI geral.
Deve haver um processo formal para avaliar o impacto de sistemas de IA antes da implantação — incluindo impacto em pessoas, sociedade e meio ambiente. Esse processo se conecta diretamente à Avaliação de Impacto de IA da Cláusula 6.1.2.
A organização deve manter registro documentado de quais sistemas de IA são usados, para qual finalidade, e quem é responsável. Este é o inventário de IA — pré-requisito para quase todos os outros controles.
Processo de identificação, avaliação e tratamento de riscos específicos de IA — incluindo riscos de viés, drift, falha de modelo, uso indevido e dependência de fornecedor. Complementa o processo geral de riscos da Cláusula 6.1.1.
Define quem é responsável por quê no ciclo de vida da IA — desde a concepção até o descomissionamento. Inclui quem pode autorizar novos sistemas de IA, quem monitora e quem responde por incidentes.
Garante que a organização tenha os recursos necessários para operar sistemas de IA com responsabilidade — incluindo competência técnica, infraestrutura e ferramentas de monitoramento.
Define como a organização comunica internamente sobre sistemas de IA, riscos identificados e incidentes. Garante que as áreas afetadas por decisões de IA sejam informadas de forma adequada.
Processo específico para identificar, registrar, analisar e responder a incidentes relacionados a sistemas de IA — incluindo saídas prejudiciais, falhas de modelo, viés detectado e uso indevido.
Garante que funcionários que usam, operam ou tomam decisões baseadas em sistemas de IA tenham treinamento adequado — incluindo limitações dos modelos, riscos de IA e responsabilidades individuais.
Define como dados para treino, validação e teste são adquiridos — incluindo verificação de origem, licenciamento, consentimento e representatividade. Dados adquiridos sem verificação de fonte são risco direto de viés e LGPD.
Processo para garantir que os dados usados em IA tenham qualidade suficiente — completude, precisão, consistência, representatividade e ausência de viés sistemático antes do treino.
A organização deve ser capaz de rastrear a origem de cada dado usado em sistemas de IA — "linhagem de dados". Essencial para responder a direitos LGPD (acesso, eliminação) e para reproduzir resultados em caso de contestação.
Define por quanto tempo dados de treino, modelos treinados e logs de inferência são mantidos — e como são descartados de forma segura ao final do período. Alinha com requisitos LGPD de minimização e prazo de retenção.
Controles de segurança específicos para datasets, modelos treinados e logs de inferência — incluindo controle de acesso, criptografia, versionamento e prevenção de vazamento de dados memorizados pelo modelo.
Documentação formal dos objetivos, casos de uso previstos, casos de uso proibidos, métricas de desempenho alvo e critérios de aceitação — antes de começar o desenvolvimento. O equivalente ao "model card" da documentação técnica.
O sistema de IA deve ser verificado (constrói certo?) e validado (constrói a coisa certa?) antes da implantação. Inclui testes em dados não vistos, testes de robustez adversarial e validação de fairness por subgrupos.
O model card: arquitetura, dados de treino, métricas de desempenho, limitações conhecidas, casos de uso recomendados e não recomendados. Deve ser mantido atualizado a cada versão do modelo.
Controle de versão de modelos de IA — incluindo rastreabilidade entre versão do modelo, dataset de treino, código e hiperparâmetros. Capacidade de reverter para versão anterior em caso de problema.
Controle sobre as ferramentas usadas no desenvolvimento de IA (frameworks, bibliotecas, plataformas de MLOps) — incluindo licenciamento, atualizações de segurança e dependências.
Garante que sistemas de IA em produção operem dentro dos parâmetros definidos durante o desenvolvimento — incluindo limites de uso, monitoramento de conformidade com casos de uso aprovados e supervisão humana.
Métricas de desempenho do modelo monitoradas continuamente em produção — incluindo acurácia, drift de dados (mudança na distribuição de entrada) e drift de conceito (mudança na relação entre entrada e saída). Com alertas configurados.
Registro das inferências realizadas — especialmente para decisões de alto impacto. Os logs devem ser suficientes para auditar uma decisão específica retrospectivamente e para análise de causa raiz em incidentes.
Processo para retreinar ou atualizar modelos quando o desempenho deteriora ou quando os dados mudam. Inclui critérios de gatilho para retreinamento, validação antes de reimplantar e aprovação formal.
Processo para retirar sistemas de IA de forma controlada — incluindo o que acontece com o modelo treinado, os dados de treino, os logs de inferência e as integrações com outros sistemas.
Processo de due diligence para fornecedores de sistemas de IA ou APIs — avaliando práticas de governança, transparência sobre os dados de treino, conformidade regulatória e responsabilidade por incidentes.
Cláusulas contratuais específicas para fornecedores de IA — incluindo responsabilidade por saídas prejudiciais, obrigação de notificação em incidentes, direito de auditoria e continuidade do serviço.
Monitoramento contínuo dos fornecedores de IA — verificando se atualizações dos modelos de terceiros afetam o desempenho ou comportamento esperado, e se a conformidade contratual é mantida.
Controle específico para uso de modelos de IA de código aberto — avaliando licenciamento, proveniência dos dados de treino do modelo base, atualizações de segurança e responsabilidade pelo fine-tuning.
Os usuários ou clientes afetados por sistemas de IA devem ser informados de que IA está sendo usada — especialmente quando há decisões automatizadas de alto impacto. A transparência é um princípio central da norma.
Quando a organização fornece sistemas de IA para que clientes ou usuários operem, deve prover documentação clara sobre uso correto, limitações e riscos — para que não seja usada fora do escopo previsto.
Mecanismo para que usuários reportem problemas com sistemas de IA — saídas incorretas, comportamento inesperado, resultados percebidos como injustos. Essencial para o ciclo de melhoria contínua e para o processo de revisão da LGPD Art. 20.
Antes de implantar um sistema de IA, verificar se ele é adequado para o propósito pretendido — incluindo testes em contexto real e validação de que o desempenho no ambiente de produção corresponde ao do ambiente de teste.
A organização deve ser capaz de explicar como um sistema de IA chegou a uma decisão — em nível adequado ao contexto (técnico para auditores, acessível para usuários afetados). Crítico para LGPD Art. 20 e para alto risco EU AI Act.
O sistema de IA deve operar de forma confiável — com degradação graciosa em falhas, comportamento previsível em entradas anômalas e mecanismos de fallback quando o modelo não consegue produzir resultado com confiança suficiente.
Para sistemas de IA cujas falhas podem causar dano físico, financeiro ou social significativo: análise de falhas (FMEA), testes de cenário adverso e limites operacionais com supervisão humana obrigatória.
Identificação de ameaças específicas de IA além das ameaças tradicionais de segurança — incluindo ataques adversariais (inputs manipulados para enganar o modelo), data poisoning (envenenamento do dataset de treino), model inversion e extração de modelo.
Controles técnicos para detectar e mitigar ataques adversariais — incluindo validação de inputs, detecção de anomalias nas entradas, limites de taxa e monitoramento de padrões suspeitos de consulta.
O modelo deve ser testado com entradas fora da distribuição normal — inputs ruidosos, dados corrompidos, valores extremos — para verificar se o comportamento permanece aceitável. Modelos frágeis a entradas anômalas são riscos operacionais.
Processo para identificar e tratar vulnerabilidades em sistemas de IA — incluindo acompanhamento de vulnerabilidades conhecidas em frameworks de ML (CVEs específicos de bibliotecas de IA) e patches de segurança.
Avaliação sistemática do sistema de IA para identificar viés em diferentes subgrupos — por gênero, raça, etnia, idade, localização geográfica e outras características protegidas. Inclui viés nos dados de treino e viés nos resultados do modelo.
Quando viés significativo é identificado, devem ser aplicadas técnicas de mitigação — re-amostragem do dataset, pesos de classe, restrições de fairness durante o treino ou pós-processamento dos outputs. Com validação após a mitigação.
O monitoramento de fairness não termina na validação — deve continuar em produção. Métricas de equidade monitoradas continuamente para detectar drift de fairness (o viés pode aparecer ou piorar com o tempo à medida que os dados mudam).
Avaliação do consumo de energia e emissão de carbono associados ao treino e à operação de sistemas de IA — especialmente modelos grandes. A ISO 42001 é uma das primeiras normas de gestão a incluir impacto ambiental como controle obrigatório de IA.
A organização deve considerar a eficiência energética como critério na seleção de modelos e infraestrutura — preferindo arquiteturas mais eficientes quando o desempenho é equivalente, e monitorando o consumo em produção.
Nem todos os 38 controles precisam ser implementados por todas as organizações. A organização deve criar uma Declaração de Aplicabilidade listando cada controle, se é aplicável ou não, a justificativa para exclusões, e o status de implementação. Uma exclusão bem justificada é tão válida quanto uma implementação — o auditor avalia a coerência do raciocínio, não apenas o número de controles implementados.
A SoA do kit traz os 38 controles com aplicabilidade, justificativa obrigatória, status, evidência e vínculo com os riscos tratados. No Kit Completo, o checklist de auditoria interna usa os mesmos controles, com pergunta de auditor e evidências a amostrar.