O que um auditor pergunta numa auditoria ISO 42001

Numa auditoria ISO 42001, o auditor não avalia se o seu modelo de IA é bom. Ele avalia se existe um sistema de gestão documentado, com dono, por trás de cada sistema de IA em produção: política assinada, inventário de sistemas, avaliação de impacto, controle sobre o dado de treinamento e evidência de que a cláusula 9.2 e o Anexo A foram cumpridos na prática, não só escritos num documento.

Isso muda o jeito de se preparar para a auditoria ISO 42001. Quem lê a norma pensando em “o que escrever” quase sempre erra o alvo, porque o auditor não lê a política, ele testa se ela é seguida, com registro, dono e data. O Gap Analysis gratuito devolve esse retrato em menos de uma hora, cláusula por cláusula, antes de qualquer auditor chegar, e mostra o que já tem evidência e o que ainda é apenas intenção escrita num documento que ninguém testou.

As duas perguntas que toda auditoria interna ISO 42001 responde

Eu simplifico a cláusula 9.2 da ISO 42001 em duas perguntas, porque é literalmente para isso que ela existe⁴. Primeira: o seu sistema de gestão de IA cumpre o que a própria empresa prometeu fazer e o que a norma exige? Segunda: esse sistema está implementado de verdade e mantido, não só criado uma vez para passar na primeira auditoria? A auditoria interna ISO 42001 precisa responder as duas, com programa de auditoria cobrindo todo o ciclo, plano por auditoria, relatório com achado e evidência, e prova de que quem auditou não avaliou o próprio trabalho⁴.

Esse último ponto trava empresa pequena. Se a mesma pessoa que escreveu a política de IA também assina o relatório de auditoria interna que aprova essa política, a independência exigida pela norma não existe, e isso é o primeiro ponto que um auditor de certificação testa, antes de olhar qualquer controle do Anexo A. Eu vejo esse problema se repetir em empresa que tem um único responsável por IA e nenhum comitê de risco por trás dele: a correção mais barata é rotear a auditoria interna para outra área da empresa, jurídico, compliance ou um par de outra unidade, que não teve mão na política avaliada, sem precisar contratar um auditor externo.

O que o auditor pede, controle por controle do Anexo A

O Anexo A da ISO 42001 organiza nove grupos de controle, de A.2 a A.10, cada um com um tipo de evidência esperada diferente⁵. Eu trato cada grupo como uma pergunta separada que o auditor vai fazer, porque é assim que ele realmente trabalha: não lê o Anexo A inteiro de uma vez, percorre grupo por grupo pedindo o documento que prova aquele ponto específico.

Reparo que a coluna da direita nunca é “o sistema funciona bem”. É sempre “existe prova de que alguém decidiu, revisou e documentou isso”. Essa é a diferença entre auditoria de qualidade de modelo, que não é o escopo da 42001, e auditoria de gestão, que é o escopo inteiro da norma¹.

Também reparo numa ordem que se repete em quase toda auditoria que acompanho de perto, mesmo fora do contexto de IA: o auditor raramente começa pelo A.2, política, porque política bem escrita é fácil de produzir sob pressão, na véspera da visita. Ele começa pelo A.5, avaliação de impacto, porque esse é o controle que mais frequentemente existe só de nome. Uma empresa pode ter política de dez páginas e zero avaliação de impacto preenchida; a recíproca, política fraca com avaliação de impacto robusta, eu nunca vi. Por isso eu oriento quem está organizando a casa a inverter a ordem natural de trabalho: documentar primeiro o controle que o auditor vai cobrar primeiro, não o que é mais fácil de escrever.

Como a mesma pergunta muda entre financeiro, saúde e indústria

O Anexo A é o mesmo texto para qualquer setor, mas a pergunta que o auditor faz em cima dele muda de peso dependendo de quem é afetado pela decisão do sistema. Num banco ou numa empresa de crédito digital, a pergunta mais pesada cai sobre A.5 e A.9: o modelo de crédito decide ou apoia, e o critério usado para negar crédito está documentado de um jeito que resiste a uma reclamação formal no Banco Central ou no Procon? Eu já vi avaliação de impacto de crédito que descrevia o modelo em termos técnicos perfeitos e não dizia uma palavra sobre o efeito da decisão sobre quem foi negado.

