Antes de acelerar a IA, revise as permissões em Dataverse e SharePoint

Semana passada respondi a um e-mail interno sobre pauta de blog com uma frase que resumo aqui de novo, porque ela descreve um padrão que vejo se repetir em projeto atrás de projeto: a IA não cria falhas de permissão, ela as expõe. Quando um cliente decide colocar um agente ou um copiloto para consultar dados de vendas, de RH ou de contratos, a primeira surpresa raramente é técnica. É descobrir quem, na prática, já conseguia enxergar aquilo tudo há anos, sem que ninguém tivesse revisado.

A Microsoft publicou recentemente um conteúdo sobre isso, tratando do papel do Dataverse como camada de controle para capacidade, retenção, segurança, auditoria e recuperação, no contexto do crescimento de volume e de uso de dados de negócio provocado pela adoção de IA. Concordo com o diagnóstico. Mas, pela experiência de quem revisa acesso antes de qualquer projeto de IA entrar em produção, o problema raramente está no Dataverse isoladamente. Está na combinação de Dataverse, SharePoint, OneDrive e Teams, que juntos formam o mapa real de onde a informação de uma empresa vive.

O que muda quando um agente de IA entra em cena

Antes de existir um agente ou um copiloto consultando dados, uma permissão mal configurada em uma biblioteca do SharePoint ou em um ambiente do Dataverse já era um risco, mas um risco que dependia de alguém procurar manualmente o arquivo errado, na pasta errada, para virar um problema real. Isso limitava, na prática, o tamanho do estrago.

Um agente de IA muda essa equação porque ele não procura manualmente. Ele varre, cruza e resume, em segundos, tudo o que tem permissão de enxergar. Se um usuário tem acesso amplo a uma pasta do OneDrive por herança de um cargo antigo, ou se um canal do Teams ficou público quando deveria ser restrito, o agente vai usar exatamente esse acesso, sem julgar se ele faz sentido. A ferramenta não erra: ela só cumpre, com uma eficiência nova, uma configuração de acesso que já estava errada antes dela existir.

Por que a auditoria de acesso vira pré-requisito, não etapa opcional

Nos projetos que a S4R conduz, ficou claro que a etapa de revisão de permissões deixou de ser um item de checklist de segurança geral e passou a ser condição de entrada para qualquer projeto de IA. Não é possível avaliar com seriedade o risco de expor um agente a uma base do Dataverse sem antes saber, com precisão, quem tem acesso a quê, por qual motivo e desde quando.

Isso exige olhar para quatro camadas ao mesmo tempo, porque um agente de IA moderno normalmente não fica restrito a uma única fonte:

• Dataverse: papéis de segurança, hierarquia de equipes e regras de compartilhamento por registro, que definem o que cada usuário (e cada aplicação) pode ler ou alterar nas tabelas de negócio.
• SharePoint: permissões herdadas de site, bibliotecas com compartilhamento externo habilitado e links “qualquer pessoa com o link”, que costumam ser criados para resolver um problema pontual e nunca mais são revisados.
• OneDrive: pastas pessoais compartilhadas manualmente com colegas ou parceiros, muitas vezes fora de qualquer política central, porque nasceram de uma necessidade individual e não de uma decisão de TI.
• Teams: canais e arquivos associados a equipes que crescem organicamente, absorvendo membros de projetos antigos que já não deveriam ter acesso àquele conteúdo.

Um agente de IA bem-configurado, mas apontado para um ambiente onde essas quatro camadas nunca foram revisadas juntas, tende a expor exatamente a combinação de dados que a empresa menos gostaria de expor: informação sensível, acumulada ao longo de anos, sem dono claro.

O que costuma aparecer quando essa revisão finalmente acontece

Quando conduzimos esse tipo de levantamento antes de um projeto de IA, alguns padrões se repetem com uma frequência que já deixou de nos surpreender. Contas de ex-funcionários com acesso ainda ativo a bibliotecas inteiras do SharePoint. Grupos de segurança do Dataverse criados para um projeto específico, nunca desativados depois que o projeto terminou. Pastas do OneDrive compartilhadas externamente, com validade indefinida, criadas para enviar um contrato há dois ou três anos.

