Quase metade do código gerado por assistentes de inteligência artificial contém vulnerabilidades de segurança. Esse dado, aferido de forma independente por pesquisadores da Universidade de Nova York e por um dos maiores laboratórios de segurança do mundo, deveria estar no centro das discussões de engenharia.

No entanto, o debate ainda gira, com frequência, em torno de produtividade. Fala-se sobre velocidade, volume de código e redução de tempo de entrega. Porém, a pergunta mais importante é outra: o que está sendo entregue junto com esse código?

Atualmente, pelo menos 8 em cada 10 desenvolvedores utilizam IA no trabalho. Além disso, estimativas indicam que entre 40% e 46% do código em repositórios corporativos tem participação de IA. Em algumas grandes empresas de tecnologia, esse número já ultrapassa 50%.

Ou seja, estamos diante de uma transformação histórica na forma de produzir software. Ainda assim, a maioria das organizações não possui políticas ou controles compatíveis com essa velocidade de adoção.

O que a pesquisa revela sobre segurança

Quando diferentes estudos independentes chegam a conclusões semelhantes, fica difícil ignorar o problema. E é exatamente isso que acontece aqui.

Um dos estudos mais citados, publicado no IEEE Symposium on Security and Privacy, analisou mais de 1.600 programas gerados por IA em 89 cenários de teste. O foco estava nas vulnerabilidades mais comuns catalogadas pelo MITRE.

O resultado é preocupante: cerca de 40% dos programas apresentavam vulnerabilidades. Em linguagens como C, esse número chegava a 50%.

Esse estudo ficou conhecido como “Asleep at the Keyboard”. O nome resume bem o problema: a IA frequentemente gera código funcional, mas sem o rigor de segurança necessário.

Portanto, o ponto não é que a IA não consegue gerar código seguro. O problema é outro. A IA otimiza o que foi pedido no prompt — e, na maioria das vezes, segurança não está explicitada.

Como consequência, o modelo replica padrões estatísticos aprendidos. E muitos desses padrões vêm de códigos históricos que já continham falhas.

O fator humano: confiança que vira vulnerabilidade

Além do aspecto técnico, existe um fator comportamental importante.

Um estudo da Universidade de Stanford avaliou 47 desenvolvedores em tarefas de programação segura. Metade utilizou IA; a outra metade não.

Os resultados mostraram que quem usou IA produziu código menos seguro em 4 das 5 tarefas. Até aqui, nada surpreendente.

Porém, há um detalhe crítico: a confiança.

Os desenvolvedores com código mais inseguro deram notas altas de confiança na IA. Já aqueles com código mais seguro demonstraram baixa confiança.

Ou seja, quanto maior a confiança no assistente, menor o nível de revisão crítica.

Esse fenômeno revela um risco relevante: a delegação cognitiva. O desenvolvedor aceita a sugestão, revisa menos e, assim, vulnerabilidades passam despercebidas.

Portanto, qualquer estratégia de governança que ignore o comportamento humano estará incompleta.

Quando o problema não é o código, mas o vazamento

Outro risco importante está no fluxo inverso: do desenvolvedor para a IA.

Para obter melhores respostas, desenvolvedores fornecem mais contexto. Isso inclui trechos de código, dados sensíveis, variáveis de ambiente e configurações.

No entanto, nem todas as ferramentas garantem onde esses dados são armazenados ou como são utilizados. Como resultado, informações críticas podem sair da organização sem controle.

Além disso, existem ameaças emergentes:

• Envenenamento de dados: pequenas quantidades de código malicioso inseridas em repositórios públicos podem influenciar modelos.
• Backdoors invisíveis: apenas 0,2% de dados contaminados pode ser suficiente para inserir vulnerabilidades difíceis de detectar.
• Slopsquatting: a IA sugere bibliotecas inexistentes. Atacantes registram essas bibliotecas com malware, e desenvolvedores acabam instalando código malicioso sem perceber.

A mudança de pergunta: de adoção para governança

Nas organizações mais maduras, o debate já mudou.

Antes, a pergunta era: devemos usar IA?
Agora, é: como governar o uso?

Mesmo assim, a maioria das empresas ainda não chegou a esse nível. Apenas cerca de 25% possuem políticas formais para uso de IA no desenvolvimento.

Segundo análises recentes, esse cenário representa um risco estratégico. A previsão é que mais de 40% dos projetos de IA sejam cancelados antes da produção, principalmente por falhas de governança — e não por limitações técnicas.

O que muda na prática: segurança desde o início

Diante desse cenário, não basta adicionar segurança no final do processo.

O modelo tradicional de shift-left security precisa evoluir. Agora, a segurança deve estar presente no momento da interação com a IA.

Em outras palavras, o desenvolvedor precisa pensar em segurança enquanto gera o código, e não depois.

Governança de IA aplicada ao desenvolvimento

Felizmente, o ecossistema de governança evoluiu rapidamente.

Hoje já existem frameworks relevantes que ajudam a estruturar esse processo:

• OWASP Top 10 para aplicações com IA generativa
• NIST AI Risk Management Framework (com extensões para IA generativa)
• ISO/IEC 42001, voltada à gestão de sistemas de IA

Esses modelos abordam riscos como:

• Injeção de prompt
• Tratamento inseguro de saídas
• Vazamento de dados sensíveis
• Envenenamento de treinamento
• Riscos na cadeia de fornecimento

O contexto brasileiro e o desafio regulatório

No Brasil, esse debate é ainda mais urgente.

O país está entre os maiores adotantes de IA para geração de código. Mais de 40% das organizações industriais já utilizam IA de alguma forma.

Ao mesmo tempo, o ambiente regulatório está evoluindo:

• A LGPD já impacta o uso de dados em IA
• O Marco Legal da IA está em discussão
• A ANPD já iniciou análises sobre IA generativa

No entanto, a interseção entre desenvolvimento com IA e proteção de dados ainda é pouco explorada pelas empresas.

Conclusão: a pergunta que precisa ser feita agora

A superfície de risco criada pela IA não é teórica. Ela já está nos repositórios, nos pipelines e nos sistemas em produção.

O desenvolvimento ficou mais rápido. Porém, a revisão não acompanhou esse ritmo.

Portanto, a pergunta essencial antes do próximo sprint é simples:

Quantos códigos no seu repositório nunca foram revisados com atenção suficiente?

Se a resposta for “não sei”, então o problema não é técnico — é de governança.

E ele já começou.