Os legados de 2028 estão sendo escritos hoje

Romildo Burguez • September 30, 2026

Em setembro, um engenheiro anônimo publicou no X (antigo Twitter) um desabafo que passou de milhões de visualizações. Segundo o relato, na empresa onde ele tinha acabado de entrar, as pessoas trabalhavam 12 a 13 horas por dia praticamente apertando Enter. Passavam o dia aprovando código gerado por IA, sem tempo para ler o que subia para produção. Muita gente leu aquilo como crise de identidade de programador. Para quem responde por sistemas críticos, a leitura é outra. Cada aprovação feita às cegas é um trecho do sistema que ninguém sabe explicar. E é assim que nasce um legado. 


O gargalo mudou de lugar, e a conta foi para a revisão 


Durante décadas, escrever código foi a parte cara do trabalho. A IA barateou essa etapa de forma brutal, mas não barateou a etapa seguinte. Alguém ainda precisa ler, entender, testar e assumir responsabilidade pelo que foi gerado. 


A análise publicada pelo DORA em março de 2026, Balancing AI tensions, descreve exatamente esse deslocamento. A partir de mais de mil respostas abertas de engenheiros, a pesquisa mostra que o tempo economizado na escrita costuma ser gasto de novo em auditoria e verificação. E verificar é uma tarefa cognitiva diferente de criar. Quem escreve com ajuda da IA entrega um pull request enorme em minutos; quem revisa continua tendo que conferir cada linha. O ganho de um vira carga do outro. 


O mesmo texto retoma um achado do relatório DORA de 2025 que deveria estar na mesa de todo gestor de engenharia. Segundo esse achado, maior adoção de IA aparece associada, ao mesmo tempo, a mais throughput e a mais instabilidade na entrega. O time entrega mais e quebra mais. A explicação do DORA é direta. A IA funciona como amplificador. Em organizações com boa plataforma interna, testes sólidos e fluxos claros, ela ajuda. Em times com ferramentas fragmentadas e infraestrutura frágil, ela só acelera a produção de dívida técnica. 


Nada disso significa que os times deixaram de revisar. A pesquisa Agents on a leash, publicada pelo Stack Overflow em maio de 2026, mostra que o uso de agentes de IA no trabalho quase dobrou, de 31% para 59%. Mesmo assim, 63% dos profissionais disseram que raramente ou nunca deixam um agente operar sozinho. O humano continua no circuito. A questão é que estar no circuito não garante compreensão. Aprovar um PR de 800 linhas em quatro minutos também é "revisão humana", pelo menos no registro da ferramenta. 


O que é dívida de compreensão 


Dívida de compreensão é a distância entre o que o sistema faz e o que alguém do time consegue explicar sobre ele sem passar horas investigando. Ela cresce toda vez que um código entra em produção sem que ninguém tenha realmente entendido por que ele foi escrito daquela forma, que regra de negócio ele implementa e o que quebra se ele mudar. 


A dívida técnica tradicional costuma ser uma escolha consciente. O time sabe que pegou um atalho e, em tese, sabe onde ele está. A dívida de compreensão é mais traiçoeira porque não deixa rastro. O código pode até estar bem escrito, seguir o padrão de estilo, passar nos testes. O problema não está no arquivo. Está na cabeça das pessoas, onde aquele conhecimento nunca chegou a entrar. 


Por que ela não aparece no painel de entrega 


Os indicadores que a maioria das empresas acompanha medem volume e velocidade, como itens concluídos, PRs mergeados e frequência de deploy. Todos sobem quando a IA entra. Nenhum deles mede se o time entende o que está entregando. 


A dívida só se manifesta mais tarde, e quase sempre num momento ruim. Pode ser um incidente em produção às duas da manhã, uma mudança regulatória que exige alterar uma regra de cálculo ou a saída da única pessoa que conhecia aquele módulo. É nessa hora que a empresa descobre que o sistema funciona, mas ninguém sabe dizer como. 


Sinais de que o seu time já está acumulando 


Alguns sintomas costumam aparecer antes da crise, e vale observá-los com atenção: 


  • PRs grandes aprovados em poucos minutos, com poucos ou nenhum comentário de revisão. 

 

  • Tempo para encontrar a causa de incidentes crescendo, mesmo em código recente. 

 

  • Perguntas sobre o funcionamento de um módulo sendo respondidas com "vou perguntar para a IA" em vez de "funciona assim porque...". 

 

  • Documentação gerada automaticamente que descreve o óbvio e omite a regra de negócio. 

 

  • Pessoas novas no time que conseguem entregar rápido, mas não conseguem explicar o que entregaram. 


