Os 39 controles do Anexo A da ISO 42001
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.2 — Políticas de uso responsável de IA
A.2.2
Política de uso responsável de IA
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.
Auditor pergunta: "Mostre-me a política. Ela menciona explicitamente os princípios de IA responsável adotados pela organização?"
A.2.3
Processo de revisão de impacto de IA
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.
Auditor pergunta: "Mostre a evidência de que a avaliação de impacto foi feita para o último sistema de IA implantado."
A.2.4
Documentação de uso de IA
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.
Auditor pergunta: "Onde está o inventário de sistemas de IA? Está atualizado com os sistemas em uso hoje?"
A.2.5
Gestão de riscos de IA
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.
Auditor pergunta: "O registro de riscos inclui riscos específicos de IA? Como o risco de drift do modelo X está classificado?"
A.3 — Controles internos de governança de IA
A.3.2
Papéis e responsabilidades internas para IA
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.
Auditor pergunta: "Se um modelo em produção começar a produzir resultados enviesados, quem é notificado? Quem tem autoridade para desligar o sistema?"
A.3.3
Gestão de recursos de IA
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.
Auditor pergunta: "Quem na organização tem competência para avaliar saídas anômalas do modelo de IA? Essa competência está documentada?"
A.3.4
Comunicação interna sobre IA
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.
Auditor pergunta: "Como as áreas de negócio são informadas quando um modelo de IA é atualizado ou quando um incidente ocorre?"
A.3.5
Gestão de incidentes de IA
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.
Auditor pergunta: "Mostre o registro de incidentes de IA dos últimos 12 meses. Como cada um foi analisado e tratado?"
A.3.6
Treinamento e conscientização em IA
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.
Auditor pergunta: "O gerente que usa o sistema de IA de crédito passou por treinamento sobre as limitações do modelo? Há registro?"
A.4 — Ciclo de vida de dados para IA
A.4.2
Aquisição de dados para IA
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.
Auditor pergunta: "De onde vieram os dados de treino do modelo X? Existe contrato ou licença que autoriza o uso para treino de IA?"
A.4.3
Qualidade de dados para IA
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.
Auditor pergunta: "Quais verificações de qualidade foram feitas no dataset de treino? Houve análise de distribuição para identificar sub-representação?"
A.4.4
Proveniência e rastreabilidade de dados
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.
Auditor pergunta: "Se um cliente questionar a decisão automatizada que o afetou, conseguimos identificar quais dados de treino influenciaram aquele modelo?"
A.4.5
Retenção e descarte de dados de IA
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.
Auditor pergunta: "Qual é o prazo de retenção do dataset de treino do modelo X? Quando expira, como é descartado?"
A.4.6
Proteção de dados de IA
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.
Auditor pergunta: "Quem tem acesso ao dataset de treino? Os pesos do modelo estão protegidos contra extração não autorizada?"
A.5 — Desenvolvimento de sistemas de IA
A.5.2
Especificação do sistema de IA
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.
Auditor pergunta: "Qual era a acurácia mínima aceitável definida antes do treino? O modelo atingiu essa meta antes de ir para produção?"
A.5.3
Verificação e validação de IA
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.
Auditor pergunta: "O conjunto de teste foi completamente separado antes do treino? O desempenho por subgrupo (raça, gênero, região) foi avaliado?"
A.5.4
Documentação técnica do sistema
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.
Auditor pergunta: "Mostre a documentação técnica do modelo em produção. As limitações conhecidas estão listadas?"
A.5.5
Gestão de versões de modelos
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.
Auditor pergunta: "Se o modelo atual tiver problema grave, quanto tempo leva para reverter para a versão anterior? O processo está documentado?"
A.5.6
Gestão de ferramentas e infraestrutura de IA
Controle sobre as ferramentas usadas no desenvolvimento de IA (frameworks, bibliotecas, plataformas de MLOps) — incluindo licenciamento, atualizações de segurança e dependências.
Auditor pergunta: "As bibliotecas de ML usadas têm controle de versão? Há processo para aplicar patches de segurança em dependências de IA?"
A.6 — Operação de sistemas de IA
A.6.2
Operação responsável de IA
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.
Auditor pergunta: "Existe supervisão humana definida para as decisões do modelo? Quem monitora se o sistema está sendo usado fora do escopo aprovado?"
A.6.3
Monitoramento de desempenho de IA
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.
Auditor pergunta: "Mostre o dashboard de monitoramento do modelo. Qual foi o último alerta de drift gerado? Como foi tratado?"
A.6.4
Log e rastreabilidade de IA
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.
Auditor pergunta: "Se um cliente questionar a decisão de crédito de 6 meses atrás, conseguimos reconstruir quais dados de entrada geraram aquela saída?"
A.6.5
Retreinamento e atualização de modelos
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.
Auditor pergunta: "Quais são os critérios para decidir que um modelo precisa ser retreinado? Quem aprova um novo modelo antes de ir para produção?"
A.6.6
Descomissionamento de sistemas de IA
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.
Auditor pergunta: "O modelo legado que foi substituído no ano passado — o que aconteceu com os pesos, os dados de treino e os logs?"
A.7 — Uso de IA por terceiros e em cadeias de suprimentos
A.7.2
Seleção e avaliação de fornecedores de IA
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.
Auditor pergunta: "A API de IA externa usada no processo de crédito — quem são os fornecedores de dados de treino deles? Essa informação foi solicitada?"
A.7.3
Contratos com fornecedores de IA
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.
Auditor pergunta: "O contrato com o fornecedor da API de IA define quem é responsável se o modelo tomar uma decisão discriminatória?"
A.7.4
Monitoramento de fornecedores de IA
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.
Auditor pergunta: "O fornecedor de IA atualizou o modelo nos últimos 6 meses? A organização foi notificada? O impacto foi avaliado?"
A.7.5
Uso de IA open source
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.
Auditor pergunta: "O modelo open source usado — sua licença permite uso comercial? Quem é responsável pelo fine-tuning feito internamente?"
A.8 — Uso responsável de IA pelos clientes
A.8.2
Divulgação do uso de IA
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.
Auditor pergunta: "O cliente sabe que a decisão de crédito que recebeu foi tomada por um sistema de IA? Onde essa informação está disponível?"
A.8.3
Instruções para uso responsável por clientes
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.
Auditor pergunta: "A documentação entregue ao cliente lista as limitações conhecidas e os casos de uso não recomendados do sistema?"
A.8.4
Canal de reclamação e feedback de IA
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.
Auditor pergunta: "Se um cliente receber uma decisão de IA que considera injusta, por onde ele aciona a revisão? O processo está documentado e funcional?"
A.9 — Propósito, adequação e confiabilidade
A.9.2
Verificação de adequação ao propósito
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.
Auditor pergunta: "O modelo foi testado com dados do ambiente de produção antes do go-live? Houve diferença de desempenho?"
A.9.3
Interpretabilidade e explicabilidade
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). Critícal para LGPD Art. 20 e para alto risco EU AI Act.
Auditor pergunta: "Consegue explicar para mim por que o modelo negou o crédito a esse cliente específico? Com quais variáveis contribuíram mais?"
A.9.4
Confiabilidade e resiliência
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.
Auditor pergunta: "O que acontece quando o modelo tem baixa confiança na predição? Ele escala para revisão humana ou aplica a decisão da mesma forma?"
A.9.5
Segurança (safety) de sistemas de IA
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.
Auditor pergunta: "Qual é o pior cenário de falha deste sistema de IA? Há controle que impede que esse cenário se concretize?"
A.10 — Segurança de sistemas de IA
A.10.2
Avaliação de ameaças a sistemas de IA
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.
Auditor pergunta: "Foi feita análise de ameaças adversariais para o modelo? Alguém tentou manipular ativamente as entradas para enganar o sistema?"
A.10.3
Proteção contra ataques adversariais
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.
Auditor pergunta: "Se alguém fizer 10.000 consultas ao modelo para reconstruir seus pesos (model extraction), há controle que detecta e bloqueia?"
A.10.4
Testes de robustez
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.
Auditor pergunta: "O modelo foi testado com dados corrompidos ou de baixa qualidade? Como ele se comporta quando recebe um input totalmente fora do esperado?"
A.10.5
Gestão de vulnerabilidades em IA
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.
Auditor pergunta: "A biblioteca TensorFlow usada no modelo tem CVEs conhecidos? Há processo para aplicar atualizações de segurança em dependências de ML?"
A.11 — Não discriminação e imparcialidade (Fairness)
A.11.2
Avaliação de viés
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.
Auditor pergunta: "A taxa de aprovação de crédito do modelo é similar entre diferentes grupos étnicos? O desempenho por subgrupo foi medido e documentado?"
A.11.3
Mitigação de viés
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.
Auditor pergunta: "Quando foi identificado viés no modelo X, quais técnicas foram aplicadas? O viés foi reduzido após a mitigação? Há evidência?"
A.11.4
Monitoramento de fairness em produçã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).
Auditor pergunta: "A taxa de falso negativo entre homens e mulheres está sendo monitorada em produção? Quando foi a última vez que esse número foi verificado?"
A.12 — Impacto ambiental de sistemas de IA
A.12.2
Avaliação de impacto ambiental
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.
Auditor pergunta: "Qual é a pegada de carbono estimada do treino do último modelo de grande porte? Isso foi avaliado antes da decisão de treinar?"
A.12.3
Eficiência energética 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.
Auditor pergunta: "A eficiência energética foi um critério na escolha entre o modelo grande e o compacto? Há monitoramento do consumo de GPU/CPU em inferência?"
Declaração de Aplicabilidade (SoA)
Nem todos os 39 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.