Na saúde, o peso se desloca para A.4 e A.6: a empresa tem gente qualificada para validar clinicamente a recomendação do sistema, e existe controle sobre o que acontece quando o sistema erra numa situação com paciente real do outro lado? O padrão que mais aparece em saúde, mesmo antes de existir norma específica de IA com esse nome, é sempre o mesmo: documentação técnica excelente, nenhuma evidência de quem reviu clinicamente a recomendação antes dela chegar ao médico.

Na indústria, a pergunta pesada é A.7 e A.10: a origem do dado de sensor e de manutenção está documentada o suficiente para explicar por que o sistema recomendou parar uma linha, e o fornecedor do modelo preditivo responde contratualmente por um erro que causa parada não planejada?

Numa empresa de tecnologia que vende software para terceiros, o peso se desloca de novo, agora para A.8 e A.10: o cliente que usa a plataforma recebe informação clara sobre onde a IA entra na decisão que o produto apoia, e o contrato de licenciamento deixa explícito quem responde se a recomendação do sistema causar dano a esse cliente final? Empresa de tecnologia costuma documentar bem o que o produto faz. Documenta mal o que o produto não garante, que é exatamente o ponto que A.8 cobra: informação completa para quem depende do sistema, não só para quem vende.

O mesmo Anexo A, quatro perguntas de peso diferente, porque o risco que materializa quando o sistema erra é diferente em cada setor. Eu chegaria numa auditoria de crédito perguntando pelo critério de negação antes de perguntar pela arquitetura do modelo; chegaria numa auditoria de indústria perguntando pelo contrato do fornecedor antes de perguntar pela acurácia do sensor; chegaria numa auditoria de empresa de tecnologia perguntando pelo contrato com o cliente final antes de perguntar pela documentação técnica do produto.

As perguntas de auditoria ISO 42001 que mais pegam quem não se preparou

Na prática, cinco perguntas derrubam quem chega sem organização. A primeira é simples e quase ninguém responde de cara: quantos sistemas de IA operam hoje na empresa? Rodar essa pergunta num comitê de risco costuma revelar um número maior do que qualquer um esperava, porque ferramenta de produtividade instalada por um time sozinho também conta como sistema de IA em uso, com ou sem aprovação formal.

A segunda é sobre autonomia real: o sistema decide ou só apoia quem decide? A ficha técnica quase sempre diz “apoia, com possibilidade de override humano”. O log de uso, quando existe, frequentemente mostra outra coisa, decisão automática aceita sem revisão na maioria dos casos. O auditor pergunta pelos dois, ficha e log, porque só comparando os dois ele sabe qual é verdade.

A terceira é sobre rastreabilidade: dado o resultado de uma decisão específica, dá para reconstruir quem aprovou o modelo, qual versão rodou e qual dado alimentou aquela decisão? Essa é a pergunta que decide se a empresa se defende ou não numa disputa judicial ou numa reclamação de cliente, porque sem essa cadeia reconstruída a empresa só tem a palavra de quem operou o sistema, não um registro que resista a contestação.

A quarta é sobre fornecedor: se o modelo vem de terceiro, a empresa tem evidência de due diligence sobre esse fornecedor, ou só confia na reputação dele? Essa pergunta pega muita empresa de surpresa porque o raciocínio comum é “o fornecedor é grande, deve ter feito a lição de casa dele”. A 42001 não aceita essa lógica: a responsabilidade pelo controle do Anexo A.10 é de quem usa o modelo na própria operação, não só de quem o vendeu.

