Como escrever uma política de governança de IA (+ o que incluir)

Apenas 11% das organizações estão totalmente preparadas para a segurança de IA, de acordo com The Netwrix 2026 Data and Identity Security Report.

A adoção de IA na maioria das organizações ocorreu por escolhas individuais de ferramentas antes que as revisões de segurança acompanhassem: os funcionários conectaram Microsoft Copilot, ChatGPT e dezenas de recursos de IA incorporados ao seu trabalho diário antes que alguém escrevesse regras de acesso que governassem o que essas ferramentas podiam acessar.

Esse risco persiste porque o acesso de IA segue um padrão de revisão diferente das solicitações normais de usuários. Essas ferramentas e as identidades dos agentes por trás delas podem herdar permissões, consultar conteúdo sensível e criar novas questões de auditoria mais rápido do que a revisão manual pode catalogá-las.

As equipes de segurança precisam de visibilidade sobre quais ferramentas existem, quais dados podem acessar, quem as aprovou e como as equipes lidam com exceções. Uma política escrita fecha essa lacuna definindo o que a IA pode acessar antes que um incidente levante a questão, fortalecendo a ciberresiliência e mantendo a adoção da IA responsável.

O que é uma política de governança de IA?

Uma política de governança de IA é o documento que define as regras sobre como os funcionários, contratados e fornecedores de uma organização podem usar ferramentas de IA: quais dados essas ferramentas podem acessar, quais ferramentas a organização aprova e como as equipes lidam com violações.

As equipes frequentemente usam "governança de IA" e "política de IA" de forma intercambiável, mas elas descrevem diferentes camadas do mesmo problema, e a distinção determina quem é responsável por quê.

Um framework de governança de IA é o programa mais amplo e contínuo dentro do qual a política opera: os papéis, ciclos de revisão e ferramentas que mantêm a política atualizada. Frameworks de referência externos, como o NIST AI Risk Management Framework (AI RMF) e ISO/IEC 42001, fornecem a estrutura do framework, enquanto a política traduz essa estrutura em regras que sua equipe pode seguir.

Quais são exemplos de políticas de governança de IA?

Princípios abstratos são fáceis de concordar e difíceis de implementar. Políticas de referência de software empresarial, saúde, serviços financeiros e contratos de defesa mostram como os requisitos mudam conforme o tipo de dado e a regulamentação.

Políticas de acesso a dados para Enterprise Copilot e modelos de linguagem grande (LLM)

Estes são os análogos mais próximos do que a maioria das equipes de segurança de mercado médio precisa escrever, além de quaisquer regulamentações específicas do setor a seguir. Eles se concentram em regras de acesso a dados vinculadas a uma categoria específica de ferramenta já em uso, como Microsoft 365 Copilot ou ChatGPT, o que mantém a aplicação baseada em fluxos de trabalho reais. Essas políticas frequentemente combinam rótulos de sensibilidade com um modelo operacional que separa a propriedade da taxonomia da aplicação técnica.

Políticas de governança de IA na saúde

As organizações de saúde constroem essas políticas em torno do Health Insurance Portability and Accountability Act (HIPAA), separando o uso clínico de IA (ferramentas de diagnóstico ou voltadas para pacientes, sujeitas às regras mais rigorosas de acesso e auditoria) do uso administrativo de IA (agendamento, faturamento, documentação interna), pois ambos apresentam níveis de risco diferentes sob a mesma regulamentação. Uma cláusula definidora em uma política modelo: as organizações podem inserir informações de saúde protegidas (PHI) em uma ferramenta de IA somente quando o fornecedor tiver assinado um Business Associate Agreement.

Políticas de governança de IA para serviços financeiros e contratantes de defesa

Eles se baseiam nos frameworks específicos que os orientam: os serviços financeiros incluem Service Organization Control 2 (SOC 2), o Regulamento Geral sobre a Proteção de Dados (GDPR) e o Digital Operational Resilience Act (DORA), enquanto a contratação de defesa inclui a Cybersecurity Maturity Model Certification (CMMC). Ambos vinculam os níveis de risco diretamente ao fato de uma ferramenta de IA acessar dados financeiros de clientes ou informações não classificadas controladas (CUI).

