Quase metade do código produzido por assistentes de inteligência artificial carrega vulnerabilidades de segurança. O número, confirmado de forma independente por pesquisadores da Universidade de Nova York e por um dos maiores laboratórios privados de segurança de software do mundo, deveria estar no centro de qualquer discussão sobre engenharia de software com IA. Mas, na prática, as conversas ainda giram em torno de produtividade: linhas por hora, ganho de velocidade, redução no tempo de entrega. O problema real, porém, é o que está sendo entregue junto com esse código.
O cenário atual: adoção acelerada e controles ausentes
Pelo menos oito em cada dez desenvolvedores já utilizam alguma forma de assistência por IA no trabalho. Estimativas recentes indicam que entre 40% e 46% do código enviado para repositórios corporativos tem participação de IA — seja por sugestão automática, geração de funções completas ou revisão assistida. Em algumas das maiores empresas de tecnologia do mundo, esse percentual ultrapassa 50%. Trata-se de uma transformação histórica na forma como software é produzido, e ela aconteceu sem que a maioria das organizações tivesse políticas, processos ou controles à altura da velocidade de adoção.
O que os estudos independentes revelam sobre segurança no código gerado por IA
Quando múltiplos estudos independentes chegam à mesma conclusão por caminhos diferentes, o resultado dificilmente pode ser atribuído a viés metodológico ou interesse comercial. É exatamente o que ocorre com a pesquisa sobre segurança em código gerado por IA: acadêmicos de universidades de ponta e laboratórios de segurança do setor privado, sem coordenação entre si, encontraram taxas de vulnerabilidade semelhantes em contextos distintos.
O estudo mais citado na área, conduzido por pesquisadores da Universidade de Nova York e publicado no IEEE Symposium on Security and Privacy, analisou mais de 1.600 programas gerados por um dos assistentes de código mais populares do mercado. O teste cobriu 89 cenários ligados às vulnerabilidades mais comuns catalogadas pelo MITRE. O resultado: aproximadamente 40% dos programas eram vulneráveis, com picos de 50% em linguagens como C. O artigo ficou conhecido na comunidade como “Asleep at the Keyboard” — um título que captura bem o problema central: a IA gera código funcionalmente correto com frequência, mas sem o rigor de segurança que um desenvolvedor humano atento aplicaria.
Esses dados não mostram que a IA é incapaz de gerar código seguro. Mostram que ela gera código otimizado para o critério que o desenvolvedor especificou no prompt — e segurança raramente está explicitada. O modelo não sabe, a menos que instruído, que aquele campo de input precisa de sanitização, que aquela query precisa ser parametrizada ou que aquela dependência tem um CVE aberto. Ele preenche o que parece correto com base em padrões estatísticos do código visto no treinamento, e boa parte desse código histórico contém vulnerabilidades que nunca foram corrigidas.
O fator humano: quanto maior a confiança na IA, pior o resultado
Há um componente comportamental no risco que os dados técnicos sozinhos não capturam. Um estudo conduzido pelo grupo de criptografia de Stanford pediu a 47 desenvolvedores que completassem cinco tarefas de programação segura — metade com acesso a um assistente de IA e metade sem. Os que usaram IA produziram código significativamente menos seguro em quatro das cinco tarefas. Até aqui, o resultado é esperado.
O que surpreendeu foi a correlação com a confiança: os desenvolvedores com o código mais inseguro avaliaram sua confiança no assistente em 4 de 5. Os com o código mais seguro deram nota 1,5 de 5. A relação entre confiança na ferramenta e qualidade do resultado foi inversa. Quanto mais o desenvolvedor acreditava que a IA estava certa, menos revisava, menos questionava e mais vulnerabilidades acabavam em produção.
Não se trata apenas de treinamento de modelos ou pipeline de segurança. Há um efeito de delegação cognitiva em curso: desenvolvedores, especialmente os mais juniores, constroem uma confiança no output da IA que desincentiva o escrutínio crítico que qualquer revisão de código deveria ter. O assistente sugere, o desenvolvedor aceita, e a vulnerabilidade vai junto. Frameworks de governança que não considerem esse comportamento humano no loop estarão incompletos.
Risco de vazamento de dados e ataques à cadeia de fornecimento
A vulnerabilidade introduzida no código gerado é apenas uma dimensão do risco. Outra, menos discutida mas igualmente grave, ocorre no sentido contrário: do desenvolvedor para a ferramenta. Quanto mais rico o contexto fornecido ao modelo, melhor a sugestão de código. Isso incentiva os desenvolvedores a colar no prompt trechos de código real, esquemas de banco de dados, variáveis de ambiente e arquivos de configuração. Em ferramentas que não garantem contratualmente onde os dados são armazenados e quem pode acessá-los, essas informações deixam a organização sem rastro e sem controle. A LGPD e os marcos regulatórios globais não foram construídos com esse fluxo de dados em mente, e a maioria das organizações ainda não mapeou quais informações seus times estão inadvertidamente tornando insumo de treinamento de terceiros.
Há ainda uma terceira dimensão, mais recente: as próprias ferramentas de desenvolvimento com IA tornaram-se alvo. Pesquisas acadêmicas demonstraram que é possível contaminar o comportamento de um assistente de código enviando pequenas quantidades de código malicioso para repositórios públicos usados como dado de treinamento. Basta contaminar apenas 0,2% dos dados — cerca de 160 arquivos em um conjunto de 80.000 — para embutir backdoors indetectáveis.
Outro fenômeno emergente é o slopsquatting: assistentes de IA frequentemente recomendam bibliotecas de software que não existem. Quando atacantes registram essas bibliotecas fictícias como pacotes reais contendo malware, qualquer desenvolvedor que aceite a sugestão sem verificar está instalando código malicioso na infraestrutura da empresa.
Como mitigar os riscos: governança e frameworks de segurança
A boa notícia é que o ecossistema de frameworks para governança de desenvolvimento com IA amadureceu rapidamente. O OWASP Top 10 para aplicações de modelos de linguagem, em sua versão mais recente, catalogou os riscos específicos de sistemas que usam IA generativa para gerar e revisar código. Entre os dez riscos listados, cinco têm relação direta com desenvolvimento de software: injeção de prompt, tratamento inseguro de saídas, envenenamento de dados de treinamento, divulgação de informações sensíveis e riscos de cadeia de fornecimento.
O NIST publicou um perfil específico de gestão de risco para IA generativa, complementando o AI RMF original com orientações sobre como as funções de governança, mapeamento, medição e gestão se traduzem para o contexto de modelos generativos. Para organizações que já operam com certificações de segurança, a ISO/IEC 42001 traz um sistema de gestão de IA com 38 controles certificáveis, compatível com a ISO 27001.
O cenário brasileiro e a urgência regulatória
No Brasil, esse debate também é urgente. O país é um dos maiores adotantes globais de IA para geração de código, com mais de 40aaa% das organizações industriais já usando alguma forma de inteligência artificial, segundo levantamento do IBGE. O Marco Legal da IA, em tramitação no Congresso, adota abordagem baseada em risco similar ao regulatório europeu. A Autoridade Nacional de Proteção de Dados publicou estudo preliminar sobre IA generativa que coloca em pauta a proteção de dados pessoais no contexto de modelos de linguagem. O cruzamento entre desenvolvimento de software com IA e LGPD ainda é território pouco mapeado para a maioria das empresas brasileiras, e o custo de ignorar essa interseção tende a crescer à medida que o ambiente regulatório se consolida.
O debate sobre desenvolvimento de software com IA nas organizações mais maduras já mudou. A pergunta não é mais “devemos usar?”, mas “como governamos o uso?”. Essa transição, no entanto, ainda não chegou à maioria das empresas. Levantamentos recentes mostram que apenas cerca de um em cada quatro organizações tem políticas formais para uso de IA no desenvolvimento de software. A Gartner posiciona esse cenário como risco estratégico de primeira grandeza. A previsão da consultoria é de que mais de 40% dos projetos de IA agêntica serão cancelados antes de chegarem a produção — não por limitações técnicas dos modelos, mas por incapacidade das organizações de estabelecer controles adequados.
O que a virada de pauta exige, na prática, é uma revisão do processo de desenvolvimento em si. Não basta adicionar uma camada de scanning de vulnerabilidades no final do pipeline. A lógica de shift-left security, que já era consenso no desenvolvimento tradicional, precisa ser reescrita para ambientes de IA: o raciocínio de segurança tem que estar embutido no momento em que o desenvolvedor interage com o assistente, não descoberto depois que o código chega ao repositório.
A superfície de risco criada pelo desenvolvimento de software com IA não é abstrata. Ela está nos repositórios, nos pipelines de CI/CD e nos sistemas em produção — construídos mais rápido do que nunca e revisados com menos atenção do que deveriam. A pergunta que vale fazer antes do próximo sprint é: em quantos dos seus repositórios há código que nenhum humano leu com atenção suficiente para perceber que havia um problema? Se a resposta for “não sei”, a conversa sobre governança de desenvolvimento com IA já está atrasada.
