Anexo A da ISO 42001: os 38 controles e a declaração de aplicabilidade

O Anexo A da ISO/IEC 42001 é a lista de referência de controles para sistemas de inteligência artificial: são 38 controles distribuídos em 9 grupos (A.2 a A.10), que vão de política de IA a relacionamento com fornecedores e clientes. Ele é normativo — a organização precisa comparar o seu tratamento de risco com essa lista, decidir o que se aplica ao seu escopo e registrar a decisão numa declaração de aplicabilidade. Não é um checklist para marcar tudo, e sim o inventário mínimo do que precisa ser considerado.

Este artigo percorre os 9 grupos, um a um, com o que cada um pede e a evidência que costuma aparecer na auditoria. Para o quadro geral da norma, veja o guia ISO 42001: o que é e para quem serve; para as cláusulas 4 a 10, o artigo de requisitos da ISO 42001.

O que é o Anexo A e como ele se encaixa na norma

A ISO 42001 tem duas camadas. As cláusulas 4 a 10 definem o sistema de gestão: contexto, liderança, planejamento, apoio, operação, avaliação e melhoria. O Anexo A define controles — as medidas concretas que reduzem risco e impacto dos sistemas de IA.

A ligação entre as duas camadas está na cláusula 6.1.3, de tratamento de risco de IA. Depois de avaliar os riscos (6.1.2) e o impacto dos sistemas (6.1.4), a organização escolhe controles para tratá-los e compara essa escolha com o Anexo A, para não deixar passar nenhum controle necessário. O resultado vai para a declaração de aplicabilidade.

Quem conhece a ISO 27001 reconhece a lógica: é o mesmo mecanismo do Anexo A de segurança da informação, só que com controles próprios de IA. A diferença de peso está no conteúdo — avaliação de impacto, ciclo de vida, dados para treinamento e uso responsável não existem no anexo da 27001.

Três regras práticas antes de entrar nos grupos:

• o Anexo A é referência, não teto: a organização pode adotar controles adicionais que não estão nele;
• controle excluído precisa de justificativa ligada ao escopo, ao papel ou ao resultado da avaliação de risco — "não deu tempo" não é justificativa;
• o Anexo B, também normativo, traz a orientação de implementação de cada controle. Ele é o primeiro lugar para resolver dúvida de interpretação.

Os 9 grupos de controles, em visão geral

A numeração começa em A.2 porque o A.1 é a introdução do anexo. A tabela resume o objetivo de cada grupo e quantos controles ele tem:

Os 38 controles não pesam igual para todo mundo. Uma empresa que só usa IA de terceiros vai concentrar esforço em A.2, A.3, A.5, A.9 e A.10. Quem desenvolve modelos tem o centro de gravidade em A.6 e A.7. O papel declarado no escopo, exigido pela cláusula 4, decide onde está o trabalho.

A.2 — Políticas relacionadas à IA

São 3 controles. O grupo pede uma política de IA documentada e aprovada pela direção, o alinhamento dela com as outras políticas da organização (segurança da informação, privacidade, qualidade, ética, compras) e a revisão em intervalos planejados.

Evidência típica: política de IA assinada, com data de aprovação e de revisão; registro de que ela foi comparada com as políticas existentes; ata ou registro da última revisão. A política da cláusula 5.2 e a do A.2 costumam ser o mesmo documento — basta que ele cubra os dois lados.

O erro comum é a política genérica, que serviria para qualquer empresa ("usamos IA de forma ética e responsável"). O auditor procura compromisso verificável: quais usos são permitidos, quais exigem aprovação, quem aprova e o que é proibido. A política de uso aceitável detalhada no artigo de governança de IA é um bom ponto de partida.

A.3 — Organização interna

São 2 controles: definir papéis e responsabilidades para a IA ao longo da organização, e criar um processo para que pessoas reportem preocupações sobre os sistemas de IA.

O primeiro é a matriz de responsabilidades: quem aprova um novo uso de IA, quem responde por cada sistema, quem faz avaliação de impacto, quem decide desligar um modelo que saiu do controle. O segundo é um canal — pode ser o canal de ética ou de incidentes já existente — que aceite relatos sobre IA, com tratamento, confidencialidade e proteção a quem reporta.

Evidência típica: matriz RACI ou descrição de cargos com atribuições de IA; procedimento do canal de reporte; registros de relatos recebidos e tratados (ou evidência de que o canal foi divulgado, se ainda não houve relato).

A.4 — Recursos para sistemas de IA

