Em boa parte das empresas, a IA chegou à rotina antes de qualquer política interna. O analista de service desk resume chamados num assistente; o desenvolvedor gera código em outro, que a TI nem sabe qual é. Cada um jura que rende mais. Na reunião de resultado, ninguém consegue apontar onde esse ganho apareceu no número do time. No Team ’26 Europe, realizado em Amsterdã no início de outubro, a Atlassian chamou esse descompasso de IA single-player e apresentou uma resposta construída em torno da governança de agentes de IA dentro do fluxo de trabalho. 

Quando a IA acelera pessoas e o time continua no mesmo ritmo 

O diagnóstico partiu do próprio cofundador e CEO da Atlassian, Mike Cannon-Brookes, no texto que abriu o evento. Segundo ele, quase toda adoção de IA começa com uma pessoa sozinha, digitando numa janela de chat no próprio notebook. Isso pode deixar aquele profissional mais rápido. O time não sente a diferença. 

A pesquisa State of Teams 2026, da própria Atlassian, ajuda a medir essa distância. Entre os executivos ouvidos, 89% dizem que a IA aumentou a velocidade do trabalho, mas só 6% se sentem seguros para apontar um retorno que valha para a organização inteira. O levantamento ouviu mais de 12 mil profissionais e mais de 170 executivos de empresas da Fortune 1000, e os números estão neste artigo do Teamwork Lab. 

A explicação está na forma como o trabalho anda dentro de uma empresa grande. Escrever código ou montar uma análise ocupa uma fatia pequena do dia. O resto é coordenação, com revisões, aprovações, alinhamentos e espera pela resposta de outra área. A IA acelera a primeira parte e despeja mais volume na segunda, que continua com as mesmas pessoas e os mesmos gargalos. Mesmo nos times que se dizem mais rápidos com IA, a Atlassian estima uma perda de cerca de seis horas por pessoa por semana com metas pouco claras, prioridades que mudam e trabalho duplicado. 

Quem administra um Jira Service Management conhece a versão operacional disso. O atendente responde mais rápido com ajuda da IA, e o chamado continua parado na aprovação do gestor ou na passagem para o time de infraestrutura. O SLA que estoura raramente estoura no atendimento. 

O risco que não aparece no painel: agentes sem dono 

Há um segundo problema, menos visível que o primeiro. Quando cada pessoa usa o próprio assistente, o trabalho feito pela IA acontece fora dos sistemas de registro da empresa. Um desenvolvedor roda um agente no terminal, o agente altera dez arquivos e o card no Jira segue com o status de três dias atrás. Ninguém fica sabendo até o pull request aparecer. 

Para quem responde pela TI, a dúvida que pesa é de responsabilidade. Imagine um agente com acesso ao Confluence que entrega a um colaborador o conteúdo de uma página restrita ao RH. A culpa é de quem configurou o agente ou de quem fez a pergunta? Em muitas empresas, essa resposta ainda não está escrita em lugar nenhum. 

É nesse vácuo que cresce o shadow AI. Ele avança justamente nas áreas em que a TI está mais pressionada, porque quem precisa entregar não espera a política de uso ficar pronta. Proibir costuma empurrar o uso para ferramentas ainda menos controladas. 

O que é o AMP da Atlassian? 

O AMP, sigla de Agentic Multiplayer Protocol, foi o anúncio central do Team ’26 Europe. Pela definição da página oficial, ele é um conjunto de experiências e padrões de design, apoiado em tecnologia própria, que orienta como pessoas e agentes de IA trabalham juntos, dentro e fora da plataforma Atlassian. O nome lembra um padrão técnico como o MCP, mas o pacote vai além da conexão entre ferramentas e entra em regras de visibilidade e de controle. 

Na prática, o agente sai da janela de chat isolada e vai para o board do Jira e para a página do Confluence onde o time já discute o trabalho. A Atlassian organizou o AMP em três camadas. 

Colaboração dentro do fluxo de trabalho 

Um agente pode receber o briefing por um vídeo no Loom ou ser mencionado numa página do Confluence, como se faria com um colega. Também pode entrar direto em workflows do Jira para triar e rotear demandas, enquanto ferramentas como Figma e IDEs se conectam via MCP. No Loom, a gravação feita para o agente transforma a fala e os movimentos na tela em um briefing estruturado, com critérios de aceite, que o agente executa e devolve para revisão. 

Identidade e presença compartilhada 

Todo agente passa a ter um dono identificado e um perfil próprio, e cada alteração fica atribuída a ele em tempo real. Quem edita um documento vê o cursor do agente ao lado do cursor dos colegas. 

Para times de desenvolvimento, o recurso Agent Sessions liga sessões de agentes ao item de trabalho certo no Jira, e a Atlassian indicou que as sessões rodadas localmente, em IDEs e terminais, chegam ao Jira em seguida. Quem já perdeu horas cobrando atualização de status vai entender o valor disso rápido. 

Contexto e governança 

É a camada que mais interessa a quem responde por segurança e compliance. Cada agente trabalha sobre o Teamwork Graph, que conecta o histórico de trabalho guardado nas ferramentas da empresa, e as permissões são delimitadas conforme o caso de uso. 

No exemplo dado por Cannon-Brookes, um agente de RH herda o acesso restrito de quem fez o pedido, enquanto um agente de helpdesk roda com uma conta de serviço própria. Toda atividade fica auditável, com registro de quem acionou o agente e de quais dados ele tocou, e os pontos de aprovação humana ficam embutidos no processo. O controle continua no Atlassian Guard e nas políticas de dados que a empresa já configurou. 

Os anúncios do Team ’26 Europe que mexem com custo e controle 

