Compliance e IA: o guia para C-level e jurídico

Compliance e IA é o programa formal — com dono, processo e evidência — que uma empresa monta para que o uso de inteligência artificial resista a uma auditoria: inventário de todos os sistemas em uso, avaliação de risco por caso de uso, trilha documental e papéis claros para jurídico, compliance e DPO. É diferente de "ter uma política de uso" (o documento que orienta o colaborador no dia a dia) — compliance é a camada que garante, com prova, que a política é seguida, que o risco é medido e que a diretoria tem visão do que está acontecendo. Este guia é para quem lidera esse programa — jurídico, compliance, diretoria — e mostra o que muda quando compliance entra formalmente na governança de IA, o que um programa cobre na prática e por onde começar.

O que muda quando compliance entra na governança de IA

Até aqui, a maioria das empresas brasileiras trata governança de IA como responsabilidade de TI ou de um comitê informal. Isso funciona até o primeiro incidente, o primeiro cliente que pede evidência de controle em due diligence, ou a primeira exigência regulatória com prazo — o momento em que compliance precisa deixar de ser convidado ocasional e virar dono de processo, com a mesma lógica que já aplica a anticorrupção, fraude e proteção de dados.

O gap é mensurável: segundo o recorte brasileiro do relatório KPMG Global AI in Finance Report, com 100 empresas do país, 34% já adotaram frameworks para orientar o uso de IA, conforme a KPMG — ou seja, a maioria ainda opera sem um. Como resume a análise mais recente da KPMG sobre governança de IA no Brasil, a governança de IA "deixa de ser um tema exclusivamente jurídico ou tecnológico e passa a exigir integração real entre jurídico, compliance, tecnologia, negócios, recursos humanos e comunicação" — exatamente o tipo de integração que compliance já sabe operar em outros riscos.

Se sua empresa ainda não tem a base de governança montada — política de uso, papéis, revisão humana —, comece por ali: veja o passo a passo em governança de IA na prática e no modelo de política de uso de IA na empresa. Este artigo assume essa base pronta e foca no que muda quando compliance formaliza o programa em cima dela.

O inventário de sistemas de IA: sem saber o que existe, não há compliance possível

O primeiro artefato de qualquer programa de compliance de IA — antes de política nova ou comitê — é o inventário: a lista viva de todo sistema de IA em uso, generativo ou não, comprado ou construído internamente, embutido em outro software ou usado via navegador. Sem esse inventário, nenhuma avaliação de risco é possível, porque compliance não sabe o que está avaliando.

Na prática, o inventário precisa registrar, por sistema:

1. Nome e fornecedor (ou "desenvolvimento interno").
2. Área e caso de uso — quem usa, para quê.
3. Tipo de dado processado — público, interno, confidencial, dado pessoal (a mesma classificação usada na política de uso de IA).
4. Nível de autonomia — a IA sugere, decide com revisão humana ou decide sozinha.
5. Impacto sobre pessoas — se a saída afeta decisão sobre cliente, colaborador ou terceiro (crédito, contratação, triagem, preço).
6. Status contratual — se há contrato de tratamento de dados e cláusulas de IA (seção mais adiante).

Levantar esse inventário quase sempre revela mais ferramentas do que a empresa imaginava — inclusive uso informal, o fenômeno que detalhamos em shadow AI. Ele nasce melhor do cruzamento entre TI (o que foi comprado), financeiro (o que está sendo pago) e uma pesquisa direta com as áreas — nenhuma das três fontes sozinha captura o quadro completo.

Avaliação de risco por caso de uso: nem toda aplicação de IA merece o mesmo controle

Com o inventário em mãos, o segundo passo é classificar risco — não da ferramenta em si, mas de cada caso de uso. A mesma ferramenta de IA generativa pode ser baixo risco num uso (resumir uma ata interna) e alto risco em outro (redigir uma cláusula contratual sem revisão). A lógica de classificação por risco é a mesma que estrutura o PL 2338/2023 e a ISO/IEC 42001 — detalhamos ambos os frameworks em riscos da IA generativa nas empresas e em ISO/IEC 42001; aqui o foco é como compliance opera essa classificação no dia a dia:

