Em boa parte das empresas, um projeto vive em três lugares ao mesmo tempo: a decisão no Jira, o documento no SharePoint e o número no Databricks. Enquanto o documento fica no SharePoint, a permissão dele é respeitada inclusive pela IA. A Microsoft documenta que o Copilot só mostra dado que o usuário tem pelo menos permissão de visualizar, e a Atlassian documenta que o Rovo espelha a permissão da origem quando lê o SharePoint por conector. O problema começa na cópia. Anexado a um item do Jira, o arquivo passa a seguir a permissão do projeto Jira. Ingerido no Databricks pelo conector de SharePoint, ele chega sem a lista de controle de acesso do arquivo, porque a documentação do conector afirma que essas listas não são ingeridas. Cada cópia cria um regime de permissão novo, e a IA responde a partir da cópia que encontrar. Uma consultoria Jira fecha a primeira brecha trocando cópia por referência, e uma consultoria Databricks fecha a segunda declarando de novo a governança no ponto de ingestão.

O contrato que estava restrito no SharePoint e aberto no Jira

A cena é corriqueira em projeto com fornecedor. O jurídico guarda o contrato numa biblioteca do SharePoint com acesso restrito a poucas pessoas. Para facilitar a vida do time, alguém baixa o PDF e anexa ao épico do projeto no Jira, onde ele fica à mão de todos que trabalham nas tarefas. Ninguém quebrou regra de propósito. Foi um gesto de conveniência que leva dez segundos.

Daquele momento em diante existem dois contratos com duas regras de acesso. O original continua restrito. A cópia segue a permissão de quem pode ver o épico, que pode incluir terceiros, estagiários e o assistente de IA que responde sobre aquele projeto. Quando o contrato é renegociado, a nova versão vai para o SharePoint e a antiga continua no Jira, desatualizada e acessível. Ninguém percebe, porque nada quebrou. O vazamento aqui é silencioso, e a IA tende a encontrar a cópia antes do original.

A tese deste guia: em projeto que atravessa Jira, SharePoint e Databricks, a governança não se perde no sistema mais frágil, se perde na cópia entre sistemas. A permissão pertence ao lugar onde o documento mora, e não ao documento. Toda cópia leva o conteúdo e deixa a regra para trás. Por isso a decisão central de governança desse projeto é onde cada coisa mora e como os outros sistemas apontam para ela, e não qual ferramenta é mais segura.

O que acontece com a permissão do documento em cada sistema?

O comportamento da permissão muda conforme o caminho que o documento faz. A tabela resume o que cada fonte oficial documenta e o que isso significa para quem governa o projeto.

A linha do Databricks precisa de leitura precisa. A documentação diz que o conector não ingere as listas de controle de acesso dos arquivos do SharePoint. Isso não torna o dado inseguro por definição. Torna a segurança dele uma decisão nova, que precisa ser tomada no Databricks porque não vem do SharePoint. Quem trata a ingestão como cópia fiel do SharePoint supõe uma proteção que o conector declara não trazer.

Por que a IA torna essa brecha mais cara?

Antes da IA, uma cópia mal governada dependia de alguém ir procurá-la. Com assistentes e agentes respondendo perguntas sobre o projeto, a cópia passa a ser encontrada por busca, e devolvida em resposta, para qualquer pessoa que tenha acesso ao lugar onde ela está. O Copilot respeita a permissão do SharePoint e o Rovo respeita a do conector, mas ambos respeitam a permissão do lugar onde o conteúdo está, e não a do lugar de onde ele veio. A cópia anexada no Jira obedece ao Jira.

Por isso a pergunta útil em projeto com IA muda. Deixa de ser se a ferramenta de IA respeita permissões, porque as três documentam que respeitam no próprio escopo. Passa a ser quantas cópias do mesmo conteúdo existem, cada uma com a sua regra. A IA não cria a brecha. Ela só a torna encontrável em segundos.

O que a consultoria Jira muda: referência em vez de cópia

A primeira brecha se fecha no desenho da instância Jira, e é trabalho de consultoria Jira. A regra é simples de enunciar e exige disciplina para manter: documento que tem dono e permissão no SharePoint não vira anexo no Jira. O item do Jira guarda o link para o documento canônico, e o acesso continua decidido pela biblioteca de origem. Quem tem permissão abre. Quem não tem vê o link e não abre. A versão é sempre a atual, porque só existe uma.

