Gap analysis ISO 42001: por que o total de itens pendentes engana

O problema

Todo relatório de gap analysis ISO 42001 chega com uma lista de itens marcados como pendentes. O primeiro instinto de quem recebe esse relatório é somar quantos itens vieram assim e tirar uma conclusão de tamanho do projeto. Esse instinto erra quase sempre, porque nem todo item pendente custa o mesmo, e um relatório que não separa esses pesos vira ruído em vez de plano de ação.
Sou auditor de sistemas críticos, e vejo esse erro se repetir em empresas de porte bem diferente: gestor recebe o gap analysis, vê metade dos controles do Anexo A fora de conformidade e decide, na mesma reunião, que o projeto é grande demais, ou que é pequeno demais para preocupar o conselho. Os dois extremos vêm do mesmo vício de leitura.

Os quatro níveis que importam mais que o total

Um relatório de gap analysis ISO 42001 bem feito não entrega nota única nem percentual isolado. Ele classifica cada requisito da norma e cada controle do Anexo A selecionado em quatro níveis: conforme, quando existe evidência documentada e recente; parcialmente conforme, quando o processo existe mas é aplicado de forma inconsistente ou sem registro completo; não conforme, quando não há processo, registro nem dono definido; e não aplicável, quando o controle foi excluído com justificativa escrita no documento de aplicabilidade.
Essa classificação em quatro níveis existe porque uma marcação simples de sim ou não esconde a diferença entre uma lacuna de fundação e um ajuste de detalhe. Prefiro tratar cada não conformidade como um registro com três campos obrigatórios: o que falta, por que falta e quem vai resolver, em vez de uma linha solta numa planilha de cem itens.

"Não aplicável" não é "não conforme"

Confundir essas duas categorias é o erro de classificação mais caro que vejo. "Não aplicável" é uma decisão documentada de que aquele controle não se encaixa no escopo da empresa, por exemplo, controle de fornecedor de modelo de fundação numa empresa que só usa modelos prontos sem retreinar nada. "Não conforme" é lacuna real, sem justificativa, e conta contra a empresa na hora de fechar o plano de ação. Um relatório que mistura as duas categorias infla artificialmente o tamanho do projeto, porque trata como pendência real algo que já deveria estar fechado com uma linha de justificativa.

Por que o total de pendentes engana

O erro mais comum que vejo é tratar a contagem de itens pendentes como medida de esforço. Um controle sem dono definido pode ser resolvido numa reunião de uma hora. Um processo de avaliação de impacto inexistente para todos os sistemas de IA em produção pode consumir meses de trabalho. A leitura certa separa lacuna fundacional, que trava qualquer avanço seguinte, de lacuna de melhoria, que pode esperar o próximo ciclo sem risco nenhum.
Uso a lógica de quatro funções do NIST, mapear, medir, gerenciar e governar, para priorizar um relatório de gap analysis: primeiro resolva o que impede mapear os sistemas de IA em uso, depois o que impede medir o risco de cada um, só então ataque o que melhora a governança já existente.

Um exemplo de reclassificação

Uma empresa recebe o relatório e vê a maior parte dos controles do Anexo A marcados fora de conformidade. O primeiro instinto é declarar o projeto grande demais. Ao reclassificar item por item, boa parte desses itens eram controles de fornecedor de modelo de fundação, marcados como não conforme quando deveriam estar como não aplicável, porque a empresa só usa modelos prontos de terceiros sem retreinamento. A lacuna real, depois da reclassificação, ficou bem menor, concentrada em três processos: inventário de sistemas de IA, avaliação de impacto e papéis de governança.
Essa reclassificação é o primeiro trabalho depois de receber o relatório, antes de qualquer plano de ação ou orçamento. Boa parte do que aparece como não aplicável só se sustenta se a empresa documentar por que aquele controle específico não se encaixa no escopo dela, com critério consistente para os dois lados do relatório.

O que fazer com cada não conformidade

Para cada item não conforme, recomendo registrar três coisas antes de corrigir: o motivo da lacuna, se o processo nunca existiu, existiu e foi abandonado, ou existe mas em outra área sem integração, o dono responsável por fechar e uma data realista. Uma avaliação de impacto de um sistema de IA de porte médio costuma levar entre 80 e 120 horas de trabalho qualificado. Essa é uma premissa minha, baseada no volume de documentação que normalmente falta, não um fato medido para qualquer empresa específica.

O gap analysis não é a certificação

Um relatório de gap analysis mostra onde a empresa está hoje. Ele não substitui a auditoria interna, a análise crítica pela direção nem a evidência acumulada ao longo de meses de operação, etapas que a própria norma exige antes de qualquer organismo de certificação emitir o certificado. Tratar o gap analysis como linha de chegada é um dos erros mais caros que vejo nesse processo. A auditoria interna confirma, meses depois, se o que foi corrigido continua valendo, e pular essa etapa para correr direto à certificação é um dos jeitos mais comuns de reprovar numa auditoria externa.

Conclusão

Um relatório com muita não conformidade não significa, sozinho, que a certificação está longe. Três não conformidades fundacionais, sem inventário, sem avaliação de risco e sem dono de processo, pesam mais do que vinte itens de melhoria pontual. O relatório já diz onde cavar. A pergunta que resta é em que ordem, e essa ordem muda o tamanho do projeto muito mais do que o percentual que aparece na primeira página.
Este texto é uma versão condensada de uma análise mais longa que publiquei em https://iso42001.com.br/artigos/gap-analysis-iso-42001-resultado/