Você descreveu o que queria, a IA montou as telas, o login funcionou, os dados aparecem. Na sua máquina, está tudo certo. A dúvida que aparece logo depois é a que trava muita gente: dá para colocar isso na frente de cliente de verdade?
A resposta honesta é: ainda não dá para saber. Ferramentas como Lovable, Bolt, v0, Replit e Cursor são ótimas para construir rápido. O que elas não fazem por conta própria é a parte que separa um protótipo de um produto: pensar em quem pode acessar o quê, no que acontece quando algo dá errado e em quanto aquilo vai custar com mil usuários em vez de um.
Abaixo estão as doze perguntas que fazemos em todo app que chega para revisão. Se você conseguir responder “sim” com segurança a todas, provavelmente está pronto. Se travar em alguma, é por ali que começa o trabalho.
Segurança: o que está exposto
1. Alguma chave ou senha está escrita no código?
É o problema mais comum em app gerado por IA. Para fazer a integração funcionar rápido, a chave da API de pagamento, do e-mail ou do modelo de IA vai parar dentro de um arquivo do projeto. Se esse código vai para o navegador do usuário ou para um repositório público, a chave está exposta. Qualquer pessoa que abrir o inspetor do navegador consegue ver.
Chave de API deve ficar no servidor, em variável de ambiente, e nunca em código que roda no navegador. Escrevemos um artigo só sobre isso, porque é o ponto que mais gera prejuízo rápido.
2. O banco de dados tem regras de quem pode ler e escrever?
Supabase e Firebase, os bancos mais usados por essas ferramentas, deixam o navegador falar direto com o banco. Isso é prático, mas só é seguro com as regras de acesso ligadas e bem escritas: no Supabase, as políticas de Row Level Security; no Firebase, as Security Rules. Sem elas, um usuário logado consegue ler os dados de todos os outros, e às vezes nem precisa estar logado.
3. O login foi testado do jeito errado?
Testar se o login funciona é fácil. O teste que importa é o contrário: o que acontece se alguém tentar abrir a página de outro usuário trocando um número na URL? Se tentar acessar a área de administrador sem ser administrador? Se o link de “esqueci minha senha” puder ser reaproveitado? Esses são os testes que a IA raramente faz por iniciativa própria.
4. O que o usuário digita é validado no servidor?
Validação feita só na tela (campo obrigatório, formato de e-mail, valor mínimo) é burlada em segundos por quem souber usar o navegador. A regra que importa precisa ser repetida no servidor ou no banco. O OWASP Top 10, a referência mais usada de riscos em aplicações web, coloca falhas de controle de acesso e de injeção entre os problemas mais frequentes.
Dados: o que acontece quando algo dá errado
5. Existe backup, e alguém já testou restaurar?
Backup que nunca foi restaurado é uma esperança, não um backup. Vale saber onde ele fica, com que frequência roda e quanto tempo leva para voltar ao ar a partir dele.
6. Você sabe quais dados pessoais o app guarda?
Nome, e-mail, telefone, CPF, endereço, foto. Se o app guarda dados de pessoas, a LGPD se aplica: você precisa de uma base legal para tratar esses dados, de uma política de privacidade que diga a verdade e de um plano para quando houver um incidente. Se forem dados de saúde, a exigência sobe, porque a lei os trata como dados sensíveis.
7. Os ambientes de teste e de produção estão separados?
Quando o mesmo banco serve para testar e para atender cliente, um teste mal feito apaga ou altera dado real. Separar os ambientes custa pouco e evita o tipo de erro que não tem volta.
Operação: o app aguenta o dia a dia
8. Você fica sabendo quando o app quebra?
Se a primeira notícia de que algo parou vem de um cliente reclamando, falta monitoramento. O mínimo é um registro de erros e um alerta quando o app sai do ar.
9. Quanto custa cada usuário, e existe um teto?
Apps com IA dentro (um chat, um resumo automático, uma análise de imagem) pagam por uso. Sem limite por usuário e sem teto de gasto na conta do fornecedor, um uso fora do normal, ou um abuso, vira uma fatura que ninguém esperava. Defina o teto antes de abrir.
10. Dá para publicar uma correção sem medo?
Se cada atualização é feita direto em produção, sem histórico de versões e sem como voltar atrás, cada correção é um risco. Código num repositório (GitHub, por exemplo) e uma forma simples de publicar e reverter resolvem a maior parte disso.
Responsabilidade: quem responde pelo app
11. Alguém além da IA entende o código?
Não precisa ser você. Mas precisa existir uma pessoa que consiga ler o que foi gerado, explicar por que está assim e corrigir quando der problema. Código que ninguém entende não tem manutenção, tem sorte.
12. Existe alguém responsável quando der problema às duas da manhã?
Software em produção dá problema. A pergunta é quem atende, em quanto tempo e com que acesso. Defina isso antes de anunciar o app, não depois do primeiro incidente.
O que fazer com as respostas
Se você respondeu “não sei” a várias perguntas, isso é normal: as ferramentas de IA não pedem essas informações durante a construção. O caminho que costuma funcionar é este:
- Corrigir primeiro o que expõe dados ou dinheiro. Chaves no código, banco sem regras de acesso e login falho vêm antes de tudo.
- Depois, o que impede de voltar atrás. Backup testado, ambientes separados e versionamento.
- Por último, o que melhora a operação. Monitoramento, teto de custo e documentação.
Quase nunca é preciso jogar fora o que foi construído. Na maioria dos apps que revisamos, o trabalho feito com IA é aproveitável. O que falta é a camada de engenharia em volta.
Escrito pela equipe da Grimpo com apoio de inteligência artificial e revisado por uma pessoa. Viu um erro ou quer sugerir um tema? Fale com a gente.
Perguntas frequentes
Um app feito com IA pode ir para produção?
Pode, desde que passe pelas mesmas verificações de qualquer software: segredos fora do código, regras de acesso no banco, login revisado, backup, monitoramento e um responsável técnico. A IA acelera a construção, mas não faz essa revisão sozinha.
Quanto tempo leva para revisar um app antes de publicar?
Depende do tamanho, mas a primeira leitura (o que está exposto, o que falta e o que é urgente) costuma caber em poucos dias. As correções vêm depois, em ordem de risco.
Preciso refazer o app do zero?
Quase nunca. Na maioria dos casos dá para manter o que foi construído e corrigir os pontos de risco: segredos, permissões, validações e a forma de publicar.
Fontes
- OWASP Top 10
- Supabase: Row Level Security
- Firebase: Security Rules
- Lei Geral de Proteção de Dados (Lei 13.709/2018)
Continue lendo
Chave de API no código: o erro que mais custa caro em app feito com IA
Por que a IA coloca a chave dentro do código, como descobrir se a sua está exposta e o que fazer nos…
Supabase e Firebase sem regras de acesso: quando qualquer usuário lê o banco inteiro
O banco que a IA escolheu deixa o navegador falar direto com os dados. Sem as regras certas, um usuário vê os…
Funciona no meu computador, quebra no ar: por que isso acontece com apps feitos com IA
Variáveis de ambiente, banco diferente, dependências soltas e build que ninguém testou. As cinco causas mais comuns e como evitar cada uma.



