Quem autorizou essa atualização de dependência? Pode ter sido sua IA

A confiança na IA não começa no modelo, começa no processo.

Quinta parte de uma série sobre a metodologia que uso para continuar sendo, de fato, o responsável pelo que um agente de IA produz. É o caso aplicado do artigo anterior, sobre guardrails fixos.

Quantas vezes você aprovou um pull request de atualização de dependência sem realmente ler o changelog inteiro, confiando que “é só um patch, deve estar tudo bem”? E quantas vezes esse PR nem foi aberto por você, mas sim por um agente de IA que, no meio de outra tarefa, decidiu que atualizar aquela biblioteca fazia parte de “deixar tudo funcionando direito”?

Disclaimer: este texto reflete minha visão prática sobre o tema, construída em projetos pessoais e profissionais. Não representa, necessariamente, a posição oficial de nenhuma organização à qual eu esteja afiliado.

Atualizar uma dependência parece uma decisão pequena demais para merecer o mesmo cuidado que uma decisão de arquitetura. No fundo, é exatamente o tipo de decisão que a indústria de segurança vem tratando, ano após ano, como porta de entrada preferida para comprometer sistemas inteiros. Não pela dependência em si, mas por ninguém ter parado para perguntar por que ela estava mudando.

O relatório de 2026 sobre o estado da cadeia de suprimentos de software da Sonatype documenta 1,233 milhões de pacotes maliciosos identificados em circulação, um crescimento de 75% em relação ao ano anterior, com 454.648 pacotes novos descobertos só no último ano, sobre um volume de 9,8 trilhões de downloads de código aberto, 67% a mais que no ano anterior.

O relatório é direto sobre a IA especificamente: “o desenvolvimento assistido por IA também está introduzindo uma nova classe de risco — automação pode amplificar entradas ruins em velocidade de máquina”.

E documenta um padrão recorrente: mesmo quando uma correção existe, versões vulneráveis continuam sendo baixadas em escala. Dependências esquecidas, dependências transitivas em cascata, e a fricção de atualizar mantêm risco antigo circulando dentro de builds novos.

O problema não é o agente decidir mal. É o agente decidir sem que ninguém perceba que uma decisão foi tomada

Um engenheiro humano, ao considerar atualizar uma dependência, normalmente sente algum grau de hesitação: “será que isso quebra alguma coisa?”, “vale a pena mexer nisso agora?” Essa hesitação, mesmo que pequena, é um guardrail natural.

Um agente de IA, obediente e eficiente por padrão, não sente essa hesitação a menos que ela tenha sido explicitamente desenhada no processo. Se a instrução for “deixe o projeto em bom estado” ou “resolva os avisos de segurança”, o caminho mais direto e mais plausível é simplesmente atualizar. E atualizar tende a parecer, para um agente, uma ação de baixo risco, quase administrativa, porque tecnicamente é só trocar um número de versão.

É exatamente aqui que o guardrail que descrevi no artigo anterior desta série (avaliar um padrão antes de adotá-lo, mesmo quando pedido por nome) precisa ser explícito sobre um tipo de mudança que normalmente ninguém pensa em restringir: a de dependências externas.

O mesmo guardrail que exige avaliar o custo real de um padrão de design antes de adotá-lo se aplica sem nenhuma alteração conceitual a uma atualização de biblioteca. A pergunta não é “essa versão compila?” É “o que mudou, por que estamos aceitando essa mudança agora, e quem está autorizando esse trade-off em nome de quem depende deste software?”

Tratar upgrade de dependência como decisão de arquitetura, não como manutenção de rotina

Isso não significa burocratizar toda atualização de patch. Isso mataria a velocidade que a IA genuinamente entrega, e sem necessidade real, já que a maioria das atualizações é, de fato, inofensiva.

Significa desenhar o processo para que a decisão de aceitar uma mudança de dependência tenha o mesmo tratamento de qualquer outro trade-off relevante: opções e custos explicitados antes de ser aceita, nunca decidida silenciosamente por quem está mais perto do teclado, humano ou agente.

Isso se traduz em regras simples, mas que precisam estar escritas como guardrail permanente, não como algo que alguém lembra de pedir a cada vez: mudanças de versão maior nunca são aplicadas sem que o changelog seja lido e resumido explicitamente antes da decisão; dependências novas (não atualizações, adições) sempre exigem justificativa de por que a capacidade não existe já no projeto; e qualquer atualização motivada por um aviso de segurança vem acompanhada da pergunta inversa também: o que essa mudança quebra, e isso foi verificado, ou só assumido?

Um ADR (o registro de decisão de arquitetura que descrevo com mais profundidade no artigo ADRs em lote, e a regra da visibilidade) entra aqui do mesmo jeito que entra em qualquer outra decisão relevante: uma atualização que mudou comportamento observável, ou que foi deliberadamente adiada por causa de um custo real, merece o mesmo registro que qualquer outra decisão técnica. Não porque toda dependência importa igualmente, mas porque, sem esse registro, ninguém consegue diferenciar depois “isso foi avaliado e aceito” de “isso simplesmente aconteceu”.