As políticas de defesa vão além: segundo a orientação do Information Security Oversight Office (ISOO), os contratantes não podem inserir CUI em ferramentas de IA públicas ou para consumidores, e qualquer ferramenta de IA que processe CUI deve constar no Plano de Segurança do Sistema do contratante.

Use estes exemplos para fundamentar sua própria política nas ferramentas, tipos de dados e obrigações de conformidade que sua organização realmente possui.

Por que uma política de governança de IA é importante

Uma política escrita oferece à adoção de IA um modelo de governança que as equipes de segurança podem medir, aplicar e melhorar. Também transforma a aprovação de ferramentas, o acesso a dados, o monitoramento e a escalada em evidências revisáveis.

A adoção de IA expande a superfície de ataque mais rápido do que a segurança pode avaliá-la

Cada nova funcionalidade Copilot, ChatGPT ou IA incorporada precisa de acesso aos dados organizacionais, e cada uma cria um novo caminho de acesso para governar. O Netwrix 2026 Data and Identity Security Report constatou que 76% não governam nem monitoram totalmente as identidades não humanas em seus ambientes, então a maioria da adoção de ferramentas de IA ocorre sem visibilidade contínua.

Os frameworks regulatórios estão passando de orientações voluntárias para a aplicação

As obrigações de avaliação de conformidade do EU AI Act para sistemas de alto risco aplicam-se geralmente a partir de 2 de agosto de 2026, com os sistemas de alto risco abrangidos pela legislação de produtos do Anexo I seguindo em 2 de agosto de 2027. Uma política documentada ajuda a mostrar que a organização acompanhou o requisito antes que se tornasse obrigatório. Esperar que um regulamento seja vinculativo antes de registrar algo não deixa evidências de esforço de boa-fé.

Auditores e conselhos agora esperam uma política documentada

Quando a liderança pergunta: "Estamos seguros com AI?", uma política escrita é a evidência de que a resposta é mais do que uma opinião. Uma garantia verbal desmorona durante uma auditoria ou revisão de incidente. A política traduz uma postura de segurança em algo que um auditor pode ler e a diretoria pode apontar, o que está alinhado com a expectativa formalizada na ISO/IEC 42001.

O princípio do menor privilégio aplica-se às ferramentas de IA apenas quando uma política define seu acesso

As equipes de segurança passaram anos restringindo o acesso humano por função. As equipes frequentemente isentam as ferramentas de IA dessa mesma disciplina por padrão, tratando-as como extensões do humano que as implantou ou como contas de serviço genéricas. Identity guidance desencoraja ambas as abordagens porque least privilege requer acesso limitado e responsável. Uma política nomeia as ferramentas de IA como sua própria classe de conta, sujeita a limites reais de acesso.

Organizações sem um já estão pagando por isso

O Relatório de Segurança de Dados e Identity 2026 da Netwrix constatou que 72% das organizações dizem que o risco relacionado à identidade para dados sensíveis aumentou nos últimos dois anos devido à IA e automação. A lacuna de políticas já aparece nos dados de risco, e as organizações que a relatam são as que adotam IA mais rapidamente.

O que incluir em uma política de governança de IA

Uma política utilizável precisa de cláusulas que segurança, jurídico, TI e proprietários de dados possam traduzir em decisões sobre aprovação e acesso. Cada cláusula deve conectar uma declaração de política ao proprietário, ferramenta, categoria de dados ou controle que a torna aplicável.

