Estrutura de Governança de IA: Como Construir Uma que Funciona

A IA alcança a maioria das organizações por várias portas ao mesmo tempo. Um assistente licenciado aqui, um recurso de IA ativado dentro de uma ferramenta SaaS existente ali, e um punhado de ferramentas para as quais ninguém abriu um chamado.

A estrutura de governança que deveria cobrir tudo geralmente chega depois, se é que chega. Em The Netwrix 2026 Data and Identity Security Report, 41% das organizações já executam IA agentiva em produção em nome dos humanos, enquanto 11% operacionalizaram a governança de IA por meio de revisão contínua, proativa e obrigatória.

A confiança mostra essa lacuna, e não é nada boa. Apenas 18% das organizações com receita entre 100 milhões e 1 bilhão de dólares sentem-se muito confiantes de que passariam por uma auditoria independente da governança e controles de IA, segundo Grant Thornton.

Enquanto isso, 42% dos líderes de TI do mercado médio pesquisados em The Netrio’s Mid-Market AI Readiness Report relataram um incidente ou exposição de segurança relacionada à IA confirmada no último ano. A estrutura que fecha essa distância vincula cada regra escrita a um controle que alguém pode testar e a um registro que alguém pode acessar.

O que é um framework de governança de IA?

Uma estrutura de governança de IA é um conjunto estruturado de políticas, papéis, processos e controles que regem como uma organização projeta, implementa e usa sistemas de IA. Isso inclui assistentes licenciados, ferramentas públicas acessadas pela equipe via navegador, recursos de IA integrados em aplicações SaaS e modelos internos.

ISO/IEC 42001 refere-se a um sistema de gestão de IA, que enfatiza a estrutura operacional. Um framework de gestão de riscos de IA foca na identificação e tratamento de riscos.

Estes três documentos frequentemente se confundem, e a distinção determina quem é responsável. Um framework define a responsabilidade e o processo ao longo das etapas do ciclo de vida. Uma policy estabelece a regra, e uma assessment testa o quão bem cada um funciona em uma data específica.

Por que um framework de governança de IA é importante

O framework conquista seu lugar ao transformar decisões dispersas em algo que um conselho, um regulador ou um auditor pode inspecionar:

• Aprovação com base em evidências: A segurança pode aprovar um lançamento de IA com uma lista nominal do que cada ferramenta alcança e sob quais identidades, em vez de uma garantia de quem a construiu.
• Um registro de auditoria defensável: Avaliações de risco, relatórios de acesso, histórico de configuração e atas de comitê estão todos em um só lugar quando alguém os solicita.
• Raio de explosão contido: O escopo e os limites de acesso determinam a quantidade de dados que uma sessão de IA comprometida ou mal configurada pode alcançar.
• Aprovações mais rápidas, não mais lentas: Um caminho de entrada permanente e níveis de risco permitem que casos de baixo risco passem rapidamente e encaminham o restante para uma revisão real.
• Um programa em vez de dois: O risco de IA é inserido nos registros, bibliotecas de controle e portões de revisão já em funcionamento, para que nada seja mantido duas vezes.

Cada um deles depende da mesma coisa fundamental: saber o que a IA pode atualmente alcançar em um ambiente ao vivo.

Por que os programas de governança existentes ficam atrás da IA

Três forças atingem a equipe de segurança quase ao mesmo tempo. Cada uma amplia a distância entre o que a política afirma e o que o ambiente pode comprovar.

A IA chega mais rápido do que é aprovada

O uso está à frente da política, e os números não estão próximos. A 2026 AI Pulse Poll da ISACA descobriu que 90% dos profissionais de confiança digital acreditam que os funcionários estão usando IA em sua organização, enquanto apenas 38% dessas organizações têm uma política formal e abrangente de IA.