Na prática, isso pede três decisões de configuração: um campo ou padrão de link governado para referência a documento canônico; uma política explícita sobre quais tipos de documento podem ser anexados, como capturas de tela de erro, e quais nunca podem, como contrato, dado pessoal ou documento classificado; e uma revisão periódica dos anexos existentes nos projetos com material sensível. A conexão do SharePoint com o Rovo ajuda nessa direção, porque permite que a busca e as respostas da IA no Atlassian alcancem o documento no SharePoint sem copiá-lo, respeitando a permissão da origem.

ANTES  SharePoint (restrito) --download--> anexo no Jira (regra do projeto)
        duas versões, duas regras, a IA encontra as duas
 
DEPOIS SharePoint (restrito) <--link------ item no Jira
        uma versão, uma regra, a IA respeita a origem



O que a consultoria Databricks muda: governança declarada na ingestão

A segunda brecha não se fecha com link, porque o objetivo de levar documentos e listas do SharePoint para o Databricks é justamente processá-los: extrair conteúdo, cruzar com dados do Jira e de outras fontes e alimentar análises e agentes. Como a documentação do conector afirma que as listas de controle de acesso dos arquivos não são ingeridas, a governança precisa ser declarada de novo no destino, e esse é o trabalho de consultoria Databricks.

O Unity Catalog é onde essa declaração acontece. A documentação da Databricks descreve permissões aplicadas igualmente a pessoas, notebooks e modelos, máscaras de coluna e filtros de linha aplicados no momento da consulta e linhagem capturada automaticamente. Na prática, a ingestão do SharePoint deve cair num esquema com concessão restrita por padrão, com a classificação do conteúdo sensível feita antes de abrir acesso e com a linhagem mostrando de qual biblioteca cada arquivo veio. Também vale considerar as limitações documentadas do conector. Ele ingere a pasta, unidade ou site configurado inteiro, sem seleção de arquivo individual, e no modo só de inclusão não captura alteração nem exclusão de arquivos existentes. Portanto, o recorte de origem e a atualização precisam ser desenhados, não presumidos. A ingestão de listas do SharePoint está em Beta na data de verificação desta publicação.

A leitura de que a permissão pertence ao lugar e não ao documento é formulação editorial da CSP Tech, construída a partir do que Microsoft, Atlassian e Databricks documentam sobre cada sistema, e não uma afirmação de nenhuma das três sobre limitação dos produtos dos outros. Cada plataforma faz o que documenta. A brecha está no caminho entre elas, que nenhuma das três governa sozinha.

Sinais de que o seu projeto tem cópias sem governança

•  Existem PDFs de contrato, proposta ou política anexados em itens do Jira. Cada um é uma versão congelada com a regra do projeto, e quase sempre há uma versão mais nova no SharePoint.

•  Ninguém sabe quem decide o acesso aos arquivos ingeridos no Databricks. Se a resposta for que vale a permissão do SharePoint, a premissa contradiz a documentação do conector.

•  A IA do Atlassian responde citando um anexo, e não o documento da biblioteca. É o sinal mais visível de que a cópia virou a fonte de verdade de fato.

•  Não existe política escrita sobre o que pode ser anexado. Sem regra, a conveniência decide, e a conveniência sempre escolhe copiar.

Quando esse rigor é desproporcional

•  Projeto interno sem documento sensível nem participante externo. Se todos que veem o Jira também veem a biblioteca e nada ali é restrito, a cópia custa versão desatualizada, e não exposição.

•  Anexos operacionais de vida curta. Captura de tela de erro, log de teste e evidência de homologação nascem no Jira e não têm original no SharePoint. Esses podem e devem ser anexos.

•  Ingestão de conteúdo público ou já anonimizado. Se o que vai para o Databricks não tem restrição na origem, redeclarar governança fina rende pouco além do controle padrão do catálogo.

Próximo passo

Há um teste de dez minutos que mostra o tamanho da brecha: no seu Jira, busque itens com anexos em PDF nos projetos que envolvem jurídico, compras ou RH e compare a data de cada anexo com a versão do mesmo documento no SharePoint. Cada diferença é uma cópia com regra própria e conteúdo vencido. Solicite um mapa de permissões entre o seu Jira, o seu SharePoint e o seu Databricks com a CSP Tech e receba a leitura do seu caso: onde existem cópias, qual regra cada uma segue e o que precisa mudar na instância e na ingestão para que a permissão volte a pertencer ao lugar certo.

