Jira em sistema cooperativo de crédito: uma instância por cooperativa ou uma para o sistema inteiro?

Guilherme Matos • November 12, 2026

This is a subtitle for your new post

Em um sistema cooperativo de crédito, a escolha entre uma instância do Jira para o sistema inteiro e uma instância por cooperativa define quem governa processo e dado, e por isso deveria acompanhar a governança que o próprio sistema já escolheu para a segurança cibernética. A Resolução CMN 4.893/2021 admite política de segurança cibernética única para o sistema cooperativo de crédito. Quando o sistema adota essa política única, padrões centrais e evidência consolidada pesam mais do que a autonomia local, e a instância única ou por central tende a servir melhor. Quando cada cooperativa mantém política própria, instâncias separadas fazem mais sentido. No Jira Cloud, só o plano Enterprise reúne várias instâncias em um mesmo plano, com limite de 150.


Como o sistema cooperativo se organiza, e por que isso pesa no Jira


O Banco Central descreve as cooperativas de crédito como organizadas em até três níveis. As singulares operam diretamente com os associados. As centrais prestam serviços às filiadas, como aplicação centralizada de recursos e consultoria técnica. As confederações reúnem as centrais. No levantamento publicado pelo Banco Central no Estudo Especial nº 83, com dados de dezembro de 2019, eram 875 singulares, 34 centrais e quatro confederações, além de 213 singulares independentes, sem vínculo com central.


Essa estrutura faz com que o mesmo processo, uma mudança em sistema, um projeto regulatório ou o atendimento de um incidente, passe por mais de um nível de decisão. A confederação ou a central costuma definir padrões e fornecer tecnologia, enquanto a singular executa e responde ao seu próprio conselho. A arquitetura do Jira precisa refletir quem define o fluxo, quem pode alterá-lo e quem precisa enxergar o resultado consolidado.


Tese da CSP Tech: o desenho certo do Jira em um sistema cooperativo nasce da governança que o sistema já decidiu ter, e o sinal mais objetivo dessa decisão é a política de segurança cibernética. Se o sistema optou por política única, os controles e as evidências precisam ser padronizados e consultáveis de forma consolidada, e espalhar o Jira em dezenas de instâncias autônomas trabalha contra isso. Se cada cooperativa mantém política própria, uma instância única impõe uma centralização que a governança do sistema não pediu.


O que a Resolução 4.893 permite ao sistema cooperativo


A Resolução CMN 4.893, de 26 de fevereiro de 2021, se aplica às instituições autorizadas a funcionar pelo Banco Central, e as cooperativas de crédito não estão entre as exceções do parágrafo único do artigo 1º. O artigo 2º, parágrafo 2º, admite a adoção de política de segurança cibernética única por conglomerado prudencial e por sistema cooperativo de crédito. O parágrafo 3º exige que a instituição que deixa de ter política própria formalize essa opção em reunião do conselho de administração ou, na falta dele, da diretoria.


A política única concentra a definição dos controles, mas cada cooperativa continua sujeita a eles e precisa demonstrar que os aplica. Na prática, isso cria uma demanda por evidência padronizada: os mesmos tipos de registro de incidente, de mudança e de acesso, organizados de forma que a área responsável pela política consiga consultar todas as cooperativas. A revisão da norma pela Resolução CMN 5.274, de dezembro de 2025, reforçou essa necessidade ao exigir trilhas de auditoria do processamento fim a fim dos dados.


Os três desenhos possíveis

Instância única para o sistema inteiro


Todas as cooperativas trabalham no mesmo Jira, separadas por espaços, permissões e esquemas. A Atlassian resume a vantagem desse modelo como ter todo mundo trabalhando junto no mesmo lugar. Para o sistema cooperativo, o ganho prático está em fluxos padronizados, relatórios consolidados sem integração e uma única configuração para auditar. O perfil ideal é o sistema com política de segurança única, tecnologia fornecida pela central ou pela confederação e processos que já são iguais entre as cooperativas. A limitação está na administração: qualquer mudança de esquema afeta todas as cooperativas, e o isolamento entre elas depende inteiramente do desenho de permissões, que precisa ser revisado sempre que uma cooperativa entra, sai ou se incorpora a outra.


