Auditoria interna de IA: qual frequência e escopo usar?

Não existe um número de vezes por ano escrito em nenhuma norma. A frequência da auditoria interna de IA é decidida pela própria empresa, com base no risco de cada sistema e na velocidade com que ele muda, não num calendário copiado de outro processo. A ISO 42001 exige um programa de auditoria planejado e documentado; não dita se esse plano roda a cada três meses ou uma vez por ano.

Isso incomoda quem queria uma resposta pronta, mas é a resposta certa: cláusula genérica não decide pelo seu parque de sistemas. O Gap Analysis gratuito existe para essa primeira decisão, porque mostra, cláusula por cláusula, onde seu programa de auditoria já tem lacuna antes mesmo de você escolher a frequência de cada sistema. Só depois desse retrato o escopo da auditoria interna de sistemas de IA deixa de ser palpite e vira plano com critério.

O que a cláusula 9.2 da ISO 42001 realmente exige (e o que ela deixa para você decidir)

A cláusula 9.2 pede três coisas: intervalos planejados, imparcialidade de quem audita e evidência documentada do que foi verificado e do resultado¹. Ela não lista um número de auditorias por ano nem separa sistema de alto risco de sistema trivial. Essa separação é trabalho seu.

Eu leio essa abertura como convite, não como lacuna. A norma de gestão de IA segue a mesma lógica das demais normas de gestão: o programa de auditoria é desenhado pela organização, e a orientação sobre como desenhar esse programa está em outro documento, a ISO 19011. A edição atual, publicada em maio de 2026, reforça exatamente o planejamento de auditoria baseado em risco e substitui a edição de 2018². Quem ainda planeja auditoria pela regra antiga está usando um guia que a própria ISO já aposentou.

A revisão de 2026 também trata auditoria remota e híbrida como método normal, não como exceção temporária, e passa a cobrar competência em tecnologia da informação de quem audita². Para auditoria interna ISO 42001, isso resolve um problema prático: parte da evidência de um sistema de IA vive em log, em painel de monitoramento e em repositório de versão de modelo, não em papel, e o auditor que não sabe ler essas três fontes audita só a política escrita, nunca o sistema de verdade.

Qual é a frequência da auditoria interna de IA recomendada por risco?

Depende do risco do sistema e da frequência com que ele muda, não de um número universal. O NIST AI RMF resolve essa mesma pergunta pelo lado do risco em vez do calendário: a função Govern pede que a empresa defina, por escrito, a frequência da revisão periódica de cada sistema, como parte do próprio processo de gestão de risco, e não como item solto de auditoria³.

Eu uso uma régua de três faixas para organizar isso, e trato os números abaixo como premissa minha, sem fonte de mercado que os valide: sistema que decide sozinho sobre crédito, contratação ou saúde entra na faixa trimestral; sistema que apoia decisão humana, mas pesa na recomendação final, entra na faixa semestral; ferramenta de produtividade interna, sem efeito direto sobre terceiro, entra na faixa anual, junto com a revisão completa do sistema de gestão.

Essa régua muda quando o sistema muda. Modelo retreinado todo mês com dado novo do cliente não espera o calendário anual chegar para ser revisado de novo; a frequência acompanha a mudança, não o aniversário da última auditoria.

Três eventos, além do calendário, deveriam disparar uma auditoria fora de hora: troca de fornecedor do modelo, mudança relevante na base de dados de treino ou de referência, e qualquer incidente relatado por quem usa o sistema no dia a dia. Esperar a próxima data agendada nesses casos custa caro: se o incidente vira reclamação formal ou vira pauta do comitê de auditoria antes de a empresa ter revisado o sistema por conta própria, a pergunta que sobra não é mais técnica, é “por que ninguém olhou antes”.

O que entra no escopo da auditoria interna de sistemas de IA

O escopo da auditoria interna de sistemas de IA cobre cinco frentes, e a maioria das empresas que eu vejo audita só a primeira: inventário atualizado de onde a IA decide ou influencia algo; controle sobre a qualidade e a origem do dado usado; registro de quem aprovou o uso daquele sistema naquele processo; due diligence do fornecedor do modelo; e evidência de supervisão humana no ponto em que a decisão afeta alguém de fora da empresa.

Esse cenário é o motivo pelo qual escopo técnico e escopo de controle precisam conviver na mesma auditoria interna de IA, não em exercícios separados que nunca se encontram. Eu já vi o equivalente fora de IA, numa auditoria de SOX que conduzi numa mineradora, aprovada pela Ernst & Young sem ressalvas: o que sustentou a aprovação não foi o sistema em si, foi o rastro de quem decidiu, testou e aprovou cada mudança, com redução de 90% no tempo de troubleshooting como efeito colateral. Sistema de IA sem esse mesmo rastro reproduz, com outro nome, o problema que a auditoria tradicional já resolveu há tempos.