Nenhum desses sinais, isolado, prova que há um problema. Juntos, indicam que a velocidade de produção passou a velocidade de entendimento. 


Como o código gerado por IA vira o legado de 2028 


Sistema legado não é sinônimo de sistema antigo. Na prática, legado é o sistema que ninguém tem coragem de mexer, porque ninguém entende o suficiente para prever o impacto de uma mudança. Por essa definição, um sistema escrito em 2026 pode virar legado em dois ou três anos. Basta que ele seja construído mais rápido do que é compreendido. 


O efeito no orçamento é previsível. A pesquisa da McKinsey com a Serviceware, Recalibrating technology budgets for the AI era, de março de 2026, separa os gastos de tecnologia em dois grupos. "Run" é o que mantém os sistemas funcionando, e "change" é o que cria capacidade nova. As empresas que a McKinsey chama de heavy IT sustainers comprometem a maior parte do orçamento só com manutenção. Já as que o estudo classifica como deliberate modernizers direcionam 57% do orçamento de aplicações para modernização e novas capacidades. 


Há um detalhe na pesquisa que conversa diretamente com a dívida de compreensão. A McKinsey descreve um grupo que investe em mudança, inclusive em IA, mas empilha as novas capacidades sobre os sistemas existentes. O resultado é mais custo de operação e mais dívida técnica, não menos. Código que ninguém entende segue exatamente esse caminho. Ele entra como "change" e, em pouco tempo, passa a morar na coluna de "run". Cada ajuste passa a exigir investigação, cada incidente demora mais para fechar e cada evolução vem acompanhada de medo de quebrar algo. 


O que a aviação aprendeu com a automação 


Em 1983, a psicóloga Lisanne Bainbridge publicou um artigo curto na revista Automatica chamado Ironies of Automation. Ela estudava controle de processos industriais, muito longe de qualquer IDE, mas o diagnóstico serve com precisão incômoda para o momento atual. 


A primeira ironia é que, quanto mais se automatiza, mais o papel do humano se reduz a monitorar. E monitorar por longos períodos um sistema que quase sempre funciona é justamente uma tarefa em que pessoas são ruins. A atenção cai, os desvios passam. 


A segunda ironia é mais cruel. Quando a automação falha, o humano precisa assumir o controle numa situação anormal, que exige mais competência do que a operação de rotina. Só que essa competência se deteriora exatamente porque deixou de ser praticada no dia a dia. O sistema automatizado cobra, na hora mais difícil, a habilidade que ele mesmo tirou do operador. 


Troque "operador de planta industrial" por "engenheiro que aprova código de IA" e a descrição continua de pé. O engenheiro vira monitor da esteira. Sua capacidade de ler e raciocinar sobre o sistema enfraquece por falta de uso. E, no dia em que algo quebra de um jeito que a IA não resolve, é dele que se espera o diagnóstico. 


A aviação comercial enfrentou esse dilema bem antes do software. Os aviões ficaram altamente automatizados, e o setor não respondeu reduzindo o treinamento dos pilotos. Respondeu com treinamento recorrente, simulação de falhas e checklists rigorosos, para que a competência manual continuasse viva mesmo quando raramente é usada. A própria Bainbridge apontava que sistemas mais automatizados podem exigir mais investimento em preparo humano, e não menos. 


Como revisar código gerado por IA sem transformar o time em monitor de esteira 


Proibir IA no desenvolvimento não resolve. O caminho é desenhar o processo para que a compreensão acompanhe a produção. Algumas práticas ajudam bastante nisso. 


A primeira é trabalhar em lotes pequenos. O próprio DORA recomenda essa disciplina como contrapeso aos riscos do desenvolvimento assistido por IA. Um PR que cabe na cabeça de quem revisa tem chance real de ser entendido. Um PR de centenas de linhas geradas de uma vez só será aprovado por confiança. 


A segunda é classificar o sistema por criticidade. Nem todo código merece o mesmo nível de escrutínio. Uma tela de relatório interno pode seguir com revisão leve. Regras de cálculo financeiro, integrações com sistemas core, tratamento de dados pessoais e fluxos regulados precisam de revisão profunda, com alguém capaz de explicar o que foi alterado e por quê. Deixar isso explícito tira a decisão do improviso e da pressão de prazo. 


