Posso lançar um app feito só com IA? Depende de quem vai usar
Para validar uma ideia, mostrar a investidores ou testar um fluxo com meia dúzia de pessoas, pode e deve. Para colocar clientes reais, dados pessoais ou pagamentos dentro, não sem uma revisão de segurança feita por alguém que entenda do assunto.
A razão é simples. A IA otimiza para fazer funcionar. Ela entrega a tela de login, o cadastro, a lista de pedidos. O que ela raramente entrega por conta própria é a parte invisível: quem pode ver o quê, o que acontece quando alguém manda um dado estranho, onde ficam guardadas as senhas e chaves.
Minha posição: vibe coding é ótimo para o primeiro rascunho e perigoso como versão final sem revisão. O erro mais comum que se vê é tratar o rascunho como produto.
O que a notícia desta semana mostra sobre apps criados com IA
Uma empresa brasileira de qualidade e segurança de software, a Sofist, divulgou testes feitos em um aplicativo comercial de acesso restrito criado com vibe coding. A tela não tinha botão público de criar conta, então parecia fechado. Mesmo assim, o servidor aceitava a criação direta de usuários que ninguém convidou.
Também havia falha na etapa de autenticação em múltiplos fatores. E o detalhe que mais chama atenção: segundo o relato, o app havia sido feito por alguém que já tinha conhecimento de segurança.
A lição prática é que esconder um botão não protege nada. Quem protege é o servidor, e é justamente nele que a IA costuma deixar buracos. O mesmo relato mostra o lado bom: onde havia regras de acesso aplicadas direto no banco de dados, o invasor recebeu zero registros.
Os furos mais comuns em código gerado por IA
Não são falhas exóticas. São as mesmas de sempre, produzidas mais rápido do que alguém consegue revisar. Estas são as que mais aparecem em análises de segurança sobre esse tipo de app:
- Regra de acesso só na tela: o botão some, mas a API responde para qualquer um que chame o endereço direto.
- Dados de um cliente visíveis para outro: o sistema confere se você está logado, mas não se o pedido é seu.
- Chaves e senhas dentro do código, às vezes visíveis para qualquer pessoa que abra o navegador.
- Banco de dados ou painel administrativo abertos ao público por configuração padrão.
- Campos que aceitam qualquer coisa, abrindo espaço para injeção de comandos no banco.
- Login e múltiplos fatores implementados de um jeito que dá para contornar.
Um teste de 30 minutos que você mesmo pode fazer
Você não precisa saber programar para fazer a primeira triagem. Precisa de duas contas de teste e curiosidade.
Crie o usuário A e o usuário B. Com o A logado, abra um pedido ou perfil e olhe o endereço no navegador: se houver um número ou código, troque pelo de um registro do B. Se os dados do B aparecerem, você achou o furo mais clássico de todos.
Depois tente estas verificações:
- Abra uma página restrita em uma janela anônima, sem login. Ela não deveria carregar.
- Tente criar uma conta por fora da tela, se o app deveria ser só por convite.
- Teste a recuperação de senha: ela revela se o e-mail existe? Aceita o mesmo link várias vezes?
- Digite aspas e símbolos estranhos em campos de texto e veja se o app quebra.
- Peça a quem fez o app para mostrar onde ficam guardadas as chaves de integração.
Onde o vibe coding funciona bem e onde não vale o risco
Funciona bem em protótipos, telas de demonstração, ferramentas internas descartáveis sem dado sensível e provas de conceito. Nesses casos, velocidade vale mais que blindagem.
Não vale o risco quando há dados pessoais de clientes, cobrança, saúde, informação financeira ou qualquer coisa que a LGPD alcance. Um vazamento não é só problema técnico: gera obrigação de comunicar, desgaste com cliente e possível sanção.
Existe ainda um efeito pouco comentado. Cada rodada de pedidos à IA (adiciona isto, muda aquilo) mexe em partes do código que ninguém releu. Quanto mais iterações sem revisão, mais difícil saber o que está de pé. Ver a ideia funcionando em um protótipo navegável antes de investir no código de verdade é um jeito barato de separar rascunho de produto, e é o que a SKAD faz com o protótipo de R$ 99.
O que exigir antes de levar um app para produção
Se o seu app nasceu em uma ferramenta de IA e agora vai ganhar usuários, não precisa jogar fora. Precisa de uma revisão com critério. Peça, por escrito, estas respostas a quem for assumir o projeto:
- Toda regra de permissão é validada no servidor, e não só na interface?
- Cada consulta de dados filtra pelo usuário logado ou pela empresa dele?
- Segredos ficam em variáveis protegidas, fora do código e fora do navegador?
- Existe limite de tentativas de login e registro de acessos?
- Há backup testado, com restauração de fato verificada?
- Alguém independente da pessoa que gerou o código fez a revisão?
Perguntas frequentes
O que é vibe coding?
É criar software descrevendo o que você quer em linguagem natural para uma IA, que gera o código. Em muitos casos o resultado é aceito sem revisão detalhada, e é aí que moram os riscos.
Apps feitos com IA são inseguros por natureza?
Não por natureza, mas o padrão da IA é entregar algo que funcione, não algo blindado. Com revisão de acesso, autenticação e configuração, dá para chegar a um nível aceitável.
Posso usar um app feito com IA só dentro da minha empresa?
Pode, se não tiver dados sensíveis e não ficar exposto na internet sem login. Ferramenta interna aberta por engano é uma das formas mais comuns de vazamento.
Um scanner automático de segurança resolve?
Ajuda, mas pega só parte dos problemas. Falhas de lógica, como um usuário ver dado de outro, muitas vezes exigem teste manual feito por quem entende do negócio.
Conclusão
Se você já tem um app feito com IA, faça hoje o teste das duas contas e anote o que encontrar. Se aparecer qualquer vazamento entre usuários, pare de divulgar o app até corrigir. E, se ainda está na fase da ideia, use a IA para validar o conceito num protótipo e só depois contrate o código que vai guardar dados de gente de verdade, com revisão independente de segurança incluída no escopo.