Essa tensão, entre deixar uma dependência estagnar e mexer nela sem governança, não é nova nem exclusiva de agente de IA. Já escrevi, num artigo fora desta série, sobre o lado da estagnação: microsserviços e suas dependências se multiplicando mais rápido do que qualquer time consegue enumerar ou revisar (O Efeito Gremlins), com uma parcela inteira desses ativos caindo na categoria “deixa quieto, time que tá ganhando não se mexe”.

O sintoma ali era o oposto deste texto: não a atualização feita sem hesitação, mas a proliferação sem controle suficiente para saber, com segurança, o que rodava onde e havia quanto tempo. É a mesma doença de fundo, tratar a atualização de dependência como evento isolado em vez de parte contínua do ciclo de vida do software, só que aparecendo agora pelo lado inverso: rápido demais, em vez de devagar demais.

Na prática

Nunca deixe “atualizar dependências” ser uma tarefa implícita dentro de outro pedido. Se o guardrail não distingue explicitamente entre “corrija esse bug” e “corrija esse bug e, de passagem, atualize o que parecer desatualizado”, a segunda interpretação vai acontecer eventualmente, e vai parecer, para quem revisa depois, que foi uma decisão deliberada.

Trate toda atualização de versão maior como uma decisão que precisa de dono, não como rotina. A pergunta não é técnica (“isso compila?”), é de responsabilidade: quem está aceitando esse trade-off em nome de quem usa o software?

Meça a fricção de atualizar como um sinal, não como um incômodo a eliminar. Se manter dependências atualizadas é sistematicamente doloroso, isso costuma indicar acoplamento excessivo em algum outro lugar da arquitetura. Resolver a dor real é melhor do que automatizar a aceitação cega dela.

Audite, de tempos em tempos, quantas dependências do projeto foram atualizadas sem nenhum registro do porquê. Esse número é uma medida direta de quanto risco de cadeia de suprimentos está circulando no seu projeto sem que ninguém tenha efetivamente decidido aceitá-lo.

Conclusão

A cadeia de suprimentos de software não quebra, na maioria das vezes, por uma dependência maliciosa sofisticada demais para ser detectada. Quebra porque uma decisão pequena, tomada sem hesitação suficiente, se acumula com outras cem decisões pequenas do mesmo tipo, até que ninguém no projeto conseguiria dizer com confiança por que cada uma daquelas versões está exatamente ali.

Um agente de IA não introduz esse risco por ser malicioso ou por ser descuidado no sentido humano da palavra. Introduz porque, sem guardrail explícito, ele trata “atualizar” como uma ação neutra. A melhor forma de mudar isso não é confiar menos na ferramenta. É desenhar, de propósito, o mesmo atrito produtivo que já uso para qualquer outro trade-off técnico, agora aplicado ao lugar onde, historicamente, ninguém pensava em aplicá-lo.

No próximo artigo desta série, volto à estratégia mais pesada: os quatro eventos de risco que deveriam disparar disciplina mais forte, e as regras que tornam uma auditoria com múltiplas frentes confiável de verdade.

Tenham um excelente dia!

Eu sou Fernando Cerqueira e entrego estratégias digitais para os desafios do presente, com propostas de inovação para um futuro sustentável. Como arquiteto sênior, aproveito meus mais de 30 anos de experiência em arquitetura e desenvolvimento de software para projetar e implementar soluções baseadas em nuvem que ajudam os clientes a transformar seus negócios com tecnologia. Este texto foi escrito com apoio do Claude Code, a partir da minha experiência, minhas decisões e revisão: o próprio processo que a série descreve.

Nesta série

1. Metodologia de Desenvolvimento Assistido por IA Centrada na Decisão Humana
2. Disciplina em rajada: por que o rigor não nasce junto com o código
3. O código duplicado que a IA cria enquanto parece produtiva
4. As três práticas que nunca esperam gatilho
5. Quem autorizou essa atualização de dependência? Pode ter sido sua IA (este artigo)
6. Os quatro eventos de risco e a auditoria multi-frente
7. Seu agente de IA resolve a issue de verdade, ou só parece resolver?
8. ADRs em lote, e a regra da visibilidade
9. IA no time não reduz o bus factor do seu projeto — pode aumentar
10. Calibrando a intensidade ao risco real
11. O alinhamento entre produto e engenharia começa onde a decisão fica registrada
12. Segurança psicológica também vale para o time formado por você e sua IA
13. Releitura: o papel do humano, os sinais que funcionam, e onde a metodologia ainda é fraca

Referências citadas

• Sonatype, “2026 State of the Software Supply Chain Report” (citação traduzida livremente no texto): https://www.sonatype.com/state-of-the-software-supply-chain/introduction
• Fernando Cerqueira, “O Efeito Gremlins e os microsserviços” (enterprisearchitecture.com.br): https://enterprisearchitecture.com.br/o-efeito-gremlins-e-os-microsservicos/