Nível de risco	Critério	Controle exigido
Baixo	Uso interno, sem dado pessoal, sem impacto sobre terceiros	Registro no inventário; sem aprovação prévia
Médio	Dado pessoal envolvido ou output usado externamente sem decisão automatizada	Revisão humana obrigatória; aprovação do gestor da área
Alto	Decisão automatizada que afeta pessoa (crédito, contratação, triagem, preço) ou dado sensível	Avaliação de impacto formal; aprovação do comitê; auditoria periódica

Essa tabela não substitui avaliação jurídica caso a caso — é o ponto de partida que prioriza onde compliance investe tempo de revisão. Cada avaliação de risco alto deve gerar um documento curto e datado: o que foi avaliado, quem avaliou, qual decisão foi tomada e por quê. É esse documento — não a política em si — que vira evidência numa auditoria.

Trilha de auditoria: a evidência que separa compliance de intenção

Uma política de uso bem escrita convence um leitor. Uma trilha de auditoria convence um auditor, um cliente em due diligence ou um regulador. A diferença é que a trilha prova, com data e responsável, que o processo declarado de fato aconteceu. Os quatro registros mínimos que todo programa de compliance de IA precisa manter:

1. Log de aprovação de ferramentas — quem aprovou cada sistema de IA no inventário, quando e com base em qual avaliação de risco.
2. Registro de avaliações de impacto — para todo caso de uso classificado como alto risco.
3. Registro de incidentes — todo uso indevido, vazamento ou reclamação envolvendo IA, independentemente de ter virado incidente formal de LGPD.
4. Evidência de treinamento — quem foi capacitado, quando e em qual conteúdo — a auditoria pergunta não só se existe regra, mas se quem usa a ferramenta sabe da regra.

Esse último ponto é o gap mais comum: política escrita e trilha de aprovação sem evidência de que o time foi treinado. É por isso que compliance de IA não pode ser só documento — precisa estar amarrado à capacitação real das equipes, o mesmo argumento de uso seguro de IA no trabalho. Este programa decide o quê auditar e com que prioridade; a execução técnica em si — viés, drift, explicabilidade, frequência e quem deve conduzir — está detalhada em auditoria de IA: guia técnico para C-level e compliance.

O papel do jurídico e do DPO dentro do programa

Compliance não substitui jurídico nem o encarregado de dados (DPO) — divide o trabalho com eles. Na prática de um programa maduro:

• Compliance é dono do processo: mantém o inventário, opera a classificação de risco, organiza a trilha de auditoria e reporta à diretoria.
• Jurídico valida enquadramento legal de casos-limite, revisa cláusulas contratuais com fornecedores de IA e responde por exposição em contencioso.
• DPO avalia especificamente os casos de uso que envolvem dado pessoal, garante que o direito à revisão humana previsto no art. 20 da LGPD seja cumprido na prática (não só no papel) e é o canal formal com a ANPD. O detalhamento completo das bases legais, do papel do DPO e das obrigações da LGPD aplicadas à IA generativa está em LGPD e IA generativa — não repetimos aqui.

Sem essa divisão explícita, cada decisão de risco vira debate ad hoc entre as três funções, sem dono final. O comitê de IA — já descrito no pilar governança de IA na prática, com composição e mandato detalhados em comitê de ética de IA: como estruturar na empresa — é o fórum que resolve casos-limite; compliance prepara o material para esse fórum decidir rápido.

Fornecedores de IA: o ponto cego da maioria dos programas de compliance

A due diligence de fornecedores é onde os programas de compliance de IA mais falham hoje — mesmo em empresas que já levam compliance a sério para outros riscos. Um estudo da Ethisphere com o programa SpeakUp, citado pela LEC, mostra o tamanho do gap: 77% das equipes de compliance já influenciam ou coordenam a governança de IA e 84% já são donas do processo de risco de fornecedores — mas apenas 14% auditaram fornecedores quanto às práticas de IA, e só 15% incluíram salvaguardas de IA nos códigos de conduta de terceiros. Do lado positivo, 57% já começaram a treinar colaboradores sobre uso de IA — a capacitação interna avança mais rápido que o controle sobre terceiros.