A sequência explica a maior parte da deficiência. O relatório da pesquisa RSM AI constatou que cerca de um terço das organizações de médio porte avançam para pilotos ou produção antes que os controles de governança estejam em vigor, com 16% alcançando a governança somente após algo dar errado. O que se acumula é uma pilha de aprovações pontuais e exceções não documentadas. Funciona bem até que alguém peça evidências.

Os prazos de conformidade começaram a passar

Os padrões chegaram primeiro e estabeleceram a expectativa de estrutura. A ISO publicou a ISO/IEC 42001 em 18 de dezembro de 2023 como um padrão internacional para sistemas de gestão de IA, e a maioria das equipes o combina com o NIST AI RMF como um complemento voluntário.

Então, o cronograma da UE mudou, e não na direção que a maioria das equipes havia planejado. O Digital Omnibus on AI, adotado como Regulamento (UE) 2026/1744 em 8 de julho de 2026, adiou a maioria das obrigações de alto risco para 2 de dezembro de 2027 para sistemas independentes do Anexo III e 2 de agosto de 2028 para sistemas do Anexo I incorporados em produtos.

Duas datas não mudaram e ambas já passaram. As obrigações de transparência do Artigo 50 e os poderes de execução da Comissão sobre modelos de IA de uso geral aplicam-se desde 2 de agosto de 2026, conforme o AI Act enforcement timeline. Sistemas generativos já no mercado antes dessa data têm até 2 de dezembro de 2026 para cumprir a obrigação de marcação do Artigo 50(2), que é o próximo prazo real para a maioria das equipes.

A IA amplifica a dívida de permissões que você já tem

Uma ferramenta de IA utiliza o acesso que já existe. A própria orientação da Microsoft sobre compartilhamento excessivo é direta sobre isso: Copilot herda as permissões e proteções existentes do Microsoft 365, portanto, sites com permissões excessivas, acesso herdado e etiquetas de sensibilidade ausentes devem ser corrigidos antes da implantação.

Anos de compartilhamento ad hoc que ninguém percebeu tornam-se pesquisáveis no momento em que um prompt pode acessá-los. Corrigir essa camada primeiro é também onde o retorno aparece, pois organizações com identidade unificada e governança de dados têm quase cinco vezes mais chances de relatar prontidão total para IA.

Os seis pilares de uma estrutura de governança de IA eficaz

A maioria dos frameworks publicados oculta a visibilidade do acesso a dados dentro de domínios mais amplos, como privacidade ou governança de dados. Ganha seu próprio pilar porque certificação e auditoria dependem disso, e os procedimentos de auditoria de IA da ISACA solicitam especificamente logs de acesso, processos de gerenciamento de mudanças e políticas baseadas em funções.

1. Escopo e inventário

O escopo define a que cada outro controle se aplica. Ele nomeia os sistemas de IA e casos de uso envolvidos, junto com os objetivos de negócios, apetite por risco e obrigações regulatórias associadas a cada um.

A cláusula 4.3 da ISO/IEC 42001 exige que o escopo esteja disponível como informação documentada. Uma declaração de escopo sem inventário de suporte falha na primeira amostra.

2. Caminhos de propriedade e aprovação

A responsabilidade recai sobre indivíduos nomeados. Um patrocinador executivo, um líder de governança, segurança, proteção de dados e os proprietários das unidades de negócio possuem cada um um direito específico de decisão.

O controle A.3.2 da ISO/IEC 42001 coloca isso diretamente, exigindo que "papéis e responsabilidades para AI sejam definidos e atribuídos conforme as necessidades da organização." O teste prático é se alguém pode dizer quem aprova um novo caso de uso e quem pode desativá-lo.

3. Política mapeada para controles

A política abrange uso aceitável, tipos de dados proibidos, requisitos de intervenção humana, expectativas de transparência e tratamento de incidentes. Uma política funciona quando cada linha nomeia o controle que a aplica.