• Escopo e aplicabilidade: Define quem a política cobre e a que se aplica, incluindo funcionários, contratados, fornecedores e ferramentas shadow AI já em uso. Sem um escopo explícito, a política governa apenas as ferramentas já conhecidas, deixando o restante sem governança.
• Papéis de governança e comitê diretor: Nomes dos responsáveis pela política e para quem escalar quando algo estiver fora dela. Sem um responsável nomeado, a "aplicação da política" fica a cargo de quem notar o problema primeiro.
• Classificação de risco: Classifica os casos de uso de IA em baixo, médio e alto risco com base nos dados ou decisões envolvidos. Sem níveis, todos os casos de uso de IA recebem o mesmo nível de análise, fazendo com que usos de alto risco sejam pouco revisados e os de baixo risco causem atritos desnecessários.
• Regras de acesso e uso de dados: Especifica quais dados cada nível de risco da ferramenta de IA pode ou não acessar. É a cláusula que transforma uma declaração de valores em um controle aplicável. Sem ela, "uso responsável da IA" não tem significado técnico.
• Processo de revisão de ferramentas e fornecedores aprovados: Estabelece como os responsáveis por segurança, jurídico e dados avaliam e aprovam uma nova ferramenta de IA antes que alguém a conecte aos dados da empresa. Sem isso, a adoção da ferramenta ocorre por quem a encontrou primeiro, e não por uma revisão de segurança.
• Requisitos de monitoramento e auditoria: Define como a organização verifica se as equipes seguem a política na prática. Uma política que ninguém verifica na realidade existe apenas no papel.
• Resposta e escalonamento de incidentes: Define o que acontece quando uma ferramenta de IA causa ou revela um problema de segurança ou conformidade. Sem isso, as equipes lidam com um incidente relacionado à IA de forma ad hoc, com o procedimento errado ou tarde demais.
• Alinhamento regulatório: Mapeia a política para os frameworks aplicáveis, incluindo NIST AI RMF, ISO/IEC 42001 e o EU AI Act. Isso permite que uma única política atenda a várias obrigações de conformidade, em vez de exigir um documento separado para cada regulamentação.
• Reveja e atualize a cadência: Comprometa-se a revisar a política em um cronograma definido e após gatilhos importantes, como novas categorias de ferramentas, mudanças regulatórias ou incidentes. As ferramentas de IA mudam mais rápido do que a maioria dos ciclos de revisão de políticas prevê, então uma política sem cadência fica obsoleta em meses.

Como escrever uma política de governança de IA que equilibre adoção e responsabilidade

A liderança quer que a adoção da IA seja rápida; a segurança assume as consequências se agir de forma descuidada. Escreva a política na ordem em que as equipes de segurança precisam de evidências: primeiro os proprietários, depois as ferramentas e fluxos de dados, depois os níveis de risco, regras de acesso, mapeamento regulatório e cadência de revisão. Regras de acesso escritas antes do inventário geralmente deixam de fora as ferramentas que já criam exposição.

1. Reúna uma equipe de governança multifuncional antes de escrever uma palavra

Comece nomeando os cargos reais: um líder de segurança da informação ou de Identity and Access Management (IAM) para assumir a aplicação, jurídico e conformidade para linguagem regulatória, um proprietário de TI ou de dados que saiba onde os dados sensíveis estão, um representante da unidade de negócios que usa ferramentas de IA diariamente e um patrocinador executivo que pode aprovar exceções.

Escolha o presidente com base no papel que já tem autoridade para vincular unidades de negócios fora da segurança, não apenas dentro dela. Em organizações lideradas pela segurança, esse é o CISO. Em organizações focadas em risco, é um executivo sênior de risco, porque as unidades de negócios já respondem a esse papel no risco empresarial, e a governança de IA precisa da mesma autoridade ou essas unidades a tratarão como opcional.

Limite a uma pessoa por função, com um substituto apenas quando a carga de trabalho exigir. Se a segurança redigir a política sozinha, ela parecerá um documento de segurança e poderá faltar autoridade para governar as unidades de negócio que geram o risco.

2. Faça o inventário das ferramentas de IA e dos fluxos de dados que você já possui, incluindo a shadow AI

Construa o inventário a partir de quatro fontes ao mesmo tempo: gastos com SaaS, registros de compras, extensão do navegador, auditorias de concessão Open Authorization (OAuth) e uma pesquisa direta às unidades de negócios.

Faça a correlação dos quatro, pois os funcionários costumam omitir ferramentas que consideram "apenas um assistente de escrita" e os registros de compras não incluem despesas individuais. Assinaturas individuais podem passar despercebidas abaixo dos limites de aprovação, e as revisões de gastos podem não detectar níveis de IA agrupados dentro de contratos SaaS existentes.

Para Microsoft 365, enumere aplicativos empresariais e principais de serviço no Entra ID, e sinalize aqueles que possuem permissões delegadas ou de aplicativo do Microsoft Graph, pois cada concessão é um caminho de acesso que ferramentas de IA podem usar.

Auditorias de concessão de consentimento OAuth e as etapas de remediação da Microsoft para concessões de consentimento ilícitas ajudam a expor e limpar autorizações arriscadas. Registre o propósito de cada ferramenta, o proprietário do negócio e os dados envolvidos em um inventário de sistemas de IA conforme avança.

3. Classifique os casos de uso de IA por nível de risco

