Governar agentes de IA no Atlassian: o que o novo controle central do Rovo faz, e o que ele deixa por sua conta

Guilherme Matos • September 9, 2026

Em agosto de 2026, a Atlassian passou a permitir que administradores de organização gerenciem e governem agentes Rovo a partir de um local central no Atlassian Administration. Segundo as notas de lançamento, o recurso dá visibilidade a todos os agentes existentes na organização, filtrados por site, e permite definir uma política de acesso padrão para agentes recém-criados, com o objetivo declarado de garantir mais segurança e conformidade sem precisar procurar site a site. É um avanço real de plataforma, e também um lembrete de escopo: o controle governa quem pode acessar e usar cada agente, não o que cada agente consegue alcançar no dado da empresa. A primeira decisão é de administração do Atlassian. A segunda é de governança de dados, e continua sendo responsabilidade de quem desenha o acesso ao dado, agente ou não.


Por que esse controle chegou agora


Agentes de IA deixaram de ser experimento e passaram a se multiplicar dentro das ferramentas de trabalho. Onde há muitos agentes criados por times diferentes, aparece um problema clássico de administração: ninguém consegue mais responder quantos existem, quem os criou e quem pode usá-los. A resposta da Atlassian a isso é o padrão que a plataforma já aplicou a outros objetos, o de trazer a visão para um ponto central.


O movimento vem acompanhado de sinais na mesma direção. As notas de lançamento de agosto também registram a substituição da abordagem de lista de permitidos por uma de lista de bloqueados na página de acesso ao Rovo, o que torna mais fácil enxergar onde os recursos estão desabilitados na organização. São mudanças de governança de uso, e elas respondem à pergunta de quem pode. É a pergunta certa, e não é a única.


A tese deste guia: governar quem usa um agente e governar o que um agente alcança são duas camadas distintas, e o novo controle central resolve a primeira. Um agente com acesso de uso restrito a poucas pessoas, mas com alcance amplo sobre dado sensível, continua sendo um risco que o painel de agentes não vê, porque esse alcance é definido na camada de dado, não na de administração de IA. Confundir as duas leva à sensação de controle sem o controle correspondente.


O que o controle central do Rovo faz

As capacidades acima são reproduzidas das notas de lançamento oficiais do Atlassian Administration de agosto de 2026. Elas descrevem controles de acesso e de uso de agentes, centralizados na administração da organização, e não controles sobre o alcance de leitura de cada agente no dado corporativo.

A camada que o painel de agentes não governa


A pergunta que o novo controle não responde é a mais consequente em ambiente com dado sensível: se este agente for acionado, o que exatamente ele consegue ler? Governar quem pode usar um agente limita o número de pessoas que o acionam. Não limita o alcance do que o agente devolve quando acionado, e esse alcance é herdado da estrutura de acesso ao dado, não da configuração do agente.


Essa é a camada de governança de dados, e ela vive onde o dado vive. Em ambiente de dados corporativo, o alcance de um agente deveria ser definido pela mesma estrutura que governa o acesso humano, e não por uma credencial criada à parte para o agente funcionar. A documentação da Databricks descreve o Unity Catalog aplicando as mesmas permissões a pessoas, notebooks e modelos, com controle de acesso, linhagem e auditoria centralizados, e controles como máscaras de coluna e filtros de linha aplicados no momento da consulta, de modo que o tratamento de dado sensível aconteça independentemente de quem, ou do que, consulta. É a resposta técnica à pergunta que o painel de agentes deixa em aberto.

A distinção entre governar o uso do agente e governar o alcance do agente no dado é formulação editorial da CSP Tech, construída a partir do escopo declarado do recurso da Atlassian e das capacidades documentadas de governança de dados. Não é uma limitação afirmada pela Atlassian sobre o próprio produto.

As duas camadas de governança de agente, lado a lado

A segunda linha é a que amarra a novidade ao trabalho de instância. O controle central diz quem pode usar; o registro de que o agente fez algo, com dono e histórico, continua morando na configuração da instância, e é ali que a ação assistida deixa rastro auditável ou não deixa. As três perguntas juntas descrevem a governança completa de um agente, e nenhuma delas é resolvida sozinha pelo painel novo.

O que muda para quem administra o Atlassian


A chegada do controle central não reduz o trabalho de governança, ele o reorganiza. Três frentes passam a ser tratáveis a partir da administração da organização, e três continuam dependendo de desenho fora dela.


     Passa a ser central: o inventário. Saber quantos agentes existem e onde deixa de exigir varredura site a site. É a base de qualquer governança, e agora está disponível.


     Passa a ser central: a política de acesso padrão. Agente novo já nasce com uma política, em vez de herdar acesso amplo por omissão. Isso corrige o hábito mais comum, que é o acesso concedido por conveniência.


     Continua de instância: o registro da ação. O que o agente faz precisa virar item com dono e histórico, e isso é configuração de tipos de item, workflow e trilha na própria instância.


     Continua de dados: o alcance de leitura. O que o agente consegue ler é definido na plataforma de dados, com o mesmo modelo de permissão do acesso humano e tratamento aplicado na consulta.