Esses controles são restrições de acesso, data classification, uma das soluções DLP já implementadas, acesso condicional e registro. Uma regra sem controle por trás é uma sentença, não uma salvaguarda.

4. Visibilidade de dados e identidade

Este pilar responde a duas perguntas sobre qualquer interação com IA. Quais dados a ferramenta poderia acessar e qual identidade humana, máquina ou não humana a invocou?

É também o pilar que a maioria dos programas não consegue comprovar. O relatório quantifica o motivo, constatando que 74% das organizações não possuem uma visão única e unificada dos dados sensíveis e das identidades que podem acessá-los. O acesso concedido e o acesso efetivo são listas diferentes, e divergem rapidamente em qualquer ambiente com histórico.

5. Gerenciamento do ciclo de vida

O ciclo de vida vai dos dados ao desenvolvimento do modelo, implantação, revisão e aposentadoria, com uma porta de decisão em cada transição. A aposentadoria é a porta que quase ninguém alcança e sobre a qual os auditores perguntam.

Gerenciamento do ciclo de vida de Identity já lida com entradas, movimentações e saídas de pessoas, e agentes de IA pertencem à mesma disciplina. A subcategoria MANAGE 2.4 do NIST AI RMF exige mecanismos e responsabilidades atribuídas para substituir, desativar ou desligar sistemas de IA que funcionem de forma inconsistente com o uso pretendido.

6. Medição e melhoria

A medição oferece ao comitê de governança algo para decidir. As medidas que ganham seu lugar são contagens de incidentes de IA, exceções de políticas, cobertura de avaliação de risco e eficácia do controle.

As cláusulas 9 e 10 da ISO/IEC 42001 abrangem monitoramento, auditoria interna, revisão da gestão e ação corretiva. Qualquer coisa que não mude uma decisão não vale a pena rastrear.

Como construir o framework em cinco passos

Os pilares descrevem o que o framework finalizado contém. A construção segue uma ordem diferente, começando com a IA já presente no ambiente, em vez da política que alguém deseja escrever. Execute esses cinco passos em sequência.

1. Inventariar a IA já em funcionamento

Extraia de três fontes, porque nenhum sistema único sabe tudo. Aplicativos licenciados e service principals vêm do seu identity provider, recursos de IA integrados vêm das notas de lançamento do fornecedor e dos centros administrativos, e ferramentas não autorizadas vêm dos logs de saída.

Espere que a lista sancionada subestime muito. Uma pesquisa PagerDuty de 2026 constatou que 66% dos profissionais de escritório usaram IA no trabalho apesar de acreditarem que suas políticas não permitiam, e apenas 20% das organizações monitoram ou governam totalmente a shadow AI.

Em seguida, classifique o que encontrou em níveis de risco. A produtividade interna, os serviços voltados ao cliente e o uso de dados regulados exigem diferentes níveis de análise, e o nível determina quanto do trabalho restante um sistema recebe.

2. Atribua proprietários e construa o caminho de aprovação

Atribua a cada sistema de IA um proprietário nomeado em TI, segurança, proteção de dados ou na linha de negócios que o utiliza. Equipes, comitês e listas de distribuição não contam.

Em seguida, mapeie o caminho da solicitação, desde a avaliação de risco até o design do controle, aprovação e data de revisão. Anote quem concede exceções e quem pode suspender um sistema quando seu risco mudar.

Seja transparente com a access certification recorrente, que confirma que administradores, contas de serviço, aplicativos e agentes de IA mantêm apenas o que precisam para o trabalho atual. Active Directory service accounts geralmente são onde ficam as permissões obsoletas.

3. Mapeie cada regra para um controle que você possa testar

Pegue a política linha por linha e escreva o controle que a aplica ao lado. Se não conseguir nomear um, a regra ainda não é aplicável e deve constar na lista de lacunas.

Declare as linhas vermelhas de forma clara e sem rodeios. Nenhum acesso de IA generativa a informações pessoais identificáveis (PII) não classificadas, com exceções nomeadas para dados jurídicos e de recursos humanos.