São 5 controles, todos de inventário: documentar os recursos que cada sistema de IA usa — recursos de dados, ferramentas, recursos de sistema e computação e recursos humanos — além de um controle geral que pede a documentação desses recursos para entender e gerir o risco.

Na prática, é uma ficha por sistema de IA: que bases de dados alimentam o modelo, que bibliotecas, plataformas ou APIs ele usa, onde roda (nuvem própria, provedor, local), e que competências as pessoas que o mantêm precisam ter.

Evidência típica: inventário de sistemas de IA com os recursos de cada um; registro de competências da equipe técnica; contratos ou termos das plataformas usadas. Esse inventário é a base de quase todo o resto do anexo — sem ele, a avaliação de impacto e o controle de fornecedores ficam no ar.

A.5 — Avaliação de impactos dos sistemas de IA

São 4 controles: ter um processo de avaliação de impacto, documentar as avaliações, avaliar o impacto em indivíduos ou grupos de indivíduos e avaliar o impacto social dos sistemas.

É o grupo que mais diferencia a 42001 de outras normas de gestão. Risco olha a organização; impacto olha quem a IA atinge — clientes, candidatos a emprego, pacientes, cidadãos, mesmo que não sejam clientes. Viés, discriminação, perda de autonomia, dano à segurança física e efeitos em escala entram aqui.

Evidência típica: procedimento de avaliação de impacto com critérios e gatilhos de revisão; avaliação registrada por sistema, com partes afetadas identificadas e medidas adotadas. A ISO/IEC 42005:2025 dá orientação detalhada de como fazer — veja o passo a passo em avaliação de impacto e de risco de IA.

A.6 — Ciclo de vida do sistema de IA

É o maior grupo, com 9 controles, e o mais técnico. Ele cobre o sistema de IA da concepção à operação:

• objetivos de desenvolvimento responsável — o que a organização se compromete a garantir quando desenvolve IA;
• processos de projeto e desenvolvimento definidos e seguidos;
• requisitos e especificação de cada sistema, incluindo requisitos de desempenho e de uso responsável;
• documentação de projeto e desenvolvimento;
• verificação e validação — testes com critério de aceite definido antes;
• implantação — plano e aprovação antes de colocar em produção;
• operação e monitoramento — desempenho, deriva (drift), falhas, uso indevido;
• documentação técnica disponível para quem precisa dela;
• registros de eventos (logs) que permitam rastrear o que o sistema fez.

Para quem só consome IA de terceiros, boa parte desse grupo pode ser excluída ou reduzida — mas operação, monitoramento e registros de eventos continuam valendo para o uso que a organização faz. Excluir A.6 inteiro com a frase "não desenvolvemos IA" raramente se sustenta numa auditoria.

Evidência típica: especificação e critério de aceite por sistema; relatórios de teste e validação; registro de aprovação de implantação; painel ou relatório de monitoramento; política de retenção de logs.

Quer isso avaliado na sua empresa?

Diagnóstico gratuito do uso de inteligência artificial: papéis, risco, impacto e o que falta para um SGIA auditável.

Falar com a Olívia

A.7 — Dados para sistemas de IA

São 5 controles: dados para desenvolvimento e melhoria do sistema, aquisição de dados, qualidade dos dados, proveniência e preparação dos dados.

A regra que segura o grupo é simples: dado ruim gera IA ruim. O auditor vai perguntar de onde veio a base de treinamento, com que direito ela foi usada, como a qualidade foi verificada, que vieses foram procurados e como os dados foram limpos, rotulados ou transformados.

Aqui o Anexo A encosta na LGPD: dado pessoal usado para treinar ou operar modelo precisa de base legal, finalidade e minimização. O controle de proveniência também ajuda a responder questionamento de direito autoral e de licença de bases de terceiros.

Evidência típica: ficha de dados por conjunto (origem, licença, base legal, data, responsável); critérios e resultados de qualidade; registro das etapas de preparação.

A.8 — Informação às partes interessadas

São 4 controles: documentação e informação para usuários do sistema de IA, meios externos de reporte para que terceiros relatem efeitos adversos, comunicação de incidentes e informação às partes interessadas sobre o sistema.

É o grupo da transparência. Quem usa ou é afetado pelo sistema precisa saber que está interagindo com IA, para que ela serve, quais as limitações e como reclamar. Esse ponto conversa diretamente com o AI Act europeu e com o PL 2338 no Brasil — veja o que muda com o PL 2338 e o AI Act.

Evidência típica: aviso de uso de IA nas interfaces; manual ou ficha do sistema para usuários; canal externo de reporte publicado; procedimento de comunicação de incidentes com critérios de quem avisar e em que prazo.