As cláusulas do sistema de gestão e os controles do Anexo A dão a lista completa do que cabe no escopo; a auditoria interna não precisa reinventar essa lista, precisa decidir quanto peso dar a cada item conforme o risco levantado no inventário.

Os modelos de política e inventário de sistemas de IA ajudam a documentar essas cinco frentes sem montar cada formulário do zero, principalmente o registro de aprovação e a ficha de due diligence de fornecedor, que costumam ser os dois documentos que faltam quando a auditoria externa pede evidência.

A due diligence de fornecedor merece atenção maior do que costuma receber, porque é a frente mais fácil de terceirizar de leve. Pedir ao fornecedor um certificado ou uma declaração de conformidade não fecha o escopo: a auditoria interna de IA precisa verificar se aquela declaração ainda é verdadeira para o uso específico que a empresa faz do modelo, não só se ela existe. O artigo sobre due diligence de fornecedor de IA detalha as perguntas que sustentam essa verificação antes de qualquer contrato ser assinado.

Quem conduz a auditoria interna de IA sem virar o próprio fiscal

A cláusula 9.2 exige imparcialidade: quem auditou a implantação do sistema não audita a própria implantação depois¹. O modelo de três linhas que o IIA aplica à IA ajuda a separar esses papéis: a primeira linha é quem opera e usa o sistema no dia a dia; a segunda é o comitê de risco ou de governança de IA, que define política e monitora; a terceira é a auditoria interna, independente das outras duas, que testa se o que as linhas anteriores declaram fazer realmente acontece⁴.

Empresa pequena, sem estrutura para três linhas separadas, ainda consegue cumprir a imparcialidade: basta que quem audita um sistema não seja quem aprovou a entrada dele em produção. Isso já evita o conflito mais comum, que é o próprio dono do projeto de IA assinando embaixo a auditoria do próprio projeto.

O custo dessa separação, numa equipe pequena, é tempo de gente que já tem outra função principal, não dinheiro de contratação nova. Eu registraria essa limitação por escrito, como controle compensatório: se a mesma pessoa precisa acumular as duas pontas por falta de equipe, o comitê de risco sabe disso e revisa o resultado com mais atenção, em vez de tratar a auditoria interna como prova definitiva por padrão.

O que acontece quando a auditoria interna de IA não existe

Nesse vácuo, quem primeiro percebe o problema costuma ser de fora: um cliente grande pedindo evidência em due diligence, o auditor externo da certificação ou, pior, um incidente que vira pauta do conselho antes de qualquer comitê interno ter revisado o sistema envolvido. Nenhum desses três cenários dá tempo de montar o programa de auditoria depois que a pergunta já chegou.

O artigo sobre risco de IA para o CFO descreve essa mesma lacuna pelo lado financeiro: controle certificado sob SOX que depende de um sistema de IA nunca auditado internamente vira uma assinatura de confiança, não uma certificação. A auditoria interna de IA é a peça que falta nos dois casos, financeiro ou não: sem ela, toda certificação externa, toda due diligence de cliente e toda resposta ao conselho descansa em “a gente acha que está tudo bem”, nunca em evidência registrada.

Como auditar sistemas de IA internamente, passo a passo

Como auditar sistemas de IA internamente começa pelo inventário, não pela checklist de controles. O artigo sobre inventário de sistemas de IA detalha esse levantamento; sem ele, qualquer programa de auditoria de IA baseado em risco fica sem critério para separar o que entra na faixa trimestral do que entra na anual.

O artigo sobre o que um auditor pergunta numa auditoria de ISO 42001 mostra o outro lado dessa mesma mesa, o que o auditor de certificação questiona quando a auditoria interna já existe. Os dois exercícios se alimentam: quanto mais sólida a auditoria interna, menos surpresa a certificação externa traz.

Depois de decidir frequência e escopo, falta a mecânica de cada ciclo: perguntas por cláusula, classificação de não conformidade, estrutura do relatório. O guia de auditoria interna do SGAI cobre esse passo a passo; aqui a decisão é quando e o quê auditar, lá é como conduzir a auditoria já decidida.

Se a sua empresa já tem uma data fixa de auditoria de IA marcada no calendário anual, vale a pergunta inversa: ela foi escolhida porque é quando o risco pede, ou porque é quando sobrou espaço na agenda do comitê?

Veja também