Segurança em código gerado por IA: como reduzir riscos no desenvolvimento

Código gerado por IA acelera tarefas, mas não conhece sozinho as regras do seu sistema. Entenda os riscos e como combinar revisão, testes e governança para usá-lo com segurança.

Ferramentas de inteligência artificial podem produzir código válido, legível e aparentemente completo sem compreender o modelo de autorização, a classificação dos dados ou as decisões arquiteturais de uma empresa. Por isso, código gerado por IA deve ser tratado como contribuição não confiável até passar pelos mesmos controles aplicados ao código humano — e, em componentes sensíveis, por verificações adicionais.

O principal risco não é a IA escrever código que não compila. Falhas sintáticas costumam ser visíveis e interrompem rapidamente o desenvolvimento. O problema mais difícil de detectar é o código funcional que viola uma regra de segurança: uma consulta aceita entrada sem tratamento adequado, um endpoint verifica a autenticação mas não a permissão, ou um arquivo é acessado a partir de um caminho controlado pelo usuário.

Por que um código plausível ainda pode ser inseguro?

Um modelo de linguagem gera respostas a partir do contexto recebido e dos padrões aprendidos. O modelo não conhece automaticamente as regras internas da aplicação, como quais perfis podem alterar um cadastro, quais campos contêm dados pessoais ou quais serviços podem se comunicar. Se essas restrições não estiverem no contexto — ou não puderem ser compartilhadas por razões de confidencialidade — a ferramenta pode preencher as lacunas com uma implementação genérica.

A fluidez do resultado aumenta o risco de uma revisão superficial. Nomes coerentes, tratamento de erros e organização visual transmitem maturidade, embora a implementação possa ignorar requisitos que não aparecem na assinatura da função. Um método chamado updateAccount, por exemplo, pode validar o formato da requisição e ainda permitir que qualquer usuário autenticado altere a conta de outra pessoa. A falha está na ausência da regra de propriedade, não na qualidade aparente do código.

Também existe uma diferença entre executar uma tarefa e compreender suas consequências operacionais. Uma sugestão pode resolver o caso apresentado no prompt, mas não considerar concorrência, isolamento entre clientes, retenção de dados, registros de auditoria ou respostas diferentes para evitar vazamento de informações. Modelos mais capazes podem melhorar a utilidade da resposta, mas não substituem o contexto de segurança específico da organização.

Quais vulnerabilidades podem aparecer no código gerado por IA?

As vulnerabilidades mais relevantes são aquelas que permanecem escondidas durante o uso normal. Injeção de comandos ou consultas pode surgir quando dados externos são concatenados em instruções executáveis. Cross-site scripting pode ocorrer quando conteúdo fornecido pelo usuário é exibido sem codificação apropriada. Falhas de autorização aparecem quando o código confirma que alguém está autenticado, mas não verifica se essa pessoa pode executar a operação solicitada.

O tratamento de arquivos exige atenção semelhante. Nomes e caminhos controlados externamente podem permitir acesso fora do diretório previsto; uploads podem ser aceitos sem validação suficiente; arquivos temporários podem receber permissões inadequadas. Na criptografia, o risco inclui selecionar primitivas impróprias, reutilizar parâmetros ou armazenar chaves junto ao código. Em todos esses exemplos, a função pode operar corretamente em um teste básico e continuar vulnerável em condições adversas.

Há ainda o risco da cadeia de suprimentos. Uma ferramenta pode sugerir um pacote inexistente, desatualizado ou incompatível com a política do projeto. Um nome plausível não comprova que a dependência existe, tem manutenção adequada ou é necessária. Antes de adicionar uma biblioteca, a equipe deve confirmar sua origem, licença, versão, integridade e finalidade. Dependências desnecessárias ampliam a superfície de atualização e o conjunto de componentes que precisam ser monitorados.

Como revisar código assistido por IA sem travar a entrega?

O controle mais eficiente começa antes da geração. O prompt pode informar linguagem, framework, requisitos de validação e padrões internos permitidos, mas não deve receber segredos, credenciais, dados pessoais ou propriedade intelectual sem uma política que autorize esse uso. Instruções melhores reduzem ambiguidades; elas não transformam a resposta em código aprovado.

Depois da geração, a revisão precisa combinar mecanismos complementares:

• Revisão humana orientada a risco: verifica regras de negócio, autorização, isolamento de dados, tratamento de erros e aderência à arquitetura.
• SAST: examina o código sem executar a aplicação e ajuda a localizar fluxos de dados, chamadas perigosas e padrões conhecidos de vulnerabilidade.
• SCA: identifica dependências e apoia a análise de componentes vulneráveis, licenças e versões utilizadas.
• DAST e testes de segurança: avaliam o comportamento da aplicação em execução, incluindo entradas malformadas, manipulação de parâmetros e controles de acesso.
• Detecção de segredos: procura credenciais, tokens e chaves inseridos em arquivos, histórico de versão ou configurações.

Esses controles não são intercambiáveis. A análise estática pode sinalizar uma entrada não tratada, mas dificilmente conhece toda a política comercial de acesso. Um teste dinâmico pode demonstrar que um endpoint aceita uma ação indevida, mas não explicar sozinho onde a regra foi omitida. A revisão humana conecta os achados ao domínio, enquanto a automação torna verificações repetíveis.

O rigor deve acompanhar o impacto. Código para autenticação, autorização, pagamentos, dados pessoais, criptografia, uploads, integrações externas e infraestrutura merece revisão especializada e critérios de aprovação mais restritos. Uma mudança de apresentação sem acesso a dados sensíveis tende a exigir controles diferentes. Governança baseada em risco evita tanto a liberação imprudente quanto a burocracia igual para qualquer alteração.

Como criar uma política prática para código gerado por IA?

Uma política útil define onde a IA pode ser usada, quais informações não podem entrar em prompts, quem responde pela revisão e quais evidências devem permanecer registradas. O repositório pode exigir identificação de trechos gerados ou substancialmente modificados por IA quando essa informação for relevante para auditoria. O registro não elimina riscos, mas permite investigar como uma decisão foi tomada e ajustar o processo após um incidente.

A política também deve separar assistência de decisão. A IA pode sugerir testes, explicar uma função ou propor uma refatoração; a responsabilidade por aceitar a alteração continua com a equipe. Para componentes críticos, a aprovação pode exigir alguém que conheça o domínio e outra pessoa com competência de segurança. O objetivo não é presumir que todo resultado está errado, mas impedir que aparência de correção seja usada como evidência de segurança.

Na experiência profissional da Phurshell, acumulada em mais de 15 anos de mercado, mais de 100 aplicativos entregues e projetos para empresas brasileiras, problemas relevantes costumam aparecer nas interfaces entre tecnologia e regra de negócio. O código isolado parece adequado, mas desconhece quem pode acessar cada dado, quais integrações são confiáveis ou como uma exceção deve ser auditada. Essa observação representa a prática da Phurshell, não uma estatística geral do mercado.

Por fim, a empresa deve acompanhar o efeito da adoção sobre o processo. Achados de segurança, dependências introduzidas, retrabalho e exceções à política ajudam a identificar onde os controles estão falhando. Métricas internas devem servir ao aprendizado, não à criação de metas que incentivem desenvolvedores a ocultar o uso de ferramentas ou acelerar aprovações.