Por que isso pede especialista de instância e de dados ao mesmo tempo: o controle central é operado por quem administra o Atlassian, o registro da ação é desenhado por quem configura a instância, e o alcance no dado é governado por quem desenha o acesso na plataforma de dados. As três precisam conversar, ou a empresa fica com a sensação de governança que o painel novo oferece sem a substância que falta nas outras duas camadas. A CSP Tech atua como Atlassian Gold Partner na instância e na administração, e como especialistas na governança de dados que define o alcance, o que permite tratar a governança do agente como um desenho único.


Quando o controle central já basta


     Agentes que só leem dado público interno. Se o alcance de leitura não inclui dado sensível, governar quem usa é suficiente, e a camada de dado tem pouco a acrescentar.


     Agentes que não executam ação em sistema. Se o agente apenas responde e não altera registro nem dispara fluxo, a camada de registro de ação perde peso, e o controle de uso cobre a maior parte do risco.


     Organização pequena, com poucos agentes e permissões já estreitas. Quando o alcance já é mínimo por desenho, o inventário central e a política padrão resolvem, e o esforço adicional rende pouco.


Perguntas frequentes


Como governar agentes Rovo no Atlassian?

Desde agosto de 2026, administradores de organização podem gerenciar e governar agentes Rovo de um local central no Atlassian Administration, com visibilidade de todos os agentes filtrados por site e definição de uma política de acesso padrão para agentes recém-criados. O acesso granular por agente também pode ser gerido ali. Segundo a Atlassian, o objetivo é garantir mais segurança e conformidade sem procurar site a site. Esse controle governa quem pode usar o agente.


O controle central do Rovo governa o que o agente pode acessar nos dados?

O recurso, conforme descrito nas notas de lançamento, governa o acesso e o uso dos agentes, ou seja, quem pode usá-los. O que um agente consegue ler no dado corporativo é definido pela estrutura de acesso da plataforma de dados, não pela administração de agentes. O desenho recomendado é que o alcance do agente siga o mesmo modelo de permissão do acesso humano, com tratamento de dado sensível aplicado no momento da consulta, de modo que a proteção não dependa de o agente cooperar.


Qual a diferença entre governar o uso e governar o alcance de um agente de IA?

Governar o uso limita quem pode acionar o agente, e é o que o controle central do Rovo faz. Governar o alcance limita o que o agente consegue ler ou fazer quando acionado, e isso vive em duas camadas fora do painel de agentes: o registro da ação, que mora na configuração da instância, e o acesso ao dado, que mora na plataforma de dados. Um agente com uso restrito e alcance amplo sobre dado sensível continua sendo um risco que o controle de uso não enxerga.


O que muda para o administrador Atlassian com a governança central de agentes?

O trabalho é reorganizado, não reduzido. Passam a ser tratáveis da administração central o inventário de agentes e a política de acesso padrão para novos agentes. Continuam dependendo de desenho fora da administração de IA o registro rastreável do que o agente faz, que é configuração de instância, e o alcance de leitura sobre o dado, que é governança da plataforma de dados. As três camadas precisam conversar para que a governança do agente seja completa.


Próximo passo


Se a sua empresa usa agentes no ambiente Atlassian, o novo controle central resolve uma pergunta importante e vale ser adotado. Antes de dar o tema por encerrado, porém, vale fazer as outras duas: o que cada agente registra quando age, e o que cada agente consegue ler. Solicite uma avaliação de governança de agentes de IA no seu Atlassian com a CSP Tech e receba o mapa das três camadas no seu ambiente: quem usa, o que fica registrado e qual o alcance real de cada agente sobre o seu dado.

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 set/2026): Atlassian, notas de mudanças do Atlassian Cloud referentes ao período de agosto de 2026 (confluence.atlassian.com/cloud/blog), quanto ao recurso que permite a administradores de organização gerenciar e governar agentes Rovo de um local central no Atlassian Administration, com visibilidade de todos os agentes filtrados por site, definição de política de acesso padrão para agentes recém-criados e gestão de acesso granular por agente, com o objetivo declarado de melhorar segurança e conformidade sem procurar site a site; e quanto à substituição da abordagem de lista de permitidos por lista de bloqueados na página de acesso ao Rovo. Databricks Documentation (docs.databricks.com), quanto ao Unity Catalog aplicando as mesmas permissões a pessoas, notebooks e modelos, com controle de acesso, linhagem e auditoria centralizados, e a máscaras de coluna e filtros de linha aplicados no momento da consulta. A distinção entre governar o uso do agente e governar o alcance do agente no dado, bem como a organização em três camadas, são formulação editorial da CSP Tech, construídas a partir do escopo declarado dos recursos citados, e não constituem afirmação da Atlassian sobre limitações do próprio produto. Nenhum número fora das fontes citadas foi utilizado. Este conteúdo trata de arquitetura e governança técnica e não constitui aconselhamento jurídico.

