Uma scale-up brasileira de SaaS B2B lançou um agente de IA que responde dúvidas de clientes e consulta dados de contrato automaticamente. Fechou negociação com um banco — e o time de segurança do banco pediu evidência de governança de IA antes de assinar. Não um relatório de pentest qualquer: queriam saber como a empresa avalia risco, impacto e supervisão humana sobre o próprio modelo. Esse pedido, que até pouco tempo era raro, está se tornando padrão em 2026.

O Jurídico do Cliente Começou a Pedir Isso

Um levantamento da KPMG de maio de 2026 mostra que grandes organizações já exigem padrões mínimos de governança de IA de seus fornecedores — do mesmo jeito que passaram a exigir SOC 2 e ISO 27001 na década anterior. A diferença é que, para IA, a norma que está virando referência de mercado é a ISO/IEC 42001: o padrão internacional para Sistema de Gestão de IA (AIMS).

Isso não é regulação obrigatória no Brasil — é pressão contratual. E pressão contratual trava negociação tão rápido quanto lei.

O Que é a ISO/IEC 42001

AIMS (AI Management System): o conjunto de processos, políticas e controles que uma organização mantém para gerenciar riscos e impactos de sistemas de IA ao longo do ciclo de vida — desde o design até o monitoramento em produção. A ISO 42001 certifica esse sistema de gestão, não um modelo específico.

O ponto que diferencia essa norma de outras ISOs de segurança: ela exige uma avaliação de impacto de IA — como o sistema afeta indivíduos, grupos e a sociedade, não só a confidencialidade de dados — além de supervisão humana documentada sobre decisões automatizadas relevantes.

O Que a Norma Exige na Prática

A certificação segue as cláusulas 4 a 10 da norma. Resumindo em etapas que uma empresa real precisa cumprir:

1. Definir o escopo do AIMS. Quais sistemas de IA, times e processos entram na certificação — escopo mal definido é a causa mais comum de atraso, igual acontece em SOC 2.
2. Comprometimento da alta direção. Política de IA formal, com papéis e responsabilidades atribuídos — não pode ser um documento que só o time técnico conhece.
3. Avaliação de risco e de impacto de IA. Identificar onde o sistema pode falhar, discriminar, expor dados ou tomar decisão errada sem supervisão — e documentar o tratamento para cada risco.
4. Treinamento e conscientização. Equipes que constroem, operam ou usam o sistema de IA precisam entender os controles, não só a área de segurança.
5. Controles operacionais com registros. Implementar os controles do Anexo A da norma e manter evidência de que estão funcionando — não só que existem no papel.
6. Auditorias internas e revisão pela direção. Verificação periódica e imparcial de que o AIMS continua funcionando conforme o desenho original.
7. Tratamento de não conformidades. Corrigir falhas encontradas e alimentar isso de volta no ciclo de melhoria contínua.

O ciclo de certificação dura três anos, com auditorias de acompanhamento no meio do caminho — parecido com o ciclo de recertificação da ISO 27001.

Brasil Ainda Não Tem Lei — Mas o Mercado Já Decidiu

O Projeto de Lei 2338/2023, que regularia o uso de IA no Brasil, ainda está parado esperando parecer do relator na Câmara dos Deputados. Sem lei específica em vigor, a ISO 42001 é voluntária — mas voluntária não significa opcional na prática: ela está funcionando como a referência que clientes, parceiros e auditores usam para decidir em quem confiar.

Uma ressalva importante: a certificação comprova maturidade de governança dentro de um escopo definido — não comprova a legalidade do sistema de IA em si. Empresas que operam IA continuam sujeitas à LGPD normalmente, e quem vende para a Europa também responde ao AI Act europeu, que adiou obrigações para sistemas de alto risco de agosto de 2026 para dezembro de 2027.

Onde o Pentest Entra Nessa Avaliação

A cláusula de avaliação de risco e impacto da ISO 42001 pede evidência técnica de que os riscos do sistema de IA foram testados — não apenas listados em planilha. É exatamente aí que entra o pentest especializado em aplicações de IA e LLMs: prompt injection, vazamento de dados via prompt e shadow AI são falhas que um pentest tradicional de API não cobre, e são exatamente os riscos que um auditor de AIMS vai perguntar como foram testados.

O padrão se repete: assim como empresas brasileiras de SaaS passaram a precisar de pentest estruturado dentro do calendário de auditoria para chegar em SOC 2, a exigência de governança de IA auditável está seguindo o mesmo caminho — só que mais rápido, porque o mercado já viu esse filme com SOC 2 e ISO 27001 e não quer ser pego de surpresa de novo.

Quem já tem processo de conformidade rodando — LGPD, ISO 27001 ou SOC 2 — não parte do zero: parte da documentação de risco e controle de acesso que já existe. O que falta, na maioria dos casos, é a avaliação de impacto específica de IA e a evidência de teste da camada de modelo.

Antes que o jurídico de um cliente grande trave sua próxima negociação pedindo isso, vale mapear onde sua empresa usa IA com dado sensível e testar essa camada antes de alguém perguntar.

Fale com a LDL Security sobre avaliação de risco e pentest em aplicações de IA →