Uma instância por cooperativa


Cada singular tem o seu Jira. A Atlassian aponta como vantagens de múltiplas instâncias a administração delegada, o tratamento diferente de tipos de dado, com controle de acesso, nível de auditoria e localização por instância, e a assinatura de apps do Marketplace separada por instância. O perfil ideal é o sistema em que cada cooperativa mantém política própria, decide os próprios processos e tem equipe para administrar a ferramenta. A limitação aparece na escala e na visão consolidada. Nos planos Free, Standard e Premium, cada assinatura dá direito a uma instância, e o Enterprise reúne até 150 instâncias no mesmo plano, limite que um sistema com muitas singulares pode ultrapassar. A visão do sistema passa a depender de uma camada de dados que leia todas as instâncias.


Instância por central, com padrões definidos pela confederação


Cada central opera uma instância para as suas filiadas, seguindo padrões de fluxo, de campos e de nomenclatura definidos pela confederação. O modelo combina autonomia regional com um vocabulário comum, e reduz o número de instâncias a algo próximo do número de centrais. O perfil ideal é o sistema de três níveis em que as centrais já prestam serviços de tecnologia às filiadas. A limitação é que os padrões só se mantêm com governança ativa: sem um dono na confederação que aprove mudanças de esquema, as instâncias divergem em poucos meses e a consolidação volta a exigir tradução de dados.


Critérios para decidir


Política de segurança cibernética. É o primeiro critério porque já foi decidido pelo sistema e registrado em ata. Política única aponta para padronização e evidência consolidada; políticas próprias apontam para autonomia.


Grau de padronização dos processos. Se mudança, incidente e projeto regulatório seguem o mesmo fluxo em todas as cooperativas, uma configuração comum reduz trabalho. Se cada cooperativa tem fluxos próprios por bons motivos, forçar um esquema único gera exceções que ninguém consegue manter.


Quem precisa ver o consolidado. A confederação, a central, a auditoria e a área responsável pela política de segurança precisam consultar dados de várias cooperativas com frequência? Quanto maior essa necessidade, maior o custo de separar instâncias e reconstruir a visão por integração.


Escala e plano. O número de cooperativas que terão Jira, comparado ao limite de 150 instâncias do plano Enterprise, define se o modelo de uma instância por cooperativa é viável dentro de um único plano.


Apps e custo. Apps do Marketplace são assinados por instância. Em muitas instâncias, um app usado por todas as cooperativas é pago muitas vezes, o que precisa entrar na conta antes da decisão.


Localização e tratamento do dado. Instâncias separadas permitem tratar dados de forma diferente, inclusive quanto à localização. A lista de locais de residência de dados da Atlassian muda com o tempo e deve ser conferida no momento da decisão.


Por que a escolha fica cara de reverter


A arquitetura de instâncias costuma ser decidida no início, quando o Jira atende poucas áreas, e revista anos depois, quando o sistema cresceu. Juntar instâncias separadas ou dividir uma instância única exige migrar projetos, usuários, histórico, anexos e configurações de apps, com risco de perder vínculos entre itens e de quebrar automações e relatórios. Em cooperativa, ainda há o efeito das incorporações: quando uma singular incorpora outra, a arquitetura precisa absorver a mudança sem perder a evidência do que cada uma registrou antes. Decidir com base na governança do sistema, e não apenas no número de usuários de hoje, reduz a chance de uma migração forçada.


A camada regulatória, com a ressalva devida