Classifique cada caso de uso com base em dois critérios juntos:

1. Quais dados a ferramenta acessa (públicos, internos, regulamentados ou informações pessoais identificáveis (PII)).
2. O que faz com esses dados (resume e exibe, informa uma decisão de negócios ou toma uma ação autônoma).

Uma ferramenta que apenas reescreve textos públicos de marketing tem baixo risco, independentemente de quão sofisticada seja. Uma ferramenta que puxa registros de clientes para responder a tickets de suporte tem alto risco, mesmo que sua saída pareça rotineira.

Uma ferramenta autônoma que executa transações ou modifica a produção está no nível superior e requer aprovação humana obrigatória. Se você opera na UE, sobreponha esses níveis internos às categorias do EU AI Act para que ambos os esquemas permaneçam visíveis.

4. Defina quais dados cada nível de risco pode e não pode acessar

Escreva cada regra de acesso como um mapeamento direto do nível de risco para a categoria de dados. Ferramentas de baixo risco têm acesso a conteúdo não sensível e já público. Ferramentas de risco médio são limitadas a acessar conjuntos de dados específicos já classificados. Ferramentas de alto risco exigem aprovação escrita explícita, registro de acesso e um revisor humano nomeado antes da implantação.

Para dados regulamentados, nomeie a condição explicitamente: PHI requer um Acordo de Associado Comercial assinado, e CUI não pode ser inserido em nenhuma ferramenta fora de um ambiente credenciado.

5. Defina a escalada e a resposta a incidentes antes de publicar

Defina o que acontece quando uma ferramenta de IA causa ou revela um problema de segurança ou conformidade: quem é notificado, com que rapidez e qual processo de resposta a incidentes existente é acionado. Vincule o caminho de escalonamento aos papéis de governança nomeados na etapa 1, para que o problema tenha um responsável nomeado em vez de ficar a cargo de quem o percebe primeiro.

Sem este passo escrito, as equipes acabam lidando com um incidente relacionado à IA de forma improvisada, com o playbook errado ou tarde demais, exatamente a lacuna que uma política deve fechar antes que um incidente levante a questão.

6. Relacione sua política aos frameworks regulatórios aplicáveis

Uma matriz de controle pode servir para todos os frameworks que você utiliza. Alinhe as quatro funções AI RMF (Govern, Map, Measure, and Manage) com as cláusulas do sistema de gestão ISO/IEC 42001 e os níveis de risco do AI Act, e depois escreva a linguagem da política uma vez para essa matriz combinada.

Os dois padrões se complementam: o NIST AI RMF fornece as ações de gerenciamento de risco operacional, e o ISO/IEC 42001 fornece a arquitetura de governança e o registro de auditoria. Usar a mesma linguagem de controle nesses frameworks reduz a documentação duplicada em todas as obrigações que você possui.

7. Defina uma cadência de revisão antes de publicar

Comprometa-se com um intervalo específico, no mínimo anual, além de gatilhos nomeados que forcem uma revisão fora do ciclo: adoção de uma nova categoria de ferramenta de IA, uma mudança regulatória, um incidente ou uma aquisição ou reorganização, incluindo mudanças importantes nos processos de negócios e nos requisitos de dados relacionados.

Ajuste a cadência ao risco, com equipes revisando sistemas de maior risco com mais frequência e o comitê de governança reunindo-se em uma programação recorrente, independentemente disso. Escreva a cadência, os gatilhos e o responsável no próprio documento. Um cronograma de revisão que existe apenas na cabeça de alguém expira no momento em que essa pessoa muda de função.

Como aplicar uma política de governança de IA na prática

As cláusulas da política precisam de controles técnicos que a segurança possa verificar. “A política diz não” só importa quando visibilidade, revisão de acesso, alertas e revogação tornam essa resposta verdadeira.

Obtenha visibilidade total do que suas ferramentas de IA podem realmente acessar

A aplicação começa com um mapa ao vivo das conexões de ferramentas de IA para dados: concessões OAuth, Microsoft 365 e Microsoft Entra ID permissões, extensões de navegador e quaisquer recursos de IA incorporados nas plataformas SaaS existentes.

Feche a porta da frente ao mesmo tempo: desative o consentimento do usuário para aplicativos não verificados e encaminhe novas solicitações pelo fluxo de trabalho de consentimento do administrador, para que novas integrações de IA entrem no processo de revisão por padrão.