A quinta, e a que mais gente subestima, é sobre manutenção: a avaliação de impacto foi revisada na última mudança relevante do sistema, ou ficou congelada na versão que passou na primeira auditoria? Sistema de IA muda de comportamento quando o modelo é retreinado, quando a base de dado de entrada muda ou quando o volume de uso cresce o suficiente para expor um padrão que não aparecia antes. Avaliação de impacto parada no tempo, enquanto o sistema continua operando e mudando por baixo, é o tipo de lacuna que um auditor de certificação encontra sem esforço, só comparando a data do documento com a data da última mudança registrada no sistema.

Organizar a resposta para essas cinco perguntas antes do auditor chegar é, na prática, montar os documentos de base da 42001 do zero: política, inventário, avaliação de impacto, mapa de dado. Os modelos de política e inventário de sistemas de IA existem porque essa parte de organização documental consome mais tempo do que qualquer controle técnico específico, e ter um ponto de partida encurta exatamente essa parte, sem substituir a decisão de quais controles do Anexo A se aplicam ao caso da empresa.

O que muda com a ISO 42006: o auditor também está sendo testado

Até 2025, quem conduzia a auditoria era avaliado só pela regra geral de competência de auditor de sistema de gestão, a mesma usada para ISO 9001 ou ISO 27001. A ISO/IEC 42006:2025 muda isso: ela fixa requisito específico para o organismo de certificação que audita contra a 42001, não para a empresa auditada². Chamo esse ponto de ISO 42006 auditor: a competência nova exigida é de quem audita, não de quem é auditado, mas o efeito prático chega até a empresa de todo jeito, porque muda o nível de pergunta que o auditor está preparado para fazer.

A exigência central da 42006 é competência coletiva da equipe de auditoria, não de uma pessoa só: o time precisa somar conhecimento de tecnologia de IA, governança, Anexo A, prática de auditoria de sistema de gestão e obrigação legal aplicável ao setor da empresa auditada²³. A norma também muda o cálculo do tempo de auditoria, agora baseado no número de sistemas de IA, na complexidade de cada um, no risco regulatório envolvido e na existência de fornecedor terceirizado no ciclo de vida do modelo³.

Na prática, isso significa que o organismo de certificação vai pedir o inventário de sistemas de IA antes de fechar o orçamento da auditoria, não depois. É comum um processo de certificação atrasar semanas inteiras quando a empresa só apresenta o escopo real depois do contrato assinado, porque o organismo precisa recalcular o tempo de auditoria no meio do processo, com nova cotação e novo cronograma. Com a 42006, isso deixa de ser exceção e passa a ser etapa formal: sem inventário e sem classificação de risco de cada sistema, o organismo de certificação não tem base para calcular quanto tempo a auditoria vai levar, nem quanto vai custar.

Premissa minha, sem fonte de mercado para sustentar o número: organizar o inventário e a classificação de risco de cada sistema de IA, no nível de detalhe que um orçamento de auditoria sob a 42006 exige, costuma consumir de 30 a 50 horas de trabalho qualificado numa empresa de porte médio com dez a vinte sistemas em produção. Esse número varia com quanto a empresa já documentou antes, com quantos sistemas foram instalados por time sem aprovação formal e com o tamanho do parque de fornecedor terceirizado envolvido. Empresa que já tem comitê de risco rodando gasta menos tempo nessa etapa; empresa que nunca listou os próprios sistemas de IA começa do zero e sente o peso completo desse número.

Que evidências de auditoria ISO 42001 convencem, e quais não convencem

Evidência que convence tem três características: é datada, tem dono identificável e mostra decisão, não só existência. Uma política de IA sem data de revisão não convence, porque o auditor não sabe se ela ainda reflete a operação atual. Um organograma sem nome de responsável por cada caixa não convence, porque não prova quem decide de fato quando um sistema de IA causa um problema.

Evidência que não convence, mesmo volumosa, é a que descreve intenção sem registro de execução. Documento de dez páginas sobre “processo de avaliação de impacto” sem nenhuma avaliação de impacto preenchida anexada é, para o auditor, prova de que o processo existe no papel e não existe na prática. Eu vi esse padrão se repetir em auditoria sob SOX antes da ISO 42001 existir com esse escopo: política bem escrita, processo real inexistente, e o auditor sempre encontra a diferença, porque pede o documento preenchido, não o modelo em branco.