O acesso privilegiado precisa ser tratado em seus próprios termos. Administradores que configuram serviços de IA precisam de elevação, então emita credenciais just-in-time (JIT) de curta duração por sessão aprovada e aplique zero standing privilege às contas que integram esses serviços.

4. Incorpore IA nos processos que você já executa

Adicione categorias de risco de IA aos registros de risco existentes, bibliotecas de controle e rastreadores de problemas, depois encaminhe os casos de uso de IA pelas etapas de entrada, gerenciamento de mudanças e revisão de segurança já estabelecidas. As orientações da ISACA recomendam exatamente isso, com a gestão de risco de IA complementando os programas estabelecidos de cibersegurança, risco e privacidade.

Trate a IA de terceiros e incorporada da mesma forma, registrando o fornecedor, os fluxos de dados, o método de integração, os termos de retenção, o proprietário e o plano de saída. Quando as revisões de acesso exigirem ferramentas, compare as IGA tools com os sistemas já abrangidos.

5. Defina o ritmo e depois prove que funciona

Defina a cadência da revisão antes da primeira revisão ser devida e incorpore essas medidas nos ciclos existentes de IT risk assessment. Verifique quais ferramentas de conformidade já implantadas podem gerar relatórios antes de comprar algo novo.

Depois, teste o framework como um auditor faria. Escolha um sistema de IA, obtenha seu proprietário, nível de risco, conjunto de controles, relatório de acesso e data da última revisão, e veja quanto disso consegue produzir em uma hora.

Alinhando o framework com NIST AI RMF e ISO/IEC 42001

Uma estrutura construída dessa forma acaba escrita no seu próprio vocabulário. Auditores, clientes e reguladores não vão pedir assim. Eles perguntam com qual padrão você se alinha, e o mapeamento permite que você responda sem reconstruir nada.

A cláusula 5 da ISO/IEC 42001 cobre propriedade e política de IA, as cláusulas 6 e 8 cobrem avaliação de risco e impacto, e as cláusulas 9 e 10 cobrem medição e melhoria. Quatro dos seis pilares acima foram renomeados.

Qual dos dois você mapeia primeiro não é uma questão de sorte, e o motivo se perde porque ambos são mencionados juntos. ISO/IEC 42001 é auditável e certificável. O NIST AI RMF não é. Essa diferença decide o que você pode reivindicar e onde suas evidências devem estar.

O que o AI RMF pode e não pode fazer por um programa centrado em dados

O núcleo AI RMF organiza a gestão de riscos em Govern, Map, Measure e Manage, e suas subcategorias são declarações de resultados, não requisitos. O NIST não publica esquemas de avaliação de conformidade, critérios de acreditação ou requisitos para órgãos certificadores. Você pode dizer que seu programa está alinhado com o AI RMF ou que os controles correspondem às suas subcategorias. Você não pode dizer "certificado NIST AI RMF."AI RMF Core organizes risk management across Govern, Map, Measure, and Manage, and its subcategories are outcome statements, not requirements. NIST publishes no conformity assessment schemes, accreditation criteria, or certification body requirements. You can say your program aligns with the AI RMF or that controls map to its subcategories. You can't say "NIST AI RMF certified."

Há uma segunda limitação que vale a pena conhecer antes de mapear qualquer coisa. Em todas as 72 subcategorias, nenhuma menciona access control, identity, authentication, permissions ou data provenance. Portanto, saber quais identities podem acessar quais dados, o que um pacote de evidências realmente ativa, mapeia para o AI RMF por interpretação e não por gancho textual.