O AMP veio acompanhado de uma lista longa de novidades. Para um decisor de TI, algumas pesam mais do que outras, e a primeira delas trata de identidade. 

A Atlassian anunciou contas de agente e um inventário de identidades não humanas. Todo agente, app ou conta de serviço, da Atlassian ou de terceiros, recebe uma identidade completa, e o administrador passa a gerenciar esses atores autônomos ao lado das pessoas, com a possibilidade de revogar acessos quando precisar. Em empresas que operam sob a LGPD, saber qual agente acessou qual dado fica mais simples de demonstrar, sem reconstrução manual de logs. 

No contexto, o Teamwork Graph passou a cobrir 7 tipos de contexto e 250 bilhões de objetos conectados, com mais de 80 conectores, entre eles Zoom, Gong, Microsoft Entra ID e Google Identity. Com o novo app Code Search, o grafo lê código-fonte até o nível de função e de classe. Dados estruturados viraram um tipo nativo de contexto, e o Atlassian Insights permite consultar data lakes e data warehouses a partir das ferramentas do time. O app Artifacts guarda o que os agentes produzem em um lugar permanente e governado, que volta a alimentar o grafo. 

Quem acompanha a fatura de IA deve olhar para o novo servidor Atlassian MCP. Ele leva o contexto da Atlassian para ferramentas como Cursor e Claude e, segundo testes internos da própria empresa com modelos Claude, usa até 25% menos tokens nas mesmas tarefas de Jira e Confluence. É um benchmark do fabricante, mas ilustra algo que vale para qualquer projeto de IA, o de que contexto bem entregue custa menos do que contexto despejado. 

O Rovo, por fim, segue disponível em todas as assinaturas pagas para usuários habilitados. Não é raro encontrar ambientes em que ele já está liberado e ninguém definiu para que deveria servir. 

Governança de agentes de IA: por onde começar antes de escalar 

Os anúncios resolvem a parte da plataforma. A parte do processo continua com a empresa, e é nela que muitas iniciativas travam. Para quem está se perguntando como governar agentes de IA na empresa sem frear o time, a sequência a seguir ajuda. 

Comece pelo que já existe. Antes de criar o primeiro agente oficial, mapeie quais assistentes as equipes já usam e com quais dados. Esse levantamento em geral encontra IA em áreas que a TI nem considerava, e sem ele qualquer política de uso fica no papel. 

Em seguida, defina dono e modo de execução para cada agente. Agir com as permissões de quem pede ou com uma conta de serviço própria é uma escolha que a área dona do dado deveria fazer junto com a TI. Um agente que consulta informações de folha de pagamento precisa herdar o acesso de quem pergunta. Já um agente de triagem de chamados pode rodar com conta própria, desde que tudo o que ele faz fique registrado. 

O passo mais negligenciado é arrumar o contexto que o agente vai ler. Um Jira com campos que ninguém sabe explicar e workflows empilhados ao longo dos anos, somado a um Confluence cheio de páginas desatualizadas, produz agentes que respondem com segurança e erram. A própria Atlassian, no material sobre o Teamwork Collection, reconhece que um agente alimentado com dado velho devolve absurdos ditos com convicção. 

Depois vêm os pontos de aprovação humana. Eles precisam estar onde a decisão tem consequência, como uma mudança em produção ou a liberação de acesso a dado sensível. Checkpoint em todas as etapas recria o gargalo que a IA deveria aliviar; sem nenhum, o erro aparece primeiro para o cliente. 

Por último, troque a régua. Contar quantas respostas o assistente gerou diz pouco sobre a operação. O que interessa é tempo de ciclo do chamado e SLA cumprido. 

Para que você possa se aprofundar ainda mais, recomendamos também a leitura dos artigos abaixo: 

Desenvolvimento com IA: 94% usam, só 6% escalam, segundo a Atlassian 

Atlassian Rovo MCP: como dar acesso ao Jira para agentes de IA sem perder o controle 

Jira, SharePoint e Databricks no mesmo projeto: a permissão não viaja com a cópia, e é aí que a governança se perde 

O agente herda o processo em que é colocado 

Os diagnósticos que a CSP Tech faz em ambientes Atlassian mostram isso com frequência. Se os pedidos chegam por e-mail, telefone, WhatsApp e planilha, sem fila nem SLA medido, um agente de triagem só automatiza a desordem. Se o Jira acumulou anos de dívida de configuração, o agente vai ler essa dívida como verdade e repetir o erro em escala. 

Por isso a sequência importa. Primeiro se entende como o trabalho acontece hoje, com as exceções e os atalhos que ninguém documentou. Depois se desenham papéis, fluxos, prioridades, SLAs e indicadores. A plataforma entra no terceiro passo, já com o processo definido, e os agentes chegam por cima de uma base que aguenta o peso. 

Como Gold Solution Partner Atlassian, a CSP Tech trabalha nessa ordem, do diagnóstico do ambiente atual ao desenho de processo, passando pela configuração de Jira, Jira Service Management, Confluence e Rovo, pela integração com os sistemas do cliente e pela sustentação depois do go-live. O objetivo é que todo pedido tenha responsável e prazo, seja ele tratado por uma pessoa ou por um agente, e que qualquer gestor saiba em que ponto ele está. 

A Atlassian colocou agentes no mesmo board que o seu time. Antes de ligar o primeiro, vale saber se esse board conta a verdade sobre a sua operação. 

Se a sua empresa já tem o Rovo liberado e um Jira que cresceu sem padrão, uma conversa com os especialistas da CSP Tech ajuda a identificar o que precisa ser ajustado antes de ampliar o uso de agentes. 

Fale com a CSP Tech: https://www.csptech.com.br/contato