Existe também o erro inverso, menos comum mas igualmente fatal: processo real que ninguém documentou. A equipe de dados avalia o impacto de cada modelo novo informalmente, numa reunião, sem registro formal nenhum. Do ponto de vista de quem opera, o controle existe e funciona. Do ponto de vista do auditor, que só pode avaliar o que está documentado e datado, esse controle simplesmente não existe, porque não há nada para verificar. Entre as duas falhas, processo documentado e não exercido, ou processo exercido e não documentado, a segunda costuma ser mais fácil de corrigir: a empresa já sabe fazer a coisa certa, só precisa aprender a registrar o que já faz.

Auditoria interna e auditoria de certificação: perguntas diferentes, mesma base

A auditoria interna ISO 42001, exigida pela cláusula 9.2, é conduzida por alguém da própria empresa ou contratado por ela, com foco em encontrar e corrigir falha antes que ela apareça para um terceiro. A auditoria de certificação é conduzida por um organismo acreditado sob a nova regra da ISO 42006, com foco em decidir se a empresa recebe ou mantém o certificado². As perguntas de fundo são as mesmas, cláusula por cláusula e controle por controle do Anexo A, mas o peso de cada resposta muda: na interna, uma falha vira ação corretiva registrada; na de certificação, uma falha não corrigida pode virar não conformidade que atrasa ou impede a emissão do certificado.

Eu recomendo tratar a auditoria interna como ensaio da de certificação, não como formalidade para cumprir calendário. Uma empresa que já respondeu as perguntas difíceis internamente, com não conformidade registrada e corrigida, chega para o organismo de certificação com evidência de que o sistema de gestão funciona de verdade, que é exatamente o que a cláusula 9.2 pede e o que qualquer auditor externo testa primeiro.

A norma não fixa uma frequência única para a auditoria interna, e isso é mais útil do que parece numa primeira leitura⁴. O programa de auditoria precisa ser baseado em risco, considerando a importância de cada processo e o resultado das auditorias anteriores, não um calendário fixo de uma vez por ano para tudo igual. Na prática, eu auditaria com mais frequência o sistema de IA de maior risco, crédito, triagem de currículo, diagnóstico, e deixaria um sistema de baixo risco, como um chatbot de dúvida frequente sem acesso a dado sensível, num ciclo mais espaçado. Tratar todo sistema de IA com a mesma frequência de revisão desperdiça esforço no que importa menos e, pior, dá a mesma falsa sensação de segurança para o que importa mais.

Por onde eu começaria, se fosse auditar a sua empresa hoje

Eu começaria pelo inventário de sistemas de IA, antes de qualquer controle do Anexo A, porque nenhuma das perguntas acima tem resposta sem saber quantos sistemas existem e quem é dono de cada um. Uma das auditorias que conduzi foi de controles ITIL numa indústria, com zero chamados perdidos e redução de 75% no tempo de processamento depois da rastreabilidade virar norma de trabalho, não exceção. O mecanismo que sustentou esse resultado é o mesmo que sustenta uma boa auditoria ISO 42001: saber exatamente onde cada processo começa, quem é responsável por ele e onde está o registro que prova isso. Troca-se ticket de chamado por decisão de modelo, e o auditor que chega depois pede exatamente o mesmo tipo de rastro.

Depois do inventário, eu priorizaria a avaliação de impacto dos sistemas de maior risco, não a política geral, porque é ali que a maioria das empresas descobre a lacuna mais cara de fechar depois, a que exige reconstruir decisão já tomada sem o registro que deveria ter acompanhado cada etapa. E só então eu trataria do resto do Anexo A, controle por controle, na ordem em que o auditor realmente vai perguntar, não na ordem em que a norma está numerada no papel.

Se a sua empresa fosse auditada na próxima segunda-feira, quantas das cinco perguntas deste texto você conseguiria responder com documento na mão, não de memória?

Veja também