Na prática, a maioria das empresas tem due diligence de fornecedor madura para temas tradicionais (anticorrupção, trabalhista, ambiental) mas não estendeu esse rigor para "este fornecedor usa IA para processar nossos dados, sob quais controles?". Os quatro ajustes que fecham o gap: cláusula específica de IA no contrato (o que o fornecedor pode fazer com o dado, incluindo vedação a treinar modelo com ele sem autorização); questionário de due diligence de IA no onboarding de qualquer fornecedor que processe dado da empresa com apoio de IA, não só de fornecedores de IA "puros"; atualização do código de conduta de terceiros; e auditoria periódica, não só na assinatura do contrato — fornecedor pode adotar IA nova depois de contratado, sem aviso.

O detalhamento das cláusulas de tratamento de dados exigíveis de fornecedor de IA sob a LGPD — base legal, vedação a treinar modelo, notificação de incidente — está em LGPD e IA generativa; aqui o ponto é que due diligence de fornecedor de IA é, na maioria das empresas, o elo mais fraco do programa — por ser o mais fácil de deixar para depois.

Como reportar o programa de compliance de IA à diretoria

Diretoria e board não precisam ver o inventário linha a linha. O relatório que compliance leva ao board responde quatro perguntas, de forma objetiva:

1. Quantos sistemas de IA estão em uso, e quantos são de alto risco?
2. Quantos casos de uso de alto risco têm avaliação de impacto concluída? (cobertura do processo, não só existência dele)
3. Houve incidente no período, e o que mudou por causa dele?
4. Qual é o gap conhecido, e qual é o plano para fechá-lo? — reportar só o que está bem feito é o erro mais comum; o board precisa do risco residual, não de uma versão editada.

Um relatório trimestral com essas quatro respostas, em uma página, é mais útil à diretoria do que uma política de cinquenta páginas que ninguém vai ler no board — e é o tipo de evidência que uma auditoria externa ou um cliente em due diligence pede primeiro.

O cenário regulatório: LGPD, PL 2338 e o novo PL 6.237/2025

O programa de compliance de IA não espera a regulamentação específica para começar — a LGPD já se aplica integralmente a qualquer sistema de IA que processe dado pessoal, e o detalhamento completo dessa obrigação está em LGPD e IA generativa. O que muda é o pano de fundo regulatório em construção:

• PL 2338/2023 (Marco Legal da IA) segue em tramitação na Câmara dos Deputados após aprovação unânime no Senado em dezembro de 2024, conforme confirma o Jornal do Comércio em julho de 2026. O texto classifica sistemas de IA por nível de risco e prevê sanções de até 2% do faturamento bruto, limitadas a R$ 50 milhões por infração — a mesma lógica de risco que este guia usa para estruturar a avaliação de caso de uso.
• PL 6.237/2025 propõe a criação do Sistema Nacional de Regulação e do Comitê Brasileiro de IA (CBIA), segundo a KPMG — um órgão de coordenação regulatória que ainda não existe hoje.

A leitura prática: inventário, avaliação de risco por caso de uso e trilha de auditoria são exatamente a estrutura que qualquer uma dessas leis, quando sancionadas, vai exigir como prova de conformidade. Montar esse programa agora não é trabalho especulativo — é cumprir a LGPD, que já vale hoje, e construir a base que o Marco Legal da IA vai cobrar quando entrar em vigor. Para quem quer um framework estruturado e auditável em vez de montar do zero, a ISO/IEC 42001 cobre essa mesma lógica com o rigor de uma norma internacional de sistema de gestão.

Checklist prático: por onde começar um programa de compliance de IA

Para quem está começando do zero, a ordem importa mais do que a completude:

1. Levante o inventário de todos os sistemas de IA em uso, incluindo uso informal.
2. Classifique cada caso de uso por nível de risco (baixo, médio, alto).
3. Defina quem aprova cada nível — e documente a decisão, não só a regra.
4. Monte a trilha de auditoria mínima: aprovações, avaliações de impacto, incidentes, treinamento.
5. Divida papéis entre compliance, jurídico e DPO por escrito — não deixe implícito.
6. Revise contratos com fornecedores de IA e inclua cláusula específica de IA nos novos.
7. Estenda o código de conduta de terceiros para cobrir uso de IA por fornecedores.
8. Defina o relatório trimestral ao board: sistemas em uso, cobertura de avaliação, incidentes, gaps.
9. Amarre o programa à capacitação real das equipes — regra sem treinamento não é evidência de nada numa auditoria.
10. Revise o programa a cada trimestre, ou imediatamente após qualquer mudança regulatória relevante (PL 2338, PL 6.237 ou norma setorial).