A Resolução 4.893 não trata de ferramentas e não exige nenhum desenho específico de Jira. O que ela exige são controles, registros e evidências, e o desenho da ferramenta só facilita ou dificulta a demonstração. A leitura de que a política única pede evidência padronizada é uma interpretação editorial da CSP Tech sobre o efeito prático da norma, e a definição do que cada cooperativa precisa demonstrar cabe às áreas de compliance, riscos e jurídico do sistema, junto com a auditoria.


Quando essa discussão é desproporcional


Uma singular independente, sem vínculo com central e com uma única área usando o Jira, não precisa desse nível de análise: uma instância própria resolve. O mesmo vale para o sistema em que o Jira atende só o time de desenvolvimento da central, sem uso pelas cooperativas. E, se o sistema está prestes a trocar de ferramenta ou de plataforma de nuvem, a decisão de arquitetura deve esperar essa definição, porque migrar duas vezes custa mais do que esperar alguns meses.


Perguntas frequentes


Uma cooperativa de crédito pode adotar a política de segurança cibernética da central ou do sistema?

Sim. A Resolução CMN 4.893/2021, no artigo 2º, parágrafo 2º, admite política de segurança cibernética única para o sistema cooperativo de crédito. A instituição que deixa de ter política própria precisa formalizar essa opção em reunião do conselho de administração ou, na falta dele, da diretoria, conforme o parágrafo 3º.


Quantas instâncias do Jira Cloud uma organização pode ter?

Nos planos Free, Standard e Premium, cada assinatura dá direito a uma instância. O plano Enterprise permite até 150 instâncias no mesmo plano e inclui os recursos do Atlassian Guard Standard, segundo a documentação da Atlassian. Acima disso, ou em planos sem Enterprise, cada instância adicional é uma assinatura separada.


Instância única do Jira ou uma por cooperativa: qual escolher?

Depende da governança do sistema. Instância única ou por central tende a servir melhor quando o sistema tem política de segurança única, processos padronizados e necessidade de visão consolidada. Uma instância por cooperativa faz mais sentido quando cada uma mantém política própria, processos próprios e equipe para administrar a ferramenta.


É possível juntar ou separar instâncias do Jira depois?

É possível, mas exige migrar projetos, usuários, histórico, anexos e configurações de apps, com risco de perder vínculos entre itens e quebrar automações e relatórios. Por isso a arquitetura deve ser decidida com base na governança do sistema e no crescimento esperado, e não só no número de usuários atual.


Próximo passo


Faça um teste de dez minutos: verifique na ata do conselho se a sua cooperativa adotou a política de segurança cibernética do sistema ou mantém política própria, e compare com a forma como o Jira está organizado hoje. Se a política é única e o Jira está espalhado em instâncias que ninguém consulta em conjunto, ou se a política é própria e a cooperativa depende de uma configuração que não controla, a arquitetura está desalinhada com a governança. Fale com um especialista CSP em consultoria Jira para desenhar a arquitetura do sistema antes que a próxima incorporação ou auditoria force a decisão.


Leituras relacionadas


Jira e regulação no setor financeiro



Configuração, governança e dados do Jira


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, 38 anos de mercado, produto próprio Power BI for Jira no Atlassian Marketplace).


Fontes (acesso em 12/11/2026): Banco Central do Brasil, Estudo Especial nº 83/2020, “Modelo de negócios de cooperativas de crédito”, dados de dezembro de 2019. Resolução CMN nº 4.893, de 26/02/2021, art. 1º e art. 2º, §§ 2º e 3º. Resolução CMN nº 5.274, de 18/12/2025. Atlassian Support, “What are the benefits of multiple instances?” e “What is an Enterprise plan?”. Os três desenhos, os critérios de decisão e a leitura da política única como demanda por evidência padronizada são formulação editorial da CSP Tech. Este conteúdo não constitui aconselhamento jurídico ou regulatório.


Fale com a CSP Tech

.