A terceira é mudar o que se mede. Se o painel só acompanha volume, o time vai perseguir volume. Indicadores como taxa de falha de mudança, tempo de recuperação de incidentes, retrabalho em código recente e tamanho médio dos PRs dizem muito mais sobre a saúde da engenharia do que a quantidade de linhas aceitas. Vale incluir também uma prática simples, que não depende de ferramenta. Periodicamente, peça que alguém do time explique um fluxo crítico do começo ao fim, sem abrir a IA. Se ninguém consegue, a dívida já está lá. 


A quarta é preservar a prática deliberada, o equivalente ao treinamento recorrente dos pilotos. Isso passa por parear pessoas menos experientes com seniores na revisão de decisões de arquitetura geradas por IA e por reservar componentes complexos para desenvolvimento com mais participação humana. Também passa por registrar as decisões de desenho em algum lugar consultável, seja no Confluence, seja no próprio fluxo do Jira. O objetivo é que o conhecimento sobre o sistema more nas pessoas e na documentação, não apenas no histórico de prompts. 


Por fim, governança de IA no desenvolvimento precisa ser tratada como decisão de gestão. Hoje, na maioria dos times, ela fica a critério de cada desenvolvedor. Quem pode aprovar o quê, em qual parte do sistema, com qual nível de evidência. Sem esse acordo, cada pessoa calibra sozinha, sob pressão, quanto vai ler antes de apertar enter. 


Onde a CSP Tech entra nessa conversa 


Boa parte das empresas que atendemos não tem tecnologia como core business, mas depende de sistemas críticos para faturar, atender e cumprir obrigações regulatórias. Nesses ambientes, a pergunta não é se a IA vai entrar no desenvolvimento. Ela já entrou. A pergunta é quanto do que está sendo entregue hoje o time vai conseguir sustentar daqui a três anos. 


A CSP Tech trabalha justamente nessa camada. Em sustentação de ambientes críticos e desenvolvimento de sistemas core, o trabalho começa por entender onde o conhecimento sobre o sistema está concentrado, onde ele já se perdeu e quais fluxos não podem ficar sem dono. A partir daí, ajudamos a estruturar o processo de revisão por criticidade e a organizar a documentação e a rastreabilidade das decisões no Jira e no Confluence. Quando o gargalo é capacidade, reforçamos o time com squads que entram para entender o ambiente, e não só para aumentar o volume de entrega. 


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


Atlassian traz loops de agentes de IA para a engenharia de software 

 

Segurança do código gerado por IA: a lacuna que ninguém está validando 

 

Sustentação e manutenção evolutiva e adaptativa de sistemas legados: por que sem medir o esforço, a conta só cresce 

 

Velocidade que o sistema consegue sustentar 


A IA já mudou o custo de escrever software, e isso não vai voltar atrás. O que ainda está em aberto é quem vai conseguir manter, corrigir e evoluir o que está sendo escrito agora. Empresas que medem só velocidade de entrega vão descobrir o tamanho da dívida de compreensão no pior momento possível, com um incidente aberto e ninguém capaz de explicar o que aconteceu. As que tratam compreensão como parte do trabalho chegam em 2028 com sistemas que ainda conseguem mudar. 


Talvez o seu time tenha acelerado com IA e você já perceba PRs aprovados rápido demais, incidentes mais difíceis de diagnosticar ou módulos que só uma pessoa entende. Se for o caso, esse é um bom momento para olhar o cenário com calma. Converse com os especialistas da CSP Tech para mapear onde a dívida de compreensão já está se formando e definir o que precisa de mais governança antes que vire o próximo legado. 


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

Fale com a CSP Tech

.

Por Guilherme Matos • 13 de novembro de 2026
Em banco, seguradora ou cooperativa, um normativo interno vencido que continua acessível na intranet deixa de ser só conteúdo desatualizado e passa a ser instrução operacional errada. Com o Microsoft 365 Copilot, o risco cresce, porque o assistente usa todo o conteúdo que o colaborador tem permissão de ver, inclusive a
Por Guilherme Matos • 12 de novembro de 2026
Uma instância Jira por cooperativa ou uma para o sistema inteiro? Veja os três desenhos possíveis, os critérios de decisão e o que a Resolução 4.893 permite ao sistema cooperativo.
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.