A estatística circula em duas partes, e as pessoas costumam citar a mais reconfortante. LLMs produzem código que compila com sucesso em cerca de 90% das vezes. A outra parte: aproximadamente 45% desse código contém vulnerabilidades da classe OWASP Top 10, a lista padrão da indústria para as falhas de segurança graves mais comuns, como bugs de injeção e verificações de login burláveis. Vale a pena ser preciso sobre o que isso significa (e o que não significa) antes que isso cause pânico ou seja simplesmente ignorado.
O que esse número NÃO é
Não é uma afirmação de que 45% dos apps construídos com IA são hackeados, nem que o código gerado é excepcionalmente ruim; desenvolvedores humanos também escrevem código vulnerável, e é por isso que a lista OWASP existe. Também não é um argumento de que as ferramentas de codificação por IA são inúteis, já que um desenvolvedor que revisa a saída consegue capturar grande parte disso no fluxo normal de trabalho.
O que isso realmente significa: jogue uma moeda para cada geração, e essa é aproximadamente a chance de o código conter uma falha do catálogo de vulnerabilidades graves mais conhecido da indústria, mesmo compilando e funcionando perfeitamente na demo. A falha não custa nada em termos de comportamento visível. É aí que está a armadilha.
Por que código que funciona não é código seguro
Modelos de IA otimizam para o sucesso visual rápido, porque é isso que o prompt pede e o que o desenvolvedor consegue verificar olhando. Segurança é precisamente a propriedade que você não consegue ver na janela de pré-visualização, e os modos de falha documentados seguem esse gradiente. O controle de acesso acaba sendo implementado no navegador em vez de no servidor, permitindo que um usuário burle a verificação modificando o código em sua própria máquina; o app parece idêntico de qualquer forma. As permissões do banco de dados são configuradas de forma ampla demais para que tudo funcione na primeira tentativa, deixando dados expostos se qualquer outra parte do app for comprometida. Segredos são inseridos diretamente nos arquivos (hardcoded) porque gerenciar variáveis de ambiente é exatamente o tipo de tarefa invisível que modelos e iniciantes ignoram, e essas credenciais acabam sendo enviadas para repositórios públicos do GitHub. E os fluxos utilitários que possuem peso real de segurança (recuperação de senha, verificação de OTP, gestão de sessão) simplesmente não são construídos, porque ninguém faz demo deles.
A posição de confiança do desenvolvedor piora a situação. Um operador não técnico não consegue ler o código gerado para verificar nada disso, e os testes manuais exercitam o “caminho feliz”, não a brecha. O app que “funciona perfeitamente” e o app que vaza todos os registros dos clientes podem ser o mesmo app.
O que verificar antes que usuários reais façam login
Uma auditoria mínima, em termos simples. Primeiro, aplicação no lado do servidor: confirme que o que um usuário pode ver é decidido no servidor ou nas regras do banco de dados, e não apenas escondendo botões na interface. Segundo, postura do banco de dados: as regras devem negar por padrão e conceder acesso de forma restrita; em ferramentas baseadas em Supabase como o Lovable, isso significa ler as políticas de RLS, e não confiar que o prompt as criou corretamente. Terceiro, higiene de segredos: procure no repositório por chaves e strings de conexão hardcoded, especialmente se o projeto tiver sido sincronizado com um repositório público. Quarto, os fluxos esquecidos: verifique se a redefinição de senha, a expiração de sessão e as restrições de cadastro existem e funcionam. Quinto, o teste do segundo usuário: crie duas contas e tente acessar os dados de um usuário a partir da sessão do outro, inclusive editando as URLs diretamente. Nada disso é exótico; tudo isso é exatamente o que a geração automática pula.
E note a cláusula de manutenção: isso não é uma verificação única. Cada regeneração é um novo lançamento de dados, portanto, o loop de correção em uma funcionalidade de autenticação significa re-verificar a camada que você já tinha verificado, e pagar pela rodada que a re-verifica. Esse fardo de re-verificação é uma face do problema do Dia Dois: a auditoria que você faz hoje é a auditoria que você fará novamente após a próxima mudança.
A bifurcação honesta
Essa lista de auditoria é o custo real por trás desse número de 45%, e existem exatamente duas formas de pagá-lo. Assumir a revisão: você ou um desenvolvedor de sua confiança revisa o código gerado em cada rodada, tratando a IA como um desenvolvedor júnior rápido, cujo trabalho de segurança deve ser sempre verificado. Essa é uma postura razoável para desenvolvedores, mas uma ilusão para qualquer outra pessoa. Ou remover a camada da equação: para apps de negócios, como portais e ferramentas internas, utilize plataformas como o Softr, onde a autenticação, permissões e regras de acesso a dados são configuradas visualmente na infraestrutura da plataforma, em vez de serem códigos gerados por projeto; assim, a “loteria dos 45%” nunca se aplica à camada que mais importa. O que não é uma postura viável é a popular terceira opção: gerar o código, dar uma olhadinha na demo e publicar. Essa estatística existe justamente porque é isso que a maioria das pessoas faz.