Conectores sincronizados por usuários: o que administrar enquanto o recurso é preview

Quem administra Microsoft 365 conhece bem o modelo tradicional de conector: o admin configura uma vez, define o escopo de crawl e o conteúdo fica disponível para todo mundo que tem permissão. Os conectores sync gerenciados pelo tenant funcionam assim até hoje.

Em preview, a Microsoft apresentou um modelo novo: o conector sincronizado por autosserviço, ou self-serve sync connector. A diferença de longe mais importante é quem decide conectar. Não é mais o admin. É cada usuário, com as próprias credenciais, para o próprio conteúdo. E isso muda o que significa "administrar" conectores.

Eu fui ler a documentação para entender o que muda no dia a dia de quem administra o tenant. O que encontrei é o que compartilho aqui.

O que é um conector sync de autosserviçoLink para esta seção

Diferente dos conectores que o admin configura para o tenant inteiro, os self-serve sync connectors são publicados pela Microsoft e aparecem para o usuário diretamente no cliente do Copilot, seja o aplicativo desktop ou o Web client em m365.cloud.microsoft (fonte: Self-serve sync connectors overview ((abre em nova aba))).

O usuário encontra o conector, clica em Connect, faz a autenticação com as credenciais dele no sistema de origem (via OAuth 2.0 de três pernas, com delegação) e o conteúdo ao qual ele já tem acesso começa a ser sincronizado para o Microsoft Graph. Só ele enxerga esse conteúdo. Não há compartilhamento entre usuários. Não há indexação cruzada. Cada conexão é individual e isolada (fonte: Manage self-serve sync connector availability ((abre em nova aba))).

No preview, as fontes de dados suportadas são duas: Confluence Cloud (wikis e posts de blog) e Jira Cloud (itens de trabalho). A Microsoft anunciou que planeja adicionar mais fontes, mas não há lista nem cronograma publicados (fonte: Self-serve sync connectors overview ((abre em nova aba))).

O que o admin ainda controlaLink para esta seção

A primeira reação de quem administra um tenant ao ouvir "o usuário conecta por conta própria" costuma ser de preocupação. E faz sentido. Mas a Microsoft não tirou o admin da jogada. Ela mudou o papel.

No centro de administração do Microsoft 365, em Copilot > Connectors, os conectores de autosserviço aparecem na lista Your connections como conectores habilitados pela Microsoft. Por padrão, eles vêm ligados para o tenant inteiro. O admin pode:

• Desabilitar um conector completamente. Quando isso acontece, a sincronização para e o conteúdo indexado é apagado para todos os usuários (fonte: Manage self-serve sync connector availability ((abre em nova aba))).
• Usar staged rollout para liberar o conector apenas para grupos específicos do Microsoft Entra ID. Quem não estiver no grupo simplesmente não vê o conector disponível (fonte: Manage self-serve sync connector availability ((abre em nova aba))).
• Ver estatísticas de adoção, como quantos usuários conectaram cada fonte (fonte: Manage self-serve sync connector availability ((abre em nova aba))).

Para acessar esses controles, é preciso ser Global Administrator ou AI Administrator (fonte: Manage self-serve sync connector availability ((abre em nova aba))).

A janela de revisão de sete diasLink para esta seção

Um detalhe que eu acho particularmente inteligente: quando um novo conector de autosserviço aparece pela primeira vez no centro de administração, ele fica visível apenas para admins por pelo menos sete dias corridos antes de ser liberado para os usuários. Durante essa janela, o admin pode revisar o conector, desabilitá-lo se ele não atender aos requisitos da organização ou configurar o staged rollout. Se o conector for desabilitado nesse período, ele nunca chega aos usuários (fonte: Manage self-serve sync connector availability ((abre em nova aba))).

Isso dá uma margem para avaliar cada nova fonte antes que ela entre em produção. No seu tenant, vale a pena monitorar a lista de conectores com regularidade para não perder essa janela.

Segurança e compliance: o que está documentadoLink para esta seção

A documentação lista cinco pontos que merecem atenção de quem pensa em governança:

1. A conexão usa a identidade do próprio usuário. As permissões são aplicadas pelo sistema de origem. O usuário só vê no Copilot o que ele já pode ver na fonte.
2. A autenticação é OAuth 2.0 delegado, com tokens armazenados de forma segura. O usuário pode revogar o acesso a qualquer momento desconectando o conector.
3. O conteúdo é indexado por usuário. Não há acesso cruzado entre usuários.
4. Só é indexado o conteúdo dentro da janela de retrospectiva do conector, que é de aproximadamente 90 dias.
5. Quando o usuário desconecta ou o admin desabilita o conector, o conteúdo indexado é deletado e a sincronização para (fonte: Manage self-serve sync connector availability ((abre em nova aba))).

Esses pontos estão documentados como funcionais para o preview. Se a sua organização tem requisitos mais específicos de compliance, vale testar cada um deles no seu ambiente antes de liberar qualquer conector.

Convivência com conectores de tenantLink para esta seção

Uma dúvida comum é: se eu já tenho um conector configurado para o tenant para a mesma fonte, o que acontece? A resposta depende de como o conector de tenant foi implantado.

Se o conector de tenant está configurado para todos os usuários, ninguém no tenant consegue usar o conector de autosserviço para aquela fonte. Se o conector de tenant está em staged rollout, os usuários que fazem parte do rollout não veem o conector de autosserviço. Os demais usuários podem usar o de autosserviço normalmente (fonte: Manage self-serve sync connector availability ((abre em nova aba))).

E se os dois tipos de conexão existem para a mesma fonte e um usuário se enquadra nos dois cenários? O Copilot prioriza o resultado do conector de tenant. A fonte aparece como uma entrada única na interface (fonte: Manage self-serve sync connector availability ((abre em nova aba))).

O que administrar hojeLink para esta seção

Com o recurso em preview, acho que a abordagem certa é de avaliação controlada. Algumas ações práticas:

• Mapeie quem no seu time tem o papel de AI Administrator ou Global Administrator. Sem essas permissões, ninguém consegue nem ver os conectores de autosserviço no centro de administração.
• Defina uma política para a janela de revisão de sete dias. Quem vai avaliar cada novo conector? Qual o critério para liberar ou bloquear?
• Considere usar staged rollout para liberar os conectores primeiro para um grupo piloto. Isso permite observar o comportamento real antes de expor todo o tenant.
• Comunique com os usuários. Se o conector de autosserviço estiver disponível, explique como ele funciona, o que é sincronizado e como desconectar. A transparência evita surpresas.
• Monitore as estatísticas de adoção. O centro de administração mostra quantos usuários conectaram cada fonte. Esse dado ajuda a decidir se faz sentido migrar para um conector gerenciado pelo tenant.

O que ainda não dá para saberLink para esta seção

A documentação deixa claro que o recurso está em preview e disponível para um conjunto limitado de clientes. Não há informação publicada sobre preço, SKU necessária, cronograma de disponibilidade geral ou quais serão as próximas fontes de dados suportadas. Também não há detalhes sobre ferramentas de auditoria para rastrear quais usuários conectaram o quê, além do contador de adoção.

Se a sua organização depende de trilha de auditoria detalhada para conformidade regulatória, esse é um ponto para testar e validar com a Microsoft antes de depender do recurso.

Para fecharLink para esta seção

Os conectores sincronizados por autosserviço representam uma mudança de paradigma na administração de conectores do Copilot. O admin sai do papel de configurador único e entra no papel de guardião: habilita ou desabilita fontes, define quem pode ver cada conector e monitora a adoção. Quem conecta, autentica e gerencia o conteúdo é o usuário.

Para organizações que já têm conectores de tenant configurados, a convivência é pacífica e bem definida. Para quem ainda não usa conectores, esse modelo de autosserviço pode ser uma porta de entrada de baixo atrito para testar o Copilot com dados externos.

Como todo recurso em preview, o conselho é testar, validar e planejar. Mas não ignorar: o modelo de conector sincronizado por usuário veio para ficar, e entender ele agora evita correria quando sair da preview.