Por Guilherme Matos • 10 de novembro de 2026
Com IA, o gestor de banco pergunta ao dado em linguagem natural em vez de esperar o relatório. Veja o que muda no time de dados com o Genie do Databricks: curadoria, testes de precisão, revisão de respostas e o histórico de perguntas como fila de demanda.
Por Guilherme Matos • 9 de novembro de 2026
Banco, cooperativa e seguradora já usam mais IA do que a TI registrou. Veja o que um inventário de IA precisa conter para servir de evidência à auditoria e ao Banco Central, de onde vêm os itens e onde manter o registro vivo no Jira Service.
Por Guilherme Matos • 5 de novembro de 2026
A Resolução 4.893 pede que o Banco Central saiba onde os dados podem ser processados. No Databricks, os recursos de IA seguem a área geográfica do workspace, que pode ir além do Brasil. Veja o que mapear antes de contratar e como configurar.
Por Guilherme Matos • 4 de novembro de 2026
Só 19% dos bancos percebiam retorno da IA em 2025. Veja os cinco pontos que travam a escala, o que a regulação já exige e por que a resposta passa pela governança de dados.
Por Guilherme Matos • 3 de novembro de 2026
A CSP Tech participou do Inovatech Executive Summit 2026, realizado em 27 de outubro no WTC São Paulo, como patrocinadora do encontro. Às 9h50, no Plenário, Lúcio Matias, Head de IA da CSP Tech , apresentou a palestra “O orçamento de inovação está preso no legado”, sobre um problema que aparece em quase toda conversa com CIOs: uma parte relevante do orçamento de TI já tem destino antes de qualquer decisão, porque precisa manter funcionando o que já existe. A mensagem central foi que a IA generativa acelera tudo, inclusive o erro, quando não conhece o sistema em que vai mexer. Por isso, a ordem de uso importa: primeiro usar a IA para entender o legado, com evidência registrada , e só depois para alterá-lo com governança e custo sob controle . No mesmo dia, a CSP Tech recebeu lideranças de tecnologia em um Almoço Executivo. Um marco para a CSP Tech: levar o debate para quem decide o orçamento Em 38 anos de mercado, a CSP Tech acumulou projetos de desenvolvimento, modernização, dados e plataformas Atlassian e Microsoft em empresas onde o sistema mais crítico costuma ser também o mais antigo. Levar essa experiência ao palco de um encontro de lideranças de tecnologia tem um peso especial para a empresa, porque coloca a discussão técnica diante de quem aprova o orçamento e responde pelo resultado dele. O Inovatech Executive Summit 2026 se propôs a discutir o que 2027 vai exigir da liderança de tecnologia, com palestras, painéis e casos sobre alocação de capital, IA, agentes, segurança e orçamento. A palestra da CSP Tech entrou nessa agenda com um recorte prático: antes de discutir quanto investir em IA, vale descobrir quanto do orçamento já está comprometido e por quê. A CSP Tech agradece a presença de todas as lideranças que participaram do Almoço Executivo e das conversas ao longo do dia. Foram trocas francas sobre o que funciona e o que ainda trava a adoção de IA nas empresas, e boa parte do que está neste texto nasceu delas. Tese da CSP Tech: o orçamento fica preso no legado quando a empresa perde o entendimento do próprio sistema, porque toda decisão sobre ele passa a ser tomada sem evidência e com margem de segurança cara. A ordem de uso da IA decide se ela libera ou consome orçamento: primeiro reconstruir o entendimento do sistema, com registro auditável e sem alterar código; só então mudar o código, com o contexto certo, modelo escolhido por tarefa e custo medido por entrega. O que preocupa as lideranças de tecnologia presentes no Summit A lista de participantes do evento trazia uma pergunta aberta: quais têm sido os maiores desafios para tecnologia e inovação nos tempos atuais. Quase metade das respostas cita IA, seja na adoção, na escala, no uso de agentes ou na IA generativa. Governança, segurança, risco e regulação aparecem em segundo plano, assim como custo, ROI, investimento e valor gerado. Na prática, a IA raramente aparece sozinha nas respostas. Ela aparece amarrada a governança, a segurança e à pergunta sobre retorno. Até 40% do orçamento com destino definido: o que esse número quer dizer A descrição oficial da palestra na agenda do evento parte da constatação de que até 40% do gasto de TI ainda vai para manter os sistemas existentes. Faixas próximas aparecem nas pesquisas da McKinsey com CIOs, com uma diferença de base que vale entender antes de usar o número em uma apresentação ao conselho. Em outubro de 2020, a McKinsey relatou que CIOs estimam a dívida técnica em 20% a 40% do valor de todo o seu parque tecnológico antes da depreciação, e que de 10% a 20% do orçamento de tecnologia destinado a novos produtos acaba desviado para resolver problemas ligados a essa dívida. Em abril de 2023, a consultoria voltou ao tema para argumentar que separar de 15% a 20% do orçamento de TI para tratar a dívida técnica é insuficiente quando a empresa não muda a forma como ela é gerada e priorizada. Os números medem coisas diferentes, valor do parque em um caso e orçamento no outro, mas apontam na mesma direção da palestra. A leitura prática para o gestor é que o número exato varia por empresa e por método de medição, mas o mecanismo é o mesmo: cada projeto novo paga um pedágio para conviver com o que já existe. O primeiro passo para reduzir esse pedágio é medi-lo no próprio parque, por sistema, em vez de importar uma média de mercado. Por que a IA sem contexto acelera o erro no legado Na síntese que a CSP Tech publicou sobre a palestra, a ideia aparece de forma direta: sem contexto, a IA ganha velocidade na direção errada, e o contexto da empresa mora no legado, raramente na documentação. Em sistemas antigos, a documentação costuma estar desatualizada ou não existir, quem construiu já saiu e as dependências entre módulos ficam invisíveis. O código passa a ser o único registro confiável das regras de negócio. Quando um time joga arquivos inteiros desse código em um assistente de IA e pede uma alteração, três coisas acontecem ao mesmo tempo. O modelo tenta inferir relações que não enxerga, e a entrega pode quebrar outra parte do sistema. O consumo de tokens cresce sem relação com o valor entregue, porque o modelo recebe muito texto irrelevante. E, sem registro, ninguém consegue reconstituir depois qual contexto foi usado, qual modelo respondeu e quanto custou. Cada um desses sintomas tem um efeito direto no orçamento e uma pergunta que o gestor pode fazer ao time ainda hoje. O contexto incompleto vira retrabalho e incidente depois da entrega, e a pergunta é se a IA recebeu as dependências reais do trecho alterado. O envio de arquivos inteiros faz a fatura de IA crescer sem relação com o resultado, o que leva a perguntar quanto custou cada entrega feita com IA em cada projeto. O uso de ferramentas sem aprovação, o chamado shadow AI, coloca risco de vazamento e custo fora do radar, e pede um inventário de quais ferramentas e modelos estão em uso e por quem. Por fim, a falta de trilha torna a auditoria cara e as decisões difíceis de defender, porque ninguém consegue mostrar a um auditor o que foi gerado e com qual base. Esse retrato conversa diretamente com o que as lideranças escreveram no formulário do evento. A preocupação com governança de IA e com retorno é a mesma preocupação vista de dois lados: sem controle do contexto e do custo, nenhuma das duas pode ser demonstrada. A ordem que a CSP Tech defendeu no palco: entender antes de alterar A abordagem apresentada por Lúcio Matias organiza o uso da IA sobre o legado em uma sequência. Cada etapa entrega valor por si e prepara a seguinte, então a empresa decide até onde ir. 1. Reconstruir o conhecimento do sistema, sem alterar o código O ponto de partida é uma engenharia reversa assistida por IA. Em vez de tratar o código como texto, a análise lê a estrutura real dele (funções, classes, chamadas e dependências, extraídas da árvore sintática do código) e monta um mapa de relações. Sobre esse mapa, a IA ajuda a documentar fluxos, regras de negócio, riscos e dívida técnica. Nada é alterado no sistema nessa etapa, o que reduz o risco e permite começar mesmo em ambientes críticos. 2. Decidir com evidência entre manter, evoluir, modernizar ou reescrever Com o sistema mapeado, a decisão que costuma ser adiada por falta de dados passa a ter base, e cada caminho tem um momento em que faz sentido e um risco que precisa ser conhecido antes da escolha. Manter faz sentido quando o sistema é estável, muda pouco e o custo de sustentação está medido e aceito pela empresa, com o cuidado de acompanhar a obsolescência da tecnologia e a saída de quem ainda conhece o sistema. Evoluir é o caminho quando o negócio pede mudanças frequentes e o núcleo do sistema ainda atende, desde que cada alteração parta de um mapa de dependências, para não quebrar outra parte. Modernizar se justifica quando a plataforma limita escala, segurança ou integração, mas as regras de negócio continuam valendo, e o risco principal está em perder alguma dessas regras na migração se não houver rastreabilidade do sistema antigo para o novo. Reescrever só se sustenta quando a arquitetura impede o que o negócio precisa e as regras já estão documentadas, porque reescrever sem conhecer o que o sistema guarda costuma repetir o problema em uma tecnologia nova. 3. Executar com IA governada Quando chega a hora de alterar o código, a IA recebe apenas o recorte do mapa relevante para a tarefa, e não o sistema inteiro. O modelo é escolhido conforme a complexidade da tarefa e o orçamento definido, o resultado é validado contra critérios de aceite antes de entrar no código e cada chamada deixa um registro. O desenvolvedor continua na ferramenta que já usa; o controle fica na camada por trás dela. Esse registro funciona como a memória da operação. Para cada uso da IA, ele guarda em qual projeto e em qual tarefa ela foi acionada, quais partes do sistema entraram no contexto, qual modelo respondeu e por qual política foi escolhido, quantos tokens foram enviados, quanto aquilo custou, se o resultado passou nos critérios de aceite e quem foi o responsável. Com essas informações, a pergunta sobre quanto custou uma entrega feita com IA deixa de depender de estimativa. 4. Medir quanto do custo de sustentar virou capacidade de investir O fechamento da palestra foi sobre orçamento: o objetivo da sequência é transformar o custo de sustentar em capacidade de investir em inovação. Isso só pode ser demonstrado com medição antes e depois, por sistema, considerando horas de sustentação, incidentes, tempo de entrega e gasto com IA por entrega. Sem a linha de base levantada na primeira etapa, qualquer ganho vira estimativa. O que fica para o gestor de TI: antes de definir quanto investir em IA em 2027, vale definir em que ordem usá-la. Começar pelo entendimento do legado cria a evidência que falta para decidir e a linha de base que falta para provar retorno. A camada de governança, com a ressalva devida A preocupação com governança que gera preocupação nas lideranças. A norma ISO/IEC 42001, publicada em dezembro de 2023, estabelece requisitos para um sistema de gestão de inteligência artificial, com foco em uso responsável, gestão de riscos e transparência. Registrar contexto, modelo, custo e validação de cada uso de IA no desenvolvimento ajuda a gerar evidências para esse tipo de sistema de gestão e para auditorias de segurança da informação. Registrar evidência, porém, não equivale a estar em conformidade: a adequação a qualquer norma depende de escopo, processo e avaliação próprios, e não decorre do uso de uma ferramenta ou de um método. Quando essa abordagem é desproporcional Há cenários em que essa sequência custa mais do que resolve. Em um sistema pequeno, bem documentado e mantido por um time que o conhece, com dependências claras e mudanças raras, um mapeamento completo tende a ser desproporcional. Quando o sistema já tem data de desligamento definida e a substituição está contratada e próxima, o esforço rende mais se for para a migração dos dados e das regras críticas. E, se o uso de IA ainda é pontual e não toca código sensível, uma política clara de ferramentas permitidas e um inventário de uso resolvem a maior parte do risco antes de qualquer camada de controle. Perguntas frequentes O que foi o Inovatech Executive Summit 2026? Um encontro de lideranças de tecnologia e inovação realizado em 27 de outubro de 2026, no WTC São Paulo, com o tema do que 2027 vai exigir da liderança de tecnologia. A agenda reuniu palestras, painéis e casos sobre alocação de capital, IA, agentes, segurança e orçamento. Qual foi a participação da CSP Tech no Inovatech 2026? A CSP Tech foi patrocinadora do evento. Lúcio Matias, Head de IA da CSP Tech, apresentou a palestra “O orçamento de inovação está preso no legado”, sobre como usar a IA para entender sistemas legados antes de alterá-los e transformar custo de sustentação em capacidade de investir. A CSP Tech também recebeu lideranças de tecnologia em um Almoço Executivo durante o Summit. Por que a IA sem contexto aumenta o custo de manter sistemas legados? Porque o modelo não conhece as relações reais entre as partes de um sistema legado, que raramente estão documentadas. Ele infere essas relações, o que gera entregas que quebram outras partes e retrabalho. Enviar arquivos inteiros ao modelo também eleva o consumo de tokens sem ganho proporcional, e a falta de registro impede saber depois o que foi feito e quanto custou. Como começar a liberar orçamento preso no legado? Medindo antes de mudar. O primeiro passo é mapear o sistema e o custo de sustentação dele, sem alterar código, para ter evidência sobre dependências, riscos e dívida técnica. Com esse diagnóstico, a empresa decide entre manter, evoluir, modernizar ou reescrever, e passa a ter uma linha de base para provar o retorno de cada mudança, inclusive das feitas com IA. Próximo passo Faça um teste de dez minutos com o seu sistema mais crítico: quem hoje consegue explicar as regras de negócio dele sem abrir o código, quanto custou a sustentação dele no último ano e quanto do gasto com IA do time foi usado nele, com que contexto. Se alguma dessas respostas depende de uma pessoa ou de uma estimativa, o orçamento de 2027 desse sistema já está comprometido sem evidência. Receba um diagnóstico de legado da CSP Tech: um mapa do sistema, dos riscos e da dívida técnica, sem alteração no código, com a recomendação fundamentada entre manter, evoluir, modernizar ou reescrever. CSP Tech. Conectando pessoas, tecnologia e negócios. 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, 38 anos de mercado, produto próprio Power BI for Jira no Atlassian Marketplace).
segurança do Rovo MCP; permissões do servidor MCP da Atlassian;
Por Romildo Burguez • 27 de outubro de 2026
Agentes de IA já escrevem no Jira. Veja os controles de segurança do Rovo MCP que o administrador precisa revisar antes de liberar a escrita.
agentes de IA não autorizados; como identificar agentes de IA em sistemas corporativos?
Por Romildo Burguez • 26 de outubro de 2026
Bancos dos EUA detectaram agentes de IA não autorizados em contas de clientes. Entenda o que o caso revela sobre identidade, permissões e controle.
Por Guilherme Matos • 26 de outubro de 2026
Circuit breaker na B3: o que a interrupção de 26 de outubro exige da TI de bancos, corretoras e instituições de pagamento
governança de agentes de IA; Agentic Multiplayer Protocol; o que é o AMP da Atlassian?
Por Romildo Burguez • 23 de outubro de 2026
Sua equipe usa IA, mas o ganho não chega ao time. Veja o que a Atlassian anunciou no Team ’26 Europe sobre governança de agentes de IA e saiba como aplicar