Auditoria de Governança de IA para Equipes de Segurança e TI
Sep 2, 2026
A auditoria de governança de IA distingue entre uma política documentada e um controle em funcionamento. A auditoria rastreia uma saída de IA até a identidade que a invocou, os dados acessados, a barreira aplicada e o registro mantido posteriormente. A maioria dos programas falha porque o acesso é ineficaz: ninguém pode dizer quais identidades acessam dados sensíveis por meio de um assistente de IA, muito menos provar que o limite é respeitado.
A liderança aprova o Microsoft 365 Copilot e, dois dias depois, o jurídico quer saber quais arquivos sensíveis ele pode ler. Na pesquisa por trás do Netwrix 2026 Data and Identity Security Report, 71% dos líderes de segurança e TI disseram que não conseguem determinar imediatamente quais identidades têm acesso a um dado sensível específico.
O assistente em si raramente é o problema. A documentação da Microsoft afirma que Copilot exibe dados organizacionais aos quais os usuários individuais têm pelo menos permissões de visualização, então cada associação de grupo obsoleta e site compartilhado em excesso se torna um possível resultado do prompt. A lacuna de controle está na camada de permissões subjacente, onde anos de compartilhamento ad hoc se acumulam sem revisão.
Testar a identidade da camada um e um arquivo de cada vez é o que produz uma resposta que ninguém precisa aceitar sem comprovação.
O que é auditoria de governança de IA?
A auditoria de governança de IA examina se os controles que regem o acesso da IA a dados, identidades e fluxos de trabalho operam conforme projetado. As evidências incluem logs, resultados de testes, relatórios de permissões e revisões datadas.A orientação de auditoria da PwC enquadra a tarefa como testar o design e a eficácia dos controles relacionados à IA. Isso significa documentar como cada controle é projetado, como funciona e como a gestão o testa.
Uma auditoria de governança termina com a eficácia do controle. O teste de desempenho do modelo é uma disciplina separada que abrange viés, deriva, precisão e explicabilidade.
O escopo abrange governança e políticas, riscos técnicos e de modelo, e controles de acesso a dados e identidade. O IIA's AI Auditing Framework atribui esse trabalho por responsabilidade, mapeando-o para o Modelo das Três Linhas para que os órgãos de governança, a gestão e a auditoria interna tenham cada um uma parte definida. A identidade está explicitamente dentro do escopo, e o ISACA AAIA outline exige que os auditores avaliem o programa específico de gestão de identidade e acesso de IA de uma organização.
Por que a auditoria da governança de IA é mais importante que o documento de política
Uma política declara uma intenção. Uma auditoria produz os artefatos que mostram que essa intenção sobreviveu ao contato com um locatário ativo. Essa lacuna separa um programa de governança de um slide de governança, e traz benefícios de quatro maneiras específicas.
Aprovando a adoção de IA com base em evidências
As equipes de segurança são solicitadas a aprovar implementações de IA em um cronograma definido por outra pessoa. Uma auditoria concluída permite que eles aprovem com uma lista nomeada de quais ferramentas de IA acessam quais dados sob quais identidades. A aprovação então se baseia em um limite que alguém realmente testou, não apenas descreveu.
Transformando a política em um registro de medição
A expectativa do NIST AI RMF para medição contínua está em MEASURE 2.4. Afirma que a funcionalidade e o comportamento do sistema de IA e seus componentes, identificados na função MAP, são "monitorados quando em produção." Uma auditoria converte uma política escrita em um registro que satisfaz essa expectativa, construído a partir de logs, relatórios de permissões, resultados de testes assinados e revisões com datas e nomes anexados.
Detectar exposição antes que se torne um incidente
Sites compartilhados em excesso e permissões obsoletas aparecem no cronograma de outra pessoa, geralmente durante uma investigação. O Netwrix 2026 Data and Identity Security Report descobriu que 75% das exposições de dados sensíveis começam com identidades comprometidas ou permissões mal configuradas. Isso torna a camada de permissões o lugar mais produtivo para procurar.
Uma auditoria agendada transforma essas condições em achados com tickets e responsáveis nomeados, meses antes de uma revisão de violação.
Uma auditoria programada converte essas condições em achados com tickets e responsáveis nomeados meses antes de uma revisão de violação.
Dar à liderança um número que se mova
Os conselhos financiam o trabalho que podem acompanhar, e uma auditoria concluída gera uma contagem de lacunas abertas, junto com responsáveis e datas-alvo. As equipes obtêm essa contagem a partir de testes de controle falhos e descobertas não resolvidas, então o progresso é lido como uma linha de tendência, muito parecido com a conformidade de patches ou taxas de falha de phishing.
Netwrix 1Secure™ informa quais arquivos sensíveis o Copilot pode acessar para cada identidade licenciada e registra todas as interações do Copilot junto com os recursos referenciados. Solicite uma demonstração.
Como auditar os controles de governança de IA
Uma auditoria defensável responde a cinco perguntas, em ordem. Cobre quais sistemas de IA estão em uso, quais dados sensíveis cada um pode acessar, sob quais identidades operam, quais controles se aplicam e quais evidências mostram que esses controles funcionam. Siga os seis passos abaixo em sequência e termine cada um com o artefato nomeado no final.
1. Construa e verifique o inventário de ativos de IA e acesso a dados
Extraia o inventário de três fontes, porque nenhum sistema sabe tudo. Pegue aplicativos de IA licenciados e service principals do Microsoft Entra ID. Adicione recursos de IA incorporados das notas de versão e do centro de administração de cada fornecedor SaaS, além de ferramentas não autorizadas dos logs de saída ou do seu CASB. Para cada entrada, registre o proprietário, o propósito comercial, o ambiente e os repositórios que a ferramenta pode acessar.
Em seguida, reconcilie as três listas e trate cada diferença como uma constatação. Atribua a cada ferramenta não registrada um proprietário nomeado e uma data de decisão, decida se deve mantê-la ou bloqueá-la e registre o resultado. O uso não autorizado raramente aparece nos registros de compras, por isso shadow AI security deve estar na primeira análise junto com as ferramentas autorizadas.
Aplique o mesmo escrutínio às ferramentas que você já aprovou, pois aprovação e segurança são questões separadas. Se Copilot é seguro em um determinado tenant depende do que suas identidades licenciadas podem acessar, e este inventário responde a isso.
Considere a etapa concluída quando toda ferramenta de IA no ambiente aparecer em uma única lista, com um proprietário e um mapeamento da fonte de dados. NIST AI RMF GOVERN 1.6 exige mecanismos para inventariar sistemas de IA e alocá-los conforme as prioridades de risco organizacional. Esta lista satisfaz esse requisito. O artefato é um inventário validado com uma lista anexada de descobertas.
2. Teste cada política de IA contra o papel que a aplica
Leia cada política de uso de IA com base em quatro perguntas antes de analisar qualquer controle. Defina qual uso é aceitável, quais tipos de dados são proibidos, onde é necessária a intervenção humana e por quanto tempo a saída é retida. Anote a resposta para cada uma e marque qualquer questão que a política deixar em aberto.
Em seguida, crie um mapa de duas colunas que coloque cada declaração de política ao lado do papel nomeado responsável por aplicá-la. Nomeie o indivíduo, pois um nome de equipe não dá ao auditor ninguém para entrevistar sobre quem aprova um novo caso de uso de IA e quem revisa a saída em fluxos de trabalho de alto risco. Qualquer declaração sem nome anexado é a constatação.
Estenda a governança que você já aplica em vez de escrever um conjunto paralelo de regras de IA. Uma IAM risk assessment já documenta os caminhos de aprovação, e um programa estabelecido de identity governance and administration já define a propriedade dos papéis. Confirme que eles se estendem ao uso de IA e registre onde terminam.
GOVERN 2.1 exige que papéis, responsabilidades e linhas de comunicação para mapear, medir e gerenciar o risco de IA estejam documentados e claros para indivíduos e equipes em toda a organização. O artefato é esse mapa de política para função, com as declarações sem dono listadas como lacunas.
3. Mapear o acesso efetivo para cada fonte de dados acessível por IA
Execute esta etapa em quatro fases, avançando da licença para o arquivo. Primeiro, liste os usuários e grupos que possuem licenças Copilot. Segundo, resolva cada grupo para sua composição real, incluindo grupos aninhados. Terceiro, liste os sites SharePoint, Teams e caixas de correio que contêm dados sensíveis e que a composição resolvida pode acessar.
A quarta passagem cobre as identidades que as pessoas esquecem, começando pelos convidados. Contas de convidados ampliam o mapa mais rápido que qualquer outra coisa, então audite Teams guest access contra os mesmos sites sensíveis. Depois, repita todo o exercício para identidades não humanas, pois Active Directory service accounts e registros de aplicativos frequentemente têm acesso mais amplo do que qualquer pessoa na folha de pagamento.
Comece o mapeamento com o relatório nativo e depois verifique o que foi deixado de fora. O relatório da Microsoft "Site permissions for users" lista os sites do SharePoint ou OneDrive que um usuário especificado pode acessar, diretamente ou por meio de grupos, e é a visão nativa por identidade mais próxima.
Antes de considerar essa saída como completa, verifique três limites no seu próprio ambiente. O relatório depende do organization-wide permissions report, que mostra apenas os 100 principais sites por número de usuários permitidos e exclui sites arquivados e sites em estado de bloqueio NoAccess. Os dados podem atrasar a geração em até 48 horas, e cada locatário é limitado a cinco relatórios atualizados a cada 30 dias.
Cubra o restante com ferramentas que resolvem o aninhamento em todo o patrimônio em uma única passagem. Essa é a função de uma capacidade de data access governance e da categoria mais ampla de ferramentas de data access governance que existem para fechar exatamente essa lacuna. O artefato é um conjunto de descobertas de acesso por identidade com classificações de risco.
4. Comprovar que o registro pode reconstruir uma interação com IA
Teste a trilha escolhendo uma interação recente do Copilot e tentando reconstruí-la apenas a partir dos logs. Recupere o login, o evento de prompt, os arquivos acessados e qualquer alteração administrativa nas configurações de IA, depois verifique se file access monitoring cobre os repositórios envolvidos. Tudo o que você não conseguir recuperar vai direto para a lista de descobertas como uma lacuna de cobertura.
Saiba qual tipo de registro contém o quê antes de concluir que algo está faltando. Os CopilotInteraction audit records do Purview capturam metadados de interação e referências aos arquivos que o Copilot usou para responder a uma solicitação. No entanto, os corpos do prompt e da resposta residem na caixa de correio do usuário e exigem eDiscovery para coletar.
Next, measure your retention window against the investigation window you'd actually need. Under Microsoft's audit retention policies, Audit (Standard) retains records for 180 days, and Audit (Premium) extends that period to 1 year for Microsoft Entra ID, Exchange, OneDrive, and SharePoint activity generated by users with E5 or equivalent licensing. Anything longer than a year requires the 10-Year Audit Log Retention add-on in addition to E5.
Finalize a etapa testando se os registros realmente se conectam entre os sistemas. Confirme que a equipe pode vincular um evento de IA a uma identidade e depois a um registro de acesso a arquivos sem correlação manual, e observe quaisquer lacunas nas ferramentas onde a cadeia se quebra. O artefato é uma avaliação da cobertura e retenção de logs indicando a janela por carga de trabalho.
5. Execute testes de controle a partir de uma identidade permitida e uma não permitida
Defina o teste antes de executá-lo, pois um resultado esperado escrito depois não tem valor. Escolha um arquivo com um rótulo de sensibilidade conhecido, uma identidade que deve acessá-lo e outra que deve ser recusada, depois anote o resultado esperado de cada um.
Emita o mesmo comando de recuperação de ambas as identidades e compare as duas respostas. A identidade permitida deve retornar o conteúdo, e a identidade restrita deve recusar ou retornar um resultado vazio. Verifique o log de auditoria para ambas as tentativas, pois uma falha silenciosa que não deixa registro é uma constatação por si só.
Dê ao DLP o mesmo tratamento superfície por superfície no mesmo arquivo de teste. Execute as políticas em modo de simulação antes de aplicá-las, e aplique as melhores práticas de política DLP que se encaixem no tenant. Repita cada caso no chat, no Word e no resumo de e-mail, pois uma política que funciona em um pode se comportar de forma diferente em outro.
Registre o escopo, o resultado esperado, o resultado real e a correção para cada caso, depois assine os documentos de trabalho e anexe as capturas de tela e exportações de logs. O artefato é um registro de teste assinado no qual cada caso falho tem um responsável e uma data para novo teste.
6. Escreva o relatório para que as descobertas se convertam em remediação
Estruture o relatório como qualquer outro IT risk assessment entregue, cobrindo escopo, metodologia, descobertas, classificações de risco e remediação. Ordene as descobertas por importância, para que o leitor veja primeiro a maior falha.
Para cada observação, inclua os cinco elementos que um revisor procura antes de assinar. O kit de ferramentas para redação de relatórios do IIA recomenda uma classificação de criticidade e uma declaração de fatos que abrange condição, critérios, causa e efeito, além de um plano de ação de gestão nomeando a ação acordada, o pessoal responsável e uma data de vencimento.
Defina a próxima data de auditoria antes de circular o relatório, enquanto o escopo ainda está fresco. Agende-a em um intervalo planejado e adicione gatilhos de mudança para novos recursos de IA, alterações de permissões, revisões de políticas e mudanças de registro. O artefato é esse relatório, com uma data de reteste já no calendário.
Como verificar os controles de acesso do Microsoft 365 Copilot
Microsoft Copilot recebe sua própria aprovação porque suas barreiras de proteção estão em superfícies administrativas nomeadas que um método genérico não pode apontar, e porque um desses controles está sendo descontinuado. A orientação de implantação da Microsoft organiza um lançamento em descobrir, classificar, auditar, proteger, monitorar e governar, com cada verbo correspondendo a um teste com resultado registrado.
1. Leia primeiro a avaliação de risco de dados do Purview
Abra o Microsoft Purview Data Security Posture Management (DSPM), vá para Discover e depois Data risk assessments, e leia a avaliação padrão antes de executar qualquer análise personalizada. Ela é executada semanalmente nos 100 principais sites SharePoint por uso, e os primeiros resultados levam cerca de 4 dias para aparecer em um novo tenant.
Considere o resultado como uma lista restrita que ainda precisa ser ampliada, pois as classificações de uso e sensibilidade apontam em direções diferentes. Transfira tudo o que a avaliação indicar para o mapeamento por identidade do passo 3 e mantenha os sites não classificados no escopo.
2. Extraia os relatórios de governança de acesso a dados do SharePoint
Gere os relatórios de Data Access Governance e analise links de compartilhamento arriscados, estado de permissões e exposição Everyone Except External Users (EEEU). Cada concessão EEEU em um site que contém dados regulados é uma constatação, e links de compartilhamento anônimos são os mais rápidos para revogar.
Verifique seu nível de licença antes de confiar na cobertura que esses relatórios oferecem. Apenas o E5 fornece relatórios de atividade, limitados a 10.000 sites com 28 dias de dados. Relatórios instantâneos e ações de remediação exigem SharePoint Advanced Management, que inclui uma licença Copilot, o complemento Plano 1 ou Microsoft 365 E7.
3. Substitua a Pesquisa Restrita do SharePoint por um controle suportado
Verifique se o locatário ainda depende de Restricted SharePoint Search (RSS) para impedir o Copilot, e registre uma constatação de migração sempre que isso ocorrer. A Microsoft anunciou a aposentadoria pelo centro de mensagens do Microsoft 365, bloqueando a habilitação de novas RSS a partir de 31 de julho de 2026 e aposentando totalmente o recurso em 31 de janeiro de 2027.
Plane a substituição enquanto ainda há tempo, pois as configurações existentes de RSS não serão migradas automaticamente para Restricted Content Discovery. Faça um inventário dos sites atualmente protegidos por RSS e associe cada um a uma correção de permissão ou a uma entrada em Restricted Content Discovery.
4. Teste etiquetas e DLP em todas as superfícies do Copilot
Verifique rótulos de sensibilidade primeiro nos arquivos de teste, depois verifique a configuração do Purview DLP no Microsoft 365 Copilot e Copilot Chat. Execute o mesmo caso no Copilot Chat, no Word e no resumo de e-mail, e registre cada superfície separadamente.
Compare o resultado com o que a ação da política realmente executa. A ação DLP impede que o Copilot processe conteúdo sensível, mas mantém o acesso do usuário ao arquivo intacto, então um usuário que ainda abre o documento passou no teste. Para cada caso, capture a identidade, o arquivo, o resultado esperado, o resultado real, o rótulo ou regra DLP aplicável e o carimbo de data/hora.
5. Exporte as evidências e agende a nova verificação
Exporte os registros de auditoria Purview da atividade do Copilot para o período de teste e defina a retenção dos logs de auditoria para corresponder ao período de investigação que a equipe realmente precisaria. Agende Microsoft Entra access reviews para as associações de grupo que controlam o acesso ao Teams e ao site, depois atribua um responsável para cada teste reprovado e marque a data do novo teste.
Avalie a verificação do Copilot com base em um único padrão concreto, em vez de uma lista de configurações revisadas. A equipe aprova quando pode nomear um arquivo, mostrar que o Copilot não o resumirá sob uma identidade restrita, explicar qual permissão, etiqueta ou regra DLP o impediu e apresentar o registro Purview que comprova que o teste ocorreu.
Lista de verificação de evidências e prontidão para uma auditoria de governança de IA
Uma auditoria de acesso a dados de IA baseia-se em artefatos que um auditor pode inspecionar. Quatro categorias têm a maior importância:
- Evidência de inventário: A lista de sistemas e ferramentas de IA com proprietários e ambientes, além da documentação das fontes de dados que cada sistema pode acessar
- Evidências de políticas e controles: Políticas de uso com registros de alterações, definições de funções e uma matriz responsible, accountable, consulted e informed (RACI) para governança de IA, e uma avaliação de riscos por caso de uso de IA
- Evidências de Identity, acesso e monitoramento: Relatórios de acesso por identidade, logs de atividade de IA e registros de eventos de controle como gatilhos DLP, decisões de Conditional Access e resultados de revisão de acesso
- Evidências de revisão e supervisão: Atas ou tickets documentando decisões de governança de IA, um registro de auditoria da remediação após avaliações anteriores e métricas que acompanham o desempenho da governança ao longo do tempo
Se faltar qualquer um dos quatro, essa é a falha que um auditor encontra primeiro. As perguntas de prontidão abaixo testam o mesmo ponto de outra perspectiva, e cada uma não respondida é uma lacuna que precisa de um responsável, um plano de remediação e uma data para novo teste.
Readiness check | Question to answer |
|---|---|
|
Inventory |
Do you have a documented inventory of all AI tools and use cases, including Copilot and other embedded AI features? |
|
Data access |
Can you list which sensitive data sources each AI system can reach, and under which identities? |
|
Control mapping |
Are AI usage policies mapped to actual controls, including access rules, DLP, Conditional Access, and review processes? |
|
Log retention |
Do you retain AI-related logs long enough, and in a form you can hand to auditors and leadership? |
|
Review evidence |
Can you show a recent AI governance review with findings, remediation actions, and named owners? |
|
Historical reporting |
Can you report identity and data access tied to AI tools over time, rather than at a single point? |
Como a Netwrix fecha a lacuna de auditoria da governança de IA
Quatro dos passos acima operam com dados que as ferramentas nativas retêm brevemente ou dispersam por portais, abrangendo permissões efetivas, registros de atividade de IA, aplicação em nível de prompt e histórico de alterações.
Netwrix agrupa esses sob AI governance como uma capacidade nomeada da plataforma para ambientes híbridos da Microsoft, e um produto diferente executa cada função.
Relatando o que o Copilot pode alcançar, antes e depois do lançamento
Netwrix 1Secure informa sobre os dados sensíveis que o Copilot pode acessar antes que um locatário o ative, respondendo à questão da prontidão enquanto a implantação ainda é reversível. Após o lançamento, lista usuários, carimbos de data/hora e recursos referenciados para cada interação, e sinaliza respostas do Copilot que expõem dados sensíveis.
A cobertura abrange SharePoint Online, servidores de arquivos Windows, Active Directory, Microsoft Entra ID e Exchange Online, portanto, o passo 4 da trilha de logs solicitado sai de um único console.
Calculando permissões efetivas por trás de cada identidade
Netwrix Access Analyzer resolve a associação aninhada de grupos AD e a herança quebrada do SharePoint para calcular o que cada identidade pode realmente acessar, revelando acessos abertos e direitos obsoletos que os relatórios por site achatam. Isso transforma o mapeamento de quatro etapas do passo 3 em um relatório que você pode entregar a um auditor.
A avaliação de Microsoft 365 Copilot readiness realiza a mesma análise antes da implantação, para que o conteúdo com permissões excessivas seja corrigido antes que qualquer usuário receba um aviso.
Bloqueio de dados sensíveis em prompts de IA no endpoint
Netwrix Endpoint Protector inspeciona o conteúdo do prompt no endpoint e bloqueia dados sensíveis antes que cheguem ao ChatGPT, Microsoft Copilot, Google Gemini, Claude ou DeepSeek. Cada evento bloqueado está vinculado à identidade por trás dele, o que transforma uma regra escrita de dados proibidos em algo que a etapa 5 pode testar.
Retendo evidências de alterações além da janela de log nativa
Netwrix Auditor registra todas as configurações e alterações de diretório do AD e Entra ID com valores antes e depois em uma trilha pesquisável. Ele mantém esses valores em um Arquivo de Longo Prazo que tem como padrão 120 meses, muito além da janela padrão de 180 dias do Purview.
Dois clientes regulados mostram o valor dessa trilha retida durante uma auditoria. First National Bank e Trust of Beloit mantêm conformidade contínua com OCC para 300 usuários em 17 locais com Netwrix Auditor, substituindo o trabalho manual de listas de verificação que antes levava uma semana inteira por uma hora de preparação. Flagler Bank identifica e mitiga riscos de TI em toda a sua rede com um departamento de TI de uma pessoa, encerrando investigações em 10 minutos que a busca manual em logs costumava levar horas.
Netwrix relata o acesso a dados de IA e o bloqueia no endpoint. A camada de aplicação da Microsoft ainda determina o que uma identidade pode fazer dentro do Microsoft 365 por meio de rótulos de sensibilidade, Purview DLP e Acesso Condicional. A auditoria verifica esses controles, e o comportamento do modelo permanece com as equipes de ciência de dados e risco de modelo.
Solicite uma demonstração para mapear quais identidades o Copilot pode alcançar, monitorar o que ele exibe após o lançamento e manter as evidências de alteração que um examinador solicitará.
Perguntas frequentes sobre auditoria de governança de IA para equipes de segurança e TI
Compartilhar em
Saiba Mais
Sobre o autor
Netwrix Team
Saiba mais sobre este assunto
Estrutura de Governança de IA: Como Construir Uma que Funciona
NIST CSF 2.0: Novidades no Cybersecurity Framework
Leis de Privacidade de Dados por Estado: Abordagens Diferentes para a Proteção da Privacidade
Exemplo de Análise de Risco: Como Avaliar Riscos
O que é Gerenciamento de Registros Eletrônicos?