Nenhum desses achados é exclusivo de empresas com governança fraca. Aparecem também em organizações que investem em segurança, porque a revisão de acesso é um trabalho contínuo, não uma tarefa que se resolve de uma vez. O que muda, com a chegada da IA, é o custo de deixar esse trabalho acumulado. Antes, um acesso esquecido era um risco latente. Agora, é um risco que um agente pode ativar sozinho, na primeira pergunta que alguém fizer a ele.

Capacidade, retenção e recuperação também entram na conta

O ponto que a Microsoft levanta sobre capacidade e retenção do Dataverse também merece atenção prática, e não só do ângulo de segurança. Um agente de IA que consulta grandes volumes de dados com frequência aumenta o consumo de capacidade do ambiente, o que tem impacto direto em custo e em desempenho para os demais usuários. Políticas de retenção mal definidas, por sua vez, significam que dados que deveriam ter sido eliminados há tempos continuam disponíveis para consulta, inclusive por um agente que não tem como saber que aquela informação já deveria estar fora do sistema.

Auditoria e recuperação completam o quadro. Se um agente de IA grava ou altera dados no Dataverse, a trilha de auditoria precisa estar habilitada e configurada corretamente antes disso acontecer, não depois de um incidente. E um plano de recuperação testado deixa de ser apenas proteção contra falha técnica: passa a ser também a forma de reverter uma alteração em massa que um agente tenha feito com base em uma instrução mal formulada.

O que fazer antes de aprovar o próximo projeto de IA

Recomendo tratar a revisão de acesso como a primeira entrega de qualquer projeto de IA, antes mesmo de discutir qual modelo ou qual plataforma usar. Na prática, isso significa:

• Levantar quais fontes de dados o agente vai consultar (Dataverse, SharePoint, OneDrive, Teams, ou uma combinação delas) e mapear quem tem acesso a cada uma hoje.
• Revisar compartilhamentos externos e links públicos, priorizando o que está exposto para fora do tenant, porque é o que representa o maior risco imediato.
• Confirmar se contas inativas ou de ex-funcionários ainda mantêm acesso, e revogar o que não tiver justificativa de negócio atual.
• Verificar se as políticas de retenção do Dataverse e do restante do Microsoft 365 refletem o que a empresa realmente precisa manter, e não apenas o padrão de fábrica.
• Testar, num ambiente controlado, o que o agente efetivamente consegue acessar, antes de liberá-lo para uso real.

Esse levantamento não precisa travar o projeto. Na maioria dos casos que acompanhamos, ele leva de alguns dias a poucas semanas, dependendo do tamanho do ambiente, e evita que o primeiro incidente de exposição de dados aconteça depois que o agente já estiver em produção, quando corrigir custa muito mais caro.

Por onde começar

Se sua empresa já decidiu avançar com algum projeto de IA sobre dados do Dataverse ou do Microsoft 365, comece pelo inventário mais simples possível: liste as fontes de dados envolvidas e, para cada uma, responda quem tem acesso hoje e por quê. Se a resposta para “por quê” for “não sei” ou “sempre foi assim”, esse é o primeiro ponto a corrigir, antes de qualquer configuração de agente.

Não é preciso resolver toda a governança de dados da empresa de uma vez para começar um projeto de IA com segurança. É preciso, sim, garantir que o agente vai enxergar exatamente o que deveria enxergar, nem mais, nem menos.

Uma conversa que vale a pena ter antes de configurar o primeiro agente

Se sua empresa está avaliando onde aplicar IA sobre dados de Dataverse, SharePoint, OneDrive ou Teams, e quer garantir que o acesso está revisado antes de qualquer agente entrar em produção, fale com um especialista da S4R. Ajudamos a mapear quem acessa o quê hoje e a corrigir o que precisar ser corrigido, antes que um agente descubra isso por você.