Perguntas frequentes

O Copilot respeita as permissões do SharePoint?

Sim. A Microsoft documenta que o Copilot só mostra dado organizacional que o usuário tem pelo menos permissão de visualizar, e recomenda usar corretamente os modelos de permissão de serviços como o SharePoint. A ressalva é que ele respeita a permissão do lugar onde o conteúdo está. Se uma cópia do documento existe em outro lugar com regra mais aberta, a proteção do original não alcança a cópia. Fonte: Microsoft Learn, Data, Privacy, and Security for Microsoft Copilot, atualizado em agosto de 2026.

Anexar um arquivo do SharePoint no Jira mantém a permissão original?

Não. O anexo passa a seguir as permissões do Jira, ou seja, fica visível para quem pode ver aquele item no projeto, independentemente da restrição que o documento tinha na biblioteca do SharePoint. Além disso, a cópia congela a versão. A prática recomendada para documento com dono e restrição é referenciar o original por link a partir do item do Jira, em vez de anexá-lo.

O conector de SharePoint do Databricks traz as permissões dos arquivos?

Não. A documentação do Lakeflow Connect, atualizada em outubro de 2026, afirma que o conector não ingere as listas de controle de acesso dos arquivos do SharePoint. A governança do conteúdo ingerido precisa ser declarada no Unity Catalog, com concessão restrita por padrão, classificação do conteúdo sensível, máscaras e filtros aplicados na consulta e linhagem até a biblioteca de origem.

O que uma consultoria Jira faz num projeto que usa SharePoint e Databricks?

Desenha a instância Jira para referenciar documentos canônicos em vez de copiá-los, define o que pode e o que não pode ser anexado, revisa os anexos sensíveis existentes e prepara o registro do Jira para ser consumido no Databricks sem levar junto conteúdo que deveria continuar restrito. Junto com a consultoria Databricks, que governa a ingestão no Unity Catalog, fecha as duas brechas por onde a permissão se perde entre os sistemas.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google, Anthropic e Semrush. Revisão técnica por especialistas Atlassian e de dados da CSP Tech (Atlassian Gold Partner, parceira Databricks, Microsoft Gold Partner, participante do Anthropic Partner Network, 34 anos de mercado, produto próprio Power BI for Jira no Atlassian Marketplace).

Fontes (oficiais, acesso out/2026): Microsoft Learn, Data, Privacy, and Security for Microsoft Copilot, atualizado em 18 de agosto de 2026, quanto ao Copilot exibir apenas dados organizacionais para os quais o usuário tem pelo menos permissão de visualização e à recomendação de uso dos modelos de permissão do SharePoint (learn.microsoft.com). Atlassian, How Rovo connector permissions are kept in sync e Connect SharePoint to Teamwork Graph, quanto ao Rovo exibir conteúdo de aplicativos de terceiros apenas para usuários que já têm acesso a ele na origem (support.atlassian.com). Atlassian, documentação de permissões de projeto do Jira quanto à visibilidade de itens e seus anexos (support.atlassian.com). Databricks Documentation, Microsoft SharePoint connector limitations, atualizada em 7 de outubro de 2026, quanto à não ingestão de listas de controle de acesso no nível de arquivo, à ingestão por pasta, unidade, subsite ou site inteiro, ao modo só de inclusão sem captura de alteração e exclusão de arquivos existentes e à ingestão de listas em Beta (docs.databricks.com). Databricks Documentation quanto ao Unity Catalog, com permissões aplicadas a pessoas, notebooks e modelos, máscaras de coluna e filtros de linha na consulta e linhagem automática. A tese de que a permissão pertence ao lugar e não ao documento é formulação editorial da CSP Tech e não constitui afirmação da Microsoft, da Atlassian ou da Databricks sobre limitações dos produtos umas das outras. Nenhum percentual, prazo ou custo foi citado.

Links internos sugeridos: “Consultoria Jira em 2026” (o hub, com a âncora 'consultoria Jira'); “O que faz um especialista Jira” (o papel que desenha a instância); “Sua intranet virou interface de dado” (o digital workplace com SharePoint e Jira); “Governar agentes de IA no Atlassian” (o Rovo e o uso); “Shadow AI na plataforma de dados” (o alcance da credencial legítima); “Dados do Jira no Databricks” (a ingestão do Jira).