Fale com a CSP Tech

.

Por Guilherme Matos 10 de setembro de 2026
Meta description Como escolher consultoria de IA, Databricks e Jira sem pagar integração duas vezes. 7 critérios de decisão para gestor de TI, com dados Gartner e MIT.
suporte proativo com IA, o que é suporte proativo em TI, rovo jira service management
Por Romildo Burguez 8 de setembro de 2026
A Gartner destacou o suporte proativo com IA como diferencial da Atlassian em ITSM. Entenda o que isso exige da sua central de serviços e como aplicar
Por Guilherme Matos 8 de setembro de 2026
O Jira Cloud Migration Assistant é a ferramenta oficial e gratuita da Atlassian para mover dados de Server ou Data Center para o Cloud, descrita pela própria documentação como o método mais fácil e confiável. Seu princípio de operação é importante e costuma ser mal entendido: ele adiciona dados ao site de Cloud sem sobrescrever o que já existe, o que permite migrar para um site novo ou para um site com dados. O ponto que derruba projetos não está no que ele leva, e sim no que ele não leva e no único caso em que ele sobrescreve. Alguns campos não são migrados e precisam ser recriados e preenchidos manualmente depois, por importação de CSV, e existe um cenário específico de sobrescrita ao migrar tipos de item gerenciados que foram renomeados. Quem trata migração como copiar tudo de um lado para o outro descobre a diferença quando o histórico chega incompleto e o indicador do outro lado não bate.
Por Guilherme Matos 4 de setembro de 2026
Contratar consultoria Jira em 2026 é diferente de contratar em 2020, e a diferença não está na ferramenta: está no que depende dela. Uma instância corporativa hoje costuma alimentar um pipeline analítico, sustentar áreas de negócio além da TI e registrar decisões e ações de sistemas de IA. Isso significa que uma decisão de configuração feita em quinze minutos pode quebrar um indicador executivo, travar a criação de campos novos por limite de plataforma ou deixar sem rastro a ação de um agente. As oito perguntas a seguir foram escolhidas porque atravessam esses três domínios, e porque cada uma tem uma resposta que qualifica e um sinal de alerta que desqualifica. Nenhuma delas exige que o comprador seja especialista: basta saber o que uma boa resposta contém.
Adoção de agentes de IA, Claude Code na engenharia de software, produtividade de devs com IA
Por Romildo Burguez 3 de setembro de 2026
90% dos devs usam IA toda semana, mas a fila de TI segue igual. Entenda por que a adoção de agentes de IA sozinha não resolve, veja como aplicar.
Por Guilherme Matos 3 de setembro de 2026
A Atlassian passou a impor limites de dados no Jira Cloud . Desde março de 2026 vale o limite de 700 campos por espaço, calculado com base nos campos incluídos nos esquemas de configuração de campos associados a ele, e o de 150 tipos de trabalho por espaço. A partir de setembro de 2026 entra um conjunto adicional, que inclui 20.000 opções por campo, 150 workflows por esquema, 200 status por workflow e 100 prioridades por espaço, entre outros. A documentação é explícita ao distinguir dois conceitos: guardrails são limiares recomendados, boas práticas não obrigatórias, enquanto limites são limiares que não podem ser excedidos. E é igualmente explícita sobre a consequência, que é menos dramática do que o alarme sugere: configurações existentes que excedam os limites continuam funcionando e nenhum dado é apagado, mas o espaço fica impedido de associar campos ou tipos de trabalho adicionais até que a redução aconteça. O ponto deste artigo é outro: o limite é o sintoma, e a causa é que campo customizado é decisão de modelagem de dados tomada em quinze minutos por quem não modela dados.
gartner Magic Quadrant ITSM, atlassian líder em itsm, jira service management gartner 2026
Por Romildo Burguez 1 de setembro de 2026
Ser líder no Gartner Magic Quadrant ITSM comprova a força da plataforma, mas não garante uma operação estável. Veja o que muda na prática e como aplicar
Consultoria Jira, Governança de Dados, Governança de IA
Por Guilherme Matos 31 de agosto de 2026
O mercado vende governança de IA como programa novo, com comitê novo e política nova. Boa parte do que a norma pede já existe na sua operação de segurança e de dados. Veja o que estender, em vez de construir do zero.
Código gerado por IA, quantos códigos gerados por IA têm falhas de segurança; processo de revisão
Por Romildo Burguez 27 de agosto de 2026
Quase metade do código gerado por IA carrega falha de segurança e a validação ainda não evoluiu no mesmo ritmo. Entenda o que muda e veja como aplicar