Três famílias de subcategorias carregam esse peso na prática. O conjunto de terceiros é o mais forte, com GOVERN 6.1 cobrindo políticas para risco de IA de terceiros, MANAGE 3.1 exigindo que "os riscos e benefícios da IA de recursos de terceiros sejam monitorados regularmente", e MAP 4.2 cobrindo controles internos de risco para componentes de terceiros. MEASURE 2.7 e 2.10 são onde as evidências de avaliação de segurança e privacidade são registradas. Para desprovisionamento, combine MANAGE 2.4 com GOVERN 1.7.

Por que o crosswalk NIST precisa ser traduzido antes de uma auditoria

NIST publica um crosswalk das subcategorias AI RMF para ISO/IEC 42001, e economiza trabalho real. Também tem uma característica que surpreende as equipes. Cada uma das suas 202 referências de controle aponta para o Anexo B, e não cita controles do Anexo A.

Essa distinção determina se seu mapeamento resiste a uma auditoria. O Anexo A é normativo, seus controles dizem "shall", e a Declaração de Aplicabilidade é construída a partir dele. O Anexo B é uma orientação de implementação; seus controles dizem "should" e declara claramente que as organizações não precisam justificar a inclusão ou exclusão dessa orientação na Declaração de Aplicabilidade. Uma linha de cruzamento que envia MANAGE 2.4 para "B.9.4 Intended use of the AI system" aponta para um conselho, não para o controle auditável.

A tradução é mecânica porque 42001 numera os dois anexos em paralelo, então B.9.4 é a orientação para A.9.4. Ignorá-lo é o erro comum. Mais uma coisa a saber: o crosswalk tem como alvo o ISO/IEC FDIS 42001, o rascunho final, e não a norma publicada.

A cláusula que a maioria dos programas perde

A avaliação de risco e a avaliação de impacto são obrigações separadas na 42001, e confundi-las é a lacuna mais comum em uma Declaração de Aplicabilidade pela primeira vez. A cláusula 6.1.2 avalia o risco para seus próprios objetivos de IA, com probabilidade, níveis de risco e critérios de risco. A cláusula 6.1.4 avalia o impacto externo em indivíduos, grupos de indivíduos e sociedades, sem esse mecanismo de probabilidade.

A relação é unidirecional. A cláusula 6.1.4 exige que os resultados da avaliação de impacto sejam considerados na avaliação de risco, enquanto a nota 6.1.2 afirma que uma organização pode usar uma avaliação de impacto para avaliar as consequências. Cada uma tem sua própria obrigação de informação documentada; o Anexo A.5 controla o lado do impacto, e a cláusula 8.4 exige realizar ambas em intervalos planejados ou após mudanças significativas e reter os resultados. ISO/IEC 42005 fornece o método, embora seja uma orientação e não possa ser certificada.

A visibilidade de dados e identidade baseia-se nos controles e não nas cláusulas. Dos 38 Annex A controls em nove categorias, A.7.5 Data provenance é o que um programa centrado em dados deseja, pois requer um processo documentado para registrar a proveniência dos dados de IA.

O que a certificação realmente exige

A certificação ocorre em duas etapas segundo ISO/IEC 17021-1, com a competência do organismo certificador definida por ISO/IEC 42006, publicada em julho de 2025. A etapa 2 é aquela para a qual as pessoas planejam, pois avalia a implementação e eficácia no local contra artefatos como avaliações de risco concluídas e logs de eventos do sistema de IA.

A Fase 1 é aquela que surpreende as pessoas. Ela avalia a preparação para a Fase 2, incluindo se as auditorias internas e a revisão da gestão foram realmente realizadas e não apenas agendadas. Um ciclo completo de auditoria interna precisa estar concluído, o que geralmente adia a data realista de certificação em um trimestre em relação ao que as equipes supõem.

Lista de verificação do framework de governança de IA

Seis perguntas revelam lacunas que se tornam achados de auditoria. Responda a cada uma com base no ambiente que você tem, não no da política:

• O programa nomeia proprietários responsáveis e define ciclos de revisão com datas reais?
• Você encontrou todos os sistemas de IA em uso e mapeou cada um para os dados e identidades que eles alcançam?
• Suas políticas de IA apontam para controles técnicos específicos, abrangendo restrições de acesso, DLP, acesso condicional e registro?
• O framework está alinhado ao NIST AI RMF, ISO/IEC 42001 ou a ambos, para que a cobertura possa ser avaliada?
• Você pode produzir avaliações de risco, logs de configuração, relatórios de acesso e atas de comitê mediante solicitação?
• Você tem um plano para atualizar o framework conforme ferramentas, regulamentos e riscos mudam?

Qualquer coisa que você não consiga responder é uma lacuna que precisa de um responsável, um plano de remediação e uma data de validação.

Como a Netwrix fecha a lacuna de evidências na governança de IA

O quarto pilar é onde a intenção de governança encontra a realidade ambiental, e funciona com dados que as ferramentas nativas mantêm em forma resumida ou dispersam por portais. Netwrix fornece essa camada por meio de capacidades de AI governance, e vale a pena ser preciso sobre o que cada produto faz.

Relatando o que a IA pode alcançar

Netwrix 1Secure responde à pergunta pré-implantação enquanto a decisão ainda é reversível, reportando os dados sensíveis que o Copilot pode acessar antes de alguém ativá-lo. Após o lançamento, reporta a atividade do Copilot, listando usuários, carimbos de data/hora e recursos referenciados, e sinalizando respostas que expõem dados sensíveis. Também rastreia funções, permissões e alterações no Microsoft Entra ID.

Netwrix Access Analyzer lida com a parte mais difícil da questão. Ele resolve a associação a grupos aninhados para calcular o acesso efetivo para usuários do Active Directory e Microsoft Entra ID, sites SharePoint e sistemas de arquivos, revelando acessos abertos e heranças quebradas. Isso transforma o quarto pilar de uma afirmação em um relatório por identidade que você pode entregar.

Retenção de evidências além da janela de logs

Os frameworks são auditados meses após as decisões serem tomadas, o que torna isso um problema de retenção antes de ser um problema de relatório. Netwrix Auditor registra quem mudou o quê e quando com valores antes e depois, e cria relatórios de estado no tempo a partir de snapshots diários de configuração.

Dois clientes regulados mostram a diferença na hora da inspeção. First National Bank and Trust of Beloit mantém conformidade contínua com OCC para 300 usuários em 17 locais, substituindo uma semana inteira de trabalho manual com listas de verificação por uma hora de preparação.

Credissimo comprova conformidade com GDPR e ISO/IEC 27001 em suas operações de financiamento ao consumidor, gerando relatórios de auditoria 85% mais rápido, em um dia em vez de uma semana.

Netwrix cobre a camada de acesso a dados, identidade e relatórios de auditoria que o pilar quatro precisa e que plataformas mais amplas de governança de IA presumem que você já possui. Essas plataformas executam o fluxo de trabalho mais amplo; o fornecedor de IA mantém o controle do comportamento do modelo; e a estrutura, o comitê e as decisões permanecem com você.

Teste o framework primeiro em um sistema

A liderança confia em uma estrutura quando os dados atuais de acesso, configuração e atividade informam suas decisões. Isso desaconselha lançar o programa inteiro de uma vez. Escolha um sistema de alto impacto e depois meça a exposição de dados sensíveis, a amplitude das permissões, o volume de exceções e a completude do pacote de evidências.

Um assistente licenciado rodando no seu tenant existente é o melhor protótipo, pois seu modelo de permissões se baseia nas decisões de acesso já existentes e as ferramentas de visibilidade já estão disponíveis. Execute os seis pilares nesse sistema, veja o que as evidências realmente provam e aplique o padrão ao restante do inventário de IA a partir daí.

Solicite uma demonstração para ver o que suas ferramentas de IA podem alcançar, mapear as identidades por trás delas e manter o histórico de alterações que sua próxima auditoria solicitará.