A.9 — Uso de sistemas de IA

São 3 controles: processos para uso responsável, objetivos de uso responsável e garantia de que o sistema é usado conforme o uso pretendido.

É o grupo mais relevante para quem é usuário de IA. Ele cobre a ferramenta generativa que a equipe usa, o modelo de crédito comprado de um fornecedor, o filtro automático de currículos. A pergunta central é: o sistema está sendo usado para o que foi aprovado, ou alguém o estendeu a decisões para as quais ele não foi avaliado?

É também onde se trata o shadow AI — o uso de ferramentas não homologadas. Evidência típica: lista de usos aprovados por sistema; regras de supervisão humana; registro de revisão de uso; ações tomadas quando um uso fora do pretendido foi detectado.

A.10 — Relacionamento com terceiros e clientes

São 3 controles: alocação de responsabilidades entre a organização, parceiros, fornecedores e clientes; gestão de fornecedores de IA; e atenção às necessidades e expectativas dos clientes.

Quase nenhuma empresa constrói tudo sozinha: modelo de fundação de um provedor, plataforma de outro, integração feita por um terceiro. O grupo pede que fique escrito quem responde por quê — quem garante a qualidade dos dados, quem monitora, quem comunica incidente — e que fornecedores de IA passem por avaliação antes de serem contratados.

Evidência típica: cláusulas contratuais de IA (uso de dados, responsabilidade, notificação de incidente, direito de auditoria); questionário ou avaliação de fornecedores de IA; registro de requisitos de clientes sobre IA.

Como montar a declaração de aplicabilidade

A declaração de aplicabilidade (DA) é o documento que liga o tratamento de risco ao Anexo A. Ela precisa conter, para cada um dos 38 controles:

1. se o controle é aplicável ou não;
2. a justificativa da inclusão (qual risco ou impacto ele trata, ou que requisito o exige);
3. a justificativa da exclusão, quando excluído;
4. se o controle está implementado, em implantação ou planejado;
5. controles adicionais adotados que não estão no Anexo A.

Uma DA boa é rastreável: o auditor escolhe um controle, segue a justificativa até o risco ou impacto avaliado e depois até a evidência em campo. Se a corrente quebra em algum ponto — controle "aplicável" sem risco associado, risco alto sem controle —, aparece a não conformidade.

Justificativas de exclusão que costumam se sustentar estão ligadas ao papel: uma organização que só usa IA de terceiros pode excluir controles de projeto e desenvolvimento do A.6, explicando que esse processo é do fornecedor e que a responsabilidade está alocada em contrato (A.10). O que não se sustenta é excluir por conveniência um controle que trata um risco já avaliado como relevante.

Anexos B, C e D: para que servem

• Anexo B (normativo) — orientação de implementação de cada controle do Anexo A. Por ser normativo, é o texto que resolve divergência de interpretação com o auditor.
• Anexo C (informativo) — objetivos organizacionais e fontes de risco de IA. É útil na fase de avaliação de risco como lista de partida: justiça, segurança, privacidade, robustez, transparência, nível de automação, falta de explicabilidade, entre outros.
• Anexo D (informativo) — uso do sistema de gestão de IA entre domínios e setores, e integração com outras normas de sistema de gestão.

Checklist prático do Anexo A

Uma forma rápida de medir a distância até a auditoria é responder, por grupo, se existe evidência — não intenção:

Erros comuns na implantação do Anexo A

• Começar pelo anexo, não pelo risco. Controle escolhido antes da avaliação de risco e de impacto vira lista de compras sem justificativa.
• Copiar a DA da 27001. A estrutura é parecida; o conteúdo, não. Os controles de impacto, ciclo de vida e dados não têm equivalente no anexo de segurança.
• Inventário incompleto. Esquecer a IA embutida em software comprado (CRM, RH, atendimento) e as ferramentas que a equipe usa por conta própria.
• Excluir A.6 e A.7 por ser "usuário". Operação, monitoramento e dados de entrada continuam sendo responsabilidade de quem usa.
• Documento sem operação. Política e procedimento existem, mas não há registro de avaliação, teste ou relato tratado. O estágio 2 da certificação procura exatamente isso.

Quem já tem SGSI aproveita boa parte da infraestrutura — controle de fornecedores, gestão de incidentes, logs, controle de documentos. O que reaproveitar e o que é novo está em ISO 42001 e ISO 27001: como integrar. Para começar, o caminho mais curto é montar o inventário do A.4 e fazer a primeira avaliação de impacto do sistema mais crítico: o resto do anexo se organiza a partir daí.