As equipes de segurança geralmente conseguem responder "quem tem acesso a quê" para contas humanas; esta etapa constrói a resposta equivalente para ferramentas e agentes de IA, incluindo permissões efetivas que resultam de grupos aninhados e acesso herdado.

As ferramentas nativas da Microsoft ajudam aqui, embora Purview DSPM for AI execute sua avaliação automática de risco apenas nos 100 principais sites do SharePoint, então uma visão mais ampla da data security posture ajuda a validar a imagem nativa e identificar lacunas.

Para o Copilot especificamente, combine etiquetas de sensibilidade com restrições de acesso ao site SharePoint e Restricted Content Discovery para que o compartilhamento excessivo nunca alcance os dados base dos quais o Copilot se alimenta.

Implemente o princípio do menor privilégio para IA da mesma forma que faz para as pessoas

Trate as identidades de ferramentas de IA e identidades de agentes como sua própria classe de conta, sujeitas à mesma revisão de acesso e ao fluxo de trabalho de atestação já usado para contas humanas. Exija acesso limitado e com expiração em vez de permissões amplas e permanentes, e execute o processo de entrada, movimentação e saída que também regula o desligamento humano em relação à desativação das ferramentas de IA.

Zero Standing Privilege modela essa disciplina usando contas efêmeras com escopo de tarefa, ephemeral accounts em vez de credenciais elevadas persistentes.

Escolas do Condado de Eastern Carver aplicaram exatamente essa disciplina: em vez de deixar contas de administrador expostas aos dados dos alunos, o distrito limitou o acesso privilegiado apenas quando necessário usando Netwrix Privilege Secure, e a implementação levou dias em vez de um projeto de um trimestre.

Ancore cada identidade de agente a um human sponsor para que cada conta mantenha um proprietário responsável quando o proprietário humano sair. As orientações atuais de identidade recomendam cadências de revisão mais curtas para agentes do que para pessoas, trimestralmente no mínimo e mensalmente para agentes com privilégios elevados, porque o acesso dos agentes muda mais rápido do que as certificações anuais.

Monitore a exposição de dados orientada por IA continuamente

O monitoramento deve ser contínuo, pois uma revisão de acesso única fica desatualizada no momento em que surge uma nova ferramenta ou integração de IA. Acompanhe quais dados as ferramentas de IA realmente consultam e recuperam, indo além das permissões registradas, e sinalize padrões de volume ou sensibilidade que estejam fora do uso aprovado.

No Microsoft 365, as interações do Copilot são registradas no log unificado de auditoria, portanto, confirme se a retenção da auditoria corresponde ao período de evidência que a política estabelece antes que um auditor solicite os registros do ano passado. Isso fornece às equipes de segurança evidências de que as regras de acesso da política estão alinhadas com o comportamento real da IA.

Netwrix AI Governance, fornecido através de Netwrix 1Secure™, adiciona rastreamento e relatórios de interação do Copilot que as equipes de segurança podem preservar como evidência de auditoria.

Automatize alertas e escalonamento quando uma ferramenta de IA ultrapassar seu limite de acesso

A detecção só tem valor se acionar o caminho de escalonamento que a política já define. Direcione automaticamente as descobertas para o incident response process nomeado na seção de governança da política e registre cada alerta como evidência de auditoria. O caminho de escalonamento deve se conectar a um processo de revogação funcional com propriedade e cronograma claros.

Transforme sua política de governança de IA em um controle aplicável

Uma política escrita reduz o risco quando cada cláusula corresponde a um controle técnico: visibilidade sobre o que as ferramentas de IA podem acessar, privilégio mínimo para identidades de IA e monitoramento contínuo.

Muitos riscos relacionados à IA seguem o mesmo caminho de acesso que incidentes de identidade: atacantes usam credenciais legítimas para acessar dados, e uma ferramenta de IA com acesso permanente amplo demais torna-se outra identidade com permissões excessivas no ambiente.

Segurança de dados e segurança de identidade são o mesmo problema visto de dois ângulos, e a política reduz o risco somente quando ambos são aplicados juntos.

Solicite uma demonstração para ver como 1Secure mapeia o acesso às ferramentas de IA, rastreia as interações do Copilot e transforma as regras de acesso da sua política em evidências de auditoria.