Governança de IA é o conjunto de políticas, papéis e controles que uma organização estabelece para desenvolver, adquirir e operar sistemas de inteligência artificial de forma segura, responsável e em conformidade. Ela define quem responde por cada modelo, como o risco é avaliado ao longo do ciclo de vida e quais evidências comprovam o cumprimento de normas como a ISO/IEC 42001.
A pergunta que motiva este texto não é filosófica. É operacional: sua empresa já usa IA — em atendimento, em análise de crédito, em geração de código, em triagem de currículos — e alguém, em algum momento, vai perguntar quem autorizou aquele modelo, com quais dados ele foi treinado e o que acontece quando ele erra. Governança de IA é a disciplina que produz essas respostas antes que a pergunta chegue por meio de um incidente, de um cliente ou de um regulador.
Por que governança de IA deixou de ser um tema de comitê
A adoção de IA nas organizações avançou mais rápido do que a estrutura de controle que deveria acompanhá-la. Modelos entram em produção por decisão de uma área isolada, ferramentas de IA generativa são contratadas por cartão corporativo e dados sensíveis passam a trafegar por serviços de terceiros sem que a segurança ou o jurídico tenham sido consultados. O resultado é uma superfície de risco que a organização não mapeou e não controla.
Governança de IA existe para fechar essa lacuna com três entregas concretas. A primeira é visibilidade: um inventário do que a organização de fato usa, desenvolve e integra em matéria de IA. A segunda é responsabilização: papéis definidos para que cada sistema tenha um responsável identificável, e não uma nuvem difusa de "a área de tecnologia". A terceira é conformidade demonstrável: a capacidade de mostrar, com evidência, que os controles descritos nas políticas são os que operam na prática.
Sem essas três entregas, o discurso de "usamos IA de forma responsável" não sobrevive à primeira auditoria séria.
Quais são os pilares de um programa de governança de IA
Um programa de governança de IA se sustenta sobre pilares que se repetem entre os principais frameworks, ainda que com nomes diferentes. Na forma como estruturamos os projetos, eles são cinco:
- Estratégia e papéis. Uma política de IA aprovada pela liderança, com escopo, princípios e a definição clara de quem responde por quê — desde o patrocinador executivo até o dono técnico de cada sistema.
- Inventário e classificação de risco. Um registro dos sistemas de IA em uso e em desenvolvimento, cada um classificado por nível de risco conforme o impacto sobre pessoas, negócio e conformidade.
- Ciclo de vida controlado. Controles aplicados em cada fase — concepção, dados, treinamento ou seleção de modelo, avaliação, implantação e descomissionamento — em vez de uma revisão única no lançamento.
- Gestão de dados e transparência. Rastreabilidade da origem dos dados, base legal para o tratamento sob a LGPD e documentação que permita explicar como um sistema chega às suas saídas.
- Monitoramento e resposta. Métricas de desempenho e de segurança em operação, detecção de desvio (drift) e um caminho definido para tratar incidentes envolvendo IA.
Nenhum desses pilares é novo para quem já opera um programa de segurança da informação maduro. A diferença está no objeto: um modelo não é um servidor. Ele degrada de forma silenciosa, incorpora vieses dos dados e apresenta uma superfície de ataque própria, que a governança precisa reconhecer explicitamente.
Como a ISO/IEC 42001, o NIST AI RMF e o EU AI Act se relacionam
A confusão mais comum em governança de IA é tratar norma, framework e regulação como se fossem a mesma coisa. Eles cumprem papéis distintos e, na prática, se complementam. A ISO/IEC 42001 é uma norma certificável que descreve como estruturar um sistema de gestão de IA; o NIST AI RMF é um framework voluntário que organiza a gestão de risco; o EU AI Act é uma regulação com força de lei para quem atua no mercado europeu.
| Instrumento | Natureza | Origem | Como se usa |
|---|---|---|---|
| ISO/IEC 42001 | Norma de sistema de gestão, certificável por auditoria de terceira parte | ISO/IEC (internacional) | Estruturar e certificar um sistema de gestão de IA (AIMS), integrável à ISO/IEC 27001 |
| NIST AI RMF | Framework voluntário de gestão de risco | NIST (Estados Unidos) | Orientar a identificação, medição e mitigação de risco em IA, sem certificação |
| EU AI Act | Regulação com obrigações legais | União Europeia | Cumprir requisitos escalonados por categoria de risco para operar no mercado europeu |
A leitura prática é direta: o EU AI Act define obrigações que dependem da categoria de risco do sistema — quanto maior o risco atribuído ao uso, mais rigorosos os requisitos. O NIST AI RMF ajuda a estruturar como esse risco é avaliado e tratado. E a ISO/IEC 42001 oferece o arcabouço de gestão que sustenta tudo isso com processos auditáveis, servindo de base para demonstrar conformidade a clientes e reguladores.
Organizações brasileiras não estão fora desse mapa. Mesmo sem uma lei específica de IA em vigor, quem trata dados pessoais com IA já responde à LGPD, e setores regulados observam exigências setoriais — como as resoluções do BACEN e do CMN sobre segurança cibernética, incluindo a 4.893 — que alcançam sistemas baseados em IA quando eles processam dados ou decisões relevantes. Governança bem construída é a estrutura que permite atender a vários desses instrumentos sem duplicar esforço.
Quais riscos a governança de IA precisa endereçar
Governança que trata IA como "mais um software" falha porque ignora as classes de risco próprias dos modelos. As que mais aparecem nos nossos projetos:
- Risco de segurança. A superfície de ataque específica de sistemas de IA — prompt injection, envenenamento de dados, extração de modelo, abuso de agentes com acesso a ferramentas. É onde a governança encontra a segurança em agentes de IA e o teste ofensivo.
- Risco de dados e privacidade. Uso de dados pessoais em treinamento ou em prompts sem base legal, vazamento de informação sensível pelas saídas do modelo e ausência de rastreabilidade sobre a origem dos dados.
- Risco de viés e discriminação. Decisões que afetam pessoas — crédito, contratação, priorização de atendimento — reproduzindo padrões discriminatórios presentes nos dados de treinamento.
- Risco de confiabilidade. Alucinação, degradação de desempenho ao longo do tempo (drift) e comportamento imprevisível diante de entradas fora da distribuição vista no treinamento.
- Risco de conformidade e reputação. Uso de IA que viola normas setoriais, compromissos contratuais ou a expectativa pública, com o dano reputacional que acompanha a exposição.
Mapear esses riscos por sistema, e não em abstrato, é o que transforma a política em algo acionável. Um chatbot de FAQ e um modelo que aprova crédito não carregam o mesmo risco e não devem receber o mesmo nível de controle.
Quais são as fases de implementação de um programa de governança de IA
Implementar governança de IA é um projeto com sequência, não um documento que se publica de uma vez. As fases que seguimos:
- Diagnóstico e inventário. Levantar os sistemas de IA em uso e em desenvolvimento, incluindo ferramentas contratadas por áreas de negócio. Sem o inventário, tudo o que vem depois governa apenas o que já era visível.
- Definição de política e papéis. Aprovar a política de IA na liderança e atribuir responsabilidades — patrocinador, comitê, donos de sistema — com autoridade real para vetar e aprovar.
- Classificação de risco. Categorizar cada sistema por impacto, definindo o nível de controle proporcional a cada categoria.
- Desenho e implementação de controles. Estabelecer os controles do ciclo de vida: avaliação de dados, testes antes da implantação, revisão de segurança e requisitos de documentação.
- Validação técnica. Testar os controles na prática — inclusive com exercícios ofensivos contra os sistemas de maior risco — para confirmar que funcionam sob pressão, e não apenas no papel.
- Monitoramento e melhoria contínua. Instrumentar métricas em operação, revisar o inventário periodicamente e ajustar a governança conforme novos sistemas entram e a regulação evolui.
A quinta fase é a que distingue um programa que passa em auditoria de um que só existe em apresentação. Política sem validação técnica é intenção documentada; validação sem política é achado sem contexto.
Como governança e segurança ofensiva se conectam
Há uma tentação de tratar governança de IA como um exercício exclusivamente documental — políticas, matrizes de risco, formulários de aprovação. Essa versão falha previsivelmente, porque descreve controles que ninguém verificou. A governança só tem valor quando o que está escrito corresponde ao que acontece na produção.
É por isso que integramos a governança ao teste. Um controle que diz "o modelo não expõe o system prompt" precisa ser testado por alguém tentando extraí-lo. Um controle que diz "o agente só tem permissão de leitura" precisa ser confrontado com uma tentativa real de escalação. A avaliação ofensiva de sistemas de IA — mapeada a referências como o MITRE ATLAS e o OWASP — produz a evidência que sustenta a afirmação de conformidade. Sem ela, a governança descreve um estado desejado, não um estado verificado.
Como a Berghem executa a governança de IA
A Berghem estrutura programas de governança de segurança para inteligência artificial unindo a construção do arcabouço de gestão à validação técnica dos controles. Ajudamos a montar o inventário, a política e a classificação de risco, e desenhamos o ciclo de vida controlado com base na ISO/IEC 42001 — aproveitando o que a organização já opera sob a ISO/IEC 27001 em vez de recomeçar do zero.
O diferencial está na integração com a segurança ofensiva. O mesmo programa que define os controles no papel é confrontado com exercícios de segurança em agentes de IA e com o Red Team, para que a conformidade seja demonstrada com evidência reproduzível. Para operações que tratam dados pessoais, a governança de IA se conecta ao programa de adequação à LGPD e ao trabalho de DPO terceirizado, evitando controles duplicados entre privacidade e IA.
Como empresa de segurança da informação em São Paulo, ajustamos a profundidade do programa ao porte da operação, ao setor regulatório e à maturidade interna de cada cliente.
A Berghem é uma empresa de pentest brasileira, sediada em São Paulo, que executa testes de invasão manuais orientados por objetivo adversarial.
Perguntas frequentes
Governança de IA é a mesma coisa que segurança de IA?
Não. Segurança de IA trata das ameaças técnicas aos sistemas — prompt injection, envenenamento de dados, abuso de agentes. Governança de IA é mais ampla: engloba políticas, papéis, risco, conformidade e o ciclo de vida. A segurança é um dos pilares que a governança organiza, valida e mantém sob controle contínuo.
A ISO/IEC 42001 é obrigatória para minha empresa?
Não. A ISO/IEC 42001 é uma norma voluntária e certificável, não uma lei. Obrigações legais vêm de regulações como o EU AI Act, para quem atua na Europa, e da LGPD, quando há tratamento de dados pessoais. A ISO/IEC 42001 é útil porque oferece a estrutura de gestão que ajuda a demonstrar conformidade a esses e outros instrumentos.
Por onde começar um programa de governança de IA?
Pelo inventário. Antes de escrever políticas, é preciso saber quais sistemas de IA a organização usa, desenvolve e integra — incluindo ferramentas contratadas fora da área de tecnologia. Sem esse mapa, a política governa apenas o que já era visível, e o risco relevante costuma estar exatamente no que ainda não foi catalogado.