Shadow Code
Código gerado por IA virou Shadow Code.
Seu CIO sabe quanto existe em produção? A pergunta deixou de ser se os times usam IA para programar. Agora é saber onde esse código está, quem o verificou e qual risco ele carrega.
Ninguém governa o que não consegue enxergar.
Se amanhã o Conselho perguntar quanto do software crítico foi produzido com assistência de IA, a organização consegue responder com evidências, e não com estimativas?
O que é Shadow Code?
Shadow Code é o código criado ou alterado com assistência de inteligência artificial sem visibilidade, rastreabilidade ou controles suficientes da organização. O risco surge quando software gerado por IA chega a repositórios e produção sem evidência clara sobre origem, modelo utilizado, revisão humana, testes, dependências e responsabilidade pela aprovação.
Assim como o Shadow IT colocou aplicações fora do radar da governança, o Shadow Code pode colocar código gerado por IA fora do radar do CIO, do CISO, da arquitetura, da segurança e da auditoria. A resposta não é proibir copilotos, mas incorporar proveniência e verificação ao ciclo de desenvolvimento.
O problema não é hipotético. A pesquisa já mostra onde a confiança pode falhar.
A página complementa o artigo publicado no IT Forum com pesquisas primárias e referências de segurança de software. O objetivo não é demonizar a IA, e sim colocar rastreabilidade, revisão e controle proporcional no mesmo ritmo da geração de código.
Pacotes alucinados em modelos comerciais
O estudo de package hallucinations encontrou taxa mínima de 5,2% entre modelos comerciais avaliados.
USENIX Security 2025 ↗Nos modelos open source avaliados
A mesma pesquisa observou taxa mínima de 21,7%, reforçando que a ameaça depende do modelo e do contexto.
Ver pesquisa ↗Amostras de código analisadas
O trabalho avaliou 16 LLMs, Python e JavaScript, para estudar persistência e risco das dependências inventadas.
Metodologia ↗Mesmo quando o código era menos seguro
Em estudo com usuários, participantes com assistente de IA produziram código menos seguro e tenderam a acreditar mais na segurança do resultado.
Perry et al. ↗IA exige revisão humana e rastreabilidade
O NIST destaca que conteúdo gerado por IA precisa ser monitorado e validado, com mecanismos capazes de rastrear modelos, alterações, evidências e aprovações ao longo do ciclo de desenvolvimento.
Abrir referência ↗Transparência de dependências é parte do controle
Práticas de SBOM e segurança da cadeia de software existem para tornar componentes e dependências visíveis. O Shadow Code amplia a necessidade de saber também a proveniência da própria geração.
Abrir guia ↗A TI já viveu essa história. Só que agora o software é criado em velocidade de máquina.
Nos anos 1990, planilhas e bancos departamentais democratizaram a criação de sistemas. Funcionavam, cresciam e viravam infraestrutura crítica antes que a organização percebesse que dependia deles. O problema não era a ferramenta. Era o artefato de alta consequência fora do campo de visão da governança.
Shadow Code
- Não há inventário confiável de onde IA foi usada.
- Revisão depende de prática individual.
- Dependências entram sem validação suficiente.
- O modelo usado não faz parte da evidência do software.
AI-assisted SDLC governado
- Uso de IA é registrado como parte da proveniência.
- Controles variam conforme criticidade e impacto.
- Dependências são verificadas e repositórios são controlados.
- Revisão, testes e evidências acompanham a velocidade da geração.
A IA desloca trabalho de escrever para verificar. E verificar é exatamente onde a organização não pode economizar.
Assistentes de código podem acelerar protótipos, testes, refatoração e implementação. Mas produtividade de digitação não é sinônimo de confiabilidade. Quando o artefato nasce rápido, a disciplina de revisão precisa se tornar ainda mais explícita.
O estudo de Neil Perry e coautores encontrou uma combinação especialmente relevante para líderes: participantes com acesso ao assistente produziram, no experimento, soluções menos seguras e ao mesmo tempo demonstraram maior confiança na segurança do que haviam produzido.
Como explicar o Shadow Code em linguagem executiva
“Hoje não conseguimos demonstrar qual parcela do software crítico recebeu contribuição de IA, quais modelos foram usados e se o nível de revisão foi proporcional ao impacto do sistema.”
Quando a IA inventa uma dependência, um erro estatístico pode virar um endereço para o atacante.
Modelos de geração de código podem sugerir pacotes que não existem. Se certos nomes inventados reaparecem com consistência, um atacante pode registrar um pacote malicioso com aquele nome e esperar que uma futura recomendação conduza alguém até ele. A literatura descreve esse vetor como package hallucination, associado ao chamado slopsquatting.
Esse cenário não torna SBOM, SCA ou varredura de vulnerabilidades inúteis. Pelo contrário: mostra que o controle de dependências precisa começar antes da instalação, com repositórios permitidos, verificação de integridade, políticas para pacotes novos e revisão de proveniência.
O problema não é apenas código vulnerável. É vulnerabilidade produzida e replicada em escala.
Erros humanos costumam ser diversos. Equipes diferentes falham de formas diferentes. Modelos amplamente usados podem introduzir o efeito oposto: o mesmo padrão inseguro ser sugerido muitas vezes, em diferentes equipes e repositórios, criando exposição correlacionada.
Ao mesmo tempo, agentes e automação reduzem o custo operacional do ataque e comprimem a janela disponível para defesa.
Modelo mental antigo
- Código nasce em ritmo predominantemente humano.
- Revisão manual absorve boa parte das mudanças.
- Falhas tendem a se distribuir de forma mais heterogênea.
- O atacante depende mais de exploração artesanal.
Modelo operacional atual
- Assistentes ampliam drasticamente o volume produzido.
- Pipelines precisam automatizar evidências e controles.
- Padrões de modelo podem criar falhas correlacionadas.
- A automação ofensiva também comprime a janela de defesa.
A resposta não é banir copilotos. É tratar proveniência, criticidade e verificação como parte do produto.
O método que amadureceu para Shadow IT continua útil: inventariar, classificar por materialidade, estabelecer responsáveis e concentrar controles onde a consequência é maior. Um protótipo descartável e um serviço de autenticação não podem seguir exatamente o mesmo regime.
Proveniência
Registrar uso de IA, modelo, ferramenta, contexto relevante e etapa do ciclo em que houve contribuição automatizada.
Criticidade
Aplicar exigências maiores a código com impacto financeiro, identidades, dados pessoais, segurança ou continuidade.
Revisão
Definir revisão por pares, testes, SAST, SCA, secret scanning e evidências mínimas conforme o risco.
Dependências
Usar lockfiles, registros internos ou aprovados, verificação de integridade e quarentena de pacotes novos quando aplicável.
Pipeline
Fazer do CI/CD o ponto de aplicação automática da política, reduzindo dependência de memória e disciplina individual.
Métricas
Medir cobertura de revisão, origem, exceções, vulnerabilidades e tempo de correção, não apenas linhas de código produzidas.
Um plano de 90 dias para tirar o Shadow Code das sombras
Não é necessário começar por uma política de dezenas de páginas. Comece pela visibilidade, conecte controles ao pipeline e crie um regime proporcional à consequência do software.
Sua organização enxerga o código que a IA está ajudando a colocar em produção?
Marque apenas o que já existe de forma verificável. Intenção, orientação informal ou “o time costuma fazer” não contam como capacidade demonstrada.
Este diagnóstico é uma ferramenta de sensibilização executiva e não substitui avaliação formal de segurança, arquitetura, SDLC, risco, auditoria ou conformidade.
IA, cibersegurança e liderança tecnológica
Shadow Code é apenas uma parte de uma transformação maior: sistemas mais autônomos, ataques mais rápidos e uma governança que precisa acompanhar a velocidade da inteligência artificial.
Biblioteca para aprofundamento
A tese do artigo conversa com uma agenda maior de segurança de software: proveniência, validação humana, dependências, supply chain e controles incorporados ao ciclo de desenvolvimento.
Shadow Code, código gerado por IA e governança
O que é Shadow Code?
É o código criado ou alterado com assistência de IA sem visibilidade, proveniência, revisão ou controles suficientes para que a organização saiba onde ele está, como foi produzido e qual risco representa.
Código gerado por inteligência artificial é inseguro?
Não necessariamente. O risco aumenta quando a fluência do modelo é confundida com correção técnica e quando o código entra em produção sem revisão humana, testes, análise de dependências e controles proporcionais à criticidade.
Como CIOs e CISOs podem governar código gerado por IA?
Começando por inventário e proveniência, classificando aplicações por materialidade, registrando o uso de IA, automatizando SAST, SCA e secret scanning no pipeline e exigindo evidências de revisão e testes para sistemas críticos.
O que são package hallucinations e slopsquatting?
Package hallucination ocorre quando um modelo sugere uma dependência que não existe. Slopsquatting descreve o risco de um atacante registrar esse nome e transformá-lo em um pacote malicioso que pode ser instalado por quem confia na recomendação da IA.
É preciso proibir copilotos e assistentes de programação?
Não. A abordagem mais sustentável é governar o uso conforme o risco, com rastreabilidade, políticas de dependências, revisão, testes e controles automáticos no ciclo de desenvolvimento.
Sobre Fábio Xavier
CIO, professor, autor e palestrante. Escreve sobre inteligência artificial, cibersegurança, governo digital, governança e liderança tecnológica em veículos como IT Forum e MIT Technology Review Brasil.
Leve o debate sobre Shadow Code, IA e cibersegurança para a sua liderança.
Fábio Xavier realiza palestras para conselhos, CIOs, CISOs, executivos e equipes sobre inteligência artificial, Shadow Code, cibersegurança, governança e liderança tecnológica, conectando decisões técnicas a risco, estratégia, continuidade e geração de valor.