Como a Jetpacks apoia o programa de compliance de IA

Dentro do método Flight Plan, compliance entra como parte do desenho, não como camada adicionada depois. O Launchpad já inclui o inventário de sistemas de IA e o mapeamento de risco por área; o Flight Plan desenha, por área, os controles e o processo de aprovação proporcionais ao risco; o Booster capacita o time com as regras de compliance embutidas na própria capacitação — não em treinamento jurídico separado que ninguém conecta ao uso real; e o Mission Control entrega o tipo de evidência que este guia descreve: métricas de adoção e de cobertura que compliance leva direto ao board. Como parceira oficial da Replit no Brasil, a Jetpacks já aplicou essa abordagem em empresas como Hypera Pharma, Volvo, BMR Medical e C12 Brasil.

FAQ

O que é compliance de IA?

É o programa formal — inventário de sistemas, avaliação de risco por caso de uso, trilha de auditoria e papéis definidos entre compliance, jurídico e DPO — que garante, com evidência, que o uso de IA na empresa segue a política definida e resiste a uma auditoria externa.

Qual a diferença entre governança de IA e compliance de IA?

Governança de IA é o conjunto mais amplo de regras, papéis e processos que orienta como a empresa adota e usa IA. Compliance de IA é a camada que produz evidência formal — inventário, avaliação de risco documentada, trilha de auditoria — de que essas regras são seguidas na prática, não só descritas.

Quem deve liderar o programa de compliance de IA: jurídico, compliance ou TI?

Compliance é dono do processo (inventário, classificação de risco, trilha de auditoria, reporte ao board); jurídico valida enquadramento legal e cláusulas contratuais; TI dá visibilidade técnica sobre os sistemas em uso. Nenhuma função sozinha cobre o programa completo.

O que deve conter o inventário de sistemas de IA?

Nome e fornecedor de cada sistema, área e caso de uso, tipo de dado processado, nível de autonomia (sugestão, decisão com revisão humana, decisão automática), impacto sobre pessoas e status contratual — incluindo se existe cláusula específica de IA.

Como avaliar o risco de um caso de uso de IA?

Pelo tipo de dado envolvido e pelo impacto sobre pessoas: uso interno sem dado pessoal é baixo risco; uso com dado pessoal ou output externo é risco médio; decisão automatizada que afeta cliente, colaborador ou terceiro (crédito, contratação, triagem, preço) é alto risco e exige avaliação de impacto formal.

O que auditar num programa de compliance de IA?

No mínimo quatro registros: log de aprovação de cada sistema de IA, avaliações de impacto para casos de alto risco, registro de incidentes e evidência de que as equipes foram treinadas nas regras — não só de que a política existe.

O PL 2338 (Marco Legal da IA) já exige um programa de compliance de IA?

Ainda não é lei em vigor — segue em tramitação na Câmara dos Deputados após aprovação no Senado em dezembro de 2024. Mas a LGPD já exige conformidade hoje para qualquer sistema de IA que processe dado pessoal, e a estrutura de inventário, risco e auditoria deste guia é a mesma que o Marco Legal da IA deve cobrar como prova de conformidade quando for sancionado.

Conclusão: compliance transforma governança declarada em governança provada

Uma política de uso de IA diz o que a empresa pretende fazer. Um programa de compliance prova que a empresa está fazendo. A diferença aparece exatamente no momento em que mais importa: numa auditoria, numa due diligence de cliente ou investidor, ou na primeira exigência de um regulador — inventário de sistemas, avaliação de risco documentada por caso de uso e trilha de auditoria são o que a empresa apresenta nesse momento, não a intenção declarada num documento.

Se sua empresa já tem governança de IA no papel e precisa transformá-la num programa de compliance auditável — com jurídico, compliance e DPO operando com papéis claros —, o diagnóstico gratuito da Jetpacks mapeia o inventário de sistemas em uso e o nível de maturidade atual em uma conversa de 30 a 45 minutos, e o método Flight Plan desenha o programa junto com a capacitação que faz as regras saírem do papel. Se o programa de compliance ainda não tem a arquitetura de funções e papéis que sustenta essa evidência, veja framework de governança de IA: guia de implementação.