Problemas de sites e apps feitos com IA (Lovable, Bolt, v0)

Os problemas que ninguém conta sobre sites e apps feitos com IA: dados expostos, chaves no front-end, custos, SEO, manutenção e lock-in. Veja como evitar.

Sites e apps feitos com IA têm alguns problemas que quase ninguém conta na hora do "olha, fiz um SaaS em uma tarde": banco de dados aberto para qualquer pessoa, chaves secretas expostas no navegador, ausência de validação no servidor, SEO fraco, custos que crescem sem aviso e um código que fica cada vez mais difícil de mexer. Nada disso significa que Lovable, Bolt.new, v0, Replit Agent ou Cursor sejam ruins. Significa que eles entregam um protótipo muito bom, e protótipo não é a mesma coisa que produto pronto para receber clientes reais.

Este guia lista os problemas mais comuns, explica cada um em linguagem simples e mostra o que verificar antes de lançar.

Primeiro, o lado bom (que é real)

Vale ser justo. Ferramentas de "vibe coding" (programar descrevendo o que você quer em linguagem natural e deixando a IA escrever o código) mudaram o jogo para quem quer validar uma ideia:

• Você testa uma ideia em dias, não em meses.
• Mostra algo clicável para investidores, sócios e primeiros clientes.
• Descobre cedo o que as pessoas realmente usam, antes de gastar caro.
• Para landing pages, ferramentas internas e MVPs simples, muitas vezes o resultado já é suficiente.

O problema não é usar IA. É pular a etapa de revisão e tratar o protótipo como se ele já tivesse passado por um time de engenharia. Os riscos abaixo aparecem justamente nessa transição.

1. Segurança: dados expostos sem você perceber

Esse é o problema mais sério, e o mais silencioso. Muitos apps gerados por IA usam o Supabase como backend (banco de dados, login e arquivos). O próprio Lovable Cloud, backend embutido do Lovable, roda sobre a infraestrutura do Supabase.

Nesse modelo, o navegador do usuário conversa direto com o banco de dados. Quem decide o que cada pessoa pode ler ou alterar é um recurso chamado Row Level Security (RLS), ou "segurança por linha". Se o RLS estiver desligado, ou se as regras (as policies) forem permissivas demais, qualquer pessoa que abrir o DevTools do navegador consegue consultar a tabela inteira.

Isso não é teoria. Em 2025, o pesquisador Matt Palmer analisou apps publicados na vitrine do Lovable e relatou que cerca de 170 dos 1.645 projetos verificados tinham tabelas acessíveis sem autenticação adequada. O caso virou o registro CVE-2025-48757. Importante: o problema não era uma falha no Supabase em si, e sim regras de acesso mal configuradas nos apps gerados. Depois disso, o Lovable passou a oferecer uma verificação de segurança antes da publicação, integrada ao Security Advisor do Supabase.

A verificação ajuda, mas não substitui entender o que as suas regras fazem. Um alerta "verde" não garante que a lógica da sua policy está certa para o seu negócio.

Atenção: se o seu app tem login, perfis de usuário, pedidos, mensagens ou qualquer dado pessoal, revisar o RLS é a primeira coisa a fazer. Explicamos passo a passo em Supabase RLS explicado.

2. Chaves e segredos no front-end

Todo código que roda no navegador pode ser lido por qualquer pessoa. Não existe "esconder" uma chave dentro do JavaScript do site.

Algumas chaves são feitas para ficar públicas, como a chave publishable (antiga anon) do Supabase. Ela só é segura se o RLS estiver bem configurado. Outras jamais podem ir para o navegador:

• A chave secret (antiga service_role) do Supabase, que ignora o RLS.
• Chaves da OpenAI, Anthropic ou outra API de IA.
• Chaves secretas do Stripe, Mercado Pago ou gateway de pagamento.
• Tokens de envio de e-mail, SMS ou WhatsApp.

Quando você pede para a IA "conectar com a API X", ela às vezes coloca a chave direto no código do front-end porque é o caminho mais curto para funcionar. Funciona, e qualquer pessoa pode copiar a chave e usar na sua conta. O lugar certo para essas chaves é uma função no servidor (por exemplo, uma Edge Function do Supabase) que guarda o segredo em variável de ambiente.

3. Regras de negócio só no navegador

Outro padrão comum: a validação existe só na tela. O botão "comprar" verifica se o cupom é válido, o formulário impede valores negativos, o menu esconde a área de admin de quem não é admin.

O problema é que tudo isso pode ser contornado. Quem souber usar o DevTools envia a requisição direto para o banco ou para a API, sem passar pela tela. Se o preço, o desconto ou a permissão de admin não forem verificados no servidor, eles não estão protegidos de verdade. Se esses termos são novos para você, vale ler a diferença entre front-end e back-end.

4. Custos que explodem

Três fontes de surpresa na fatura:

• Créditos da própria ferramenta. Cada pedido para a IA consome créditos. Quando o projeto cresce e a IA entra num ciclo de "conserta isso, quebrou aquilo", o consumo dispara e a evolução trava.
• APIs pagas expostas ou sem limite. Uma chave de API de IA vazada, ou uma função sem limite de uso (rate limiting), pode ser chamada milhares de vezes por um robô. Quem paga é você.
• Consultas ineficientes. Código gerado tende a buscar mais dados do que precisa, sem paginação nem índices. Com dez usuários, ninguém nota. Com milhares, o banco fica lento e o plano precisa subir.

Dica: configure alertas de gasto e limites de uso em todos os serviços pagos (provedor de IA, banco, hospedagem) antes de divulgar o app.

5. SEO de SPA: o Google pode não ver o seu conteúdo direito

Muitos projetos gerados por IA são SPAs (Single Page Applications): o servidor entrega uma página praticamente vazia e o JavaScript monta o conteúdo no navegador. O Google consegue executar JavaScript, mas o processo é mais lento e menos previsível do que ler um HTML pronto. Outros robôs, como os que geram a prévia de links no WhatsApp e no LinkedIn, muitas vezes nem executam.

As ferramentas estão evoluindo nisso. Segundo a documentação do Lovable, apps criados a partir de maio de 2026 usam TanStack Start com renderização no servidor, e projetos antigos hospedados lá recebem versões pré-renderizadas para buscadores verificados. O v0 costuma gerar projetos em Next.js, que suporta renderização no servidor. Mesmo assim, títulos únicos por página, sitemap e meta tags continuam sendo responsabilidade sua. Detalhamos tudo em por que o Google não encontra seu site feito com IA.

6. Código difícil de manter

A IA escreve rápido, mas não necessariamente de forma organizada. Depois de dezenas de iterações, é comum encontrar:

• Componentes enormes, com centenas de linhas misturando tela, regra e acesso a dados.
• A mesma lógica copiada em vários lugares, cada cópia um pouco diferente.
• Dependências instaladas e nunca usadas.
• Nenhum teste automatizado, então ninguém sabe se uma mudança quebrou outra coisa.
• Migrações de banco feitas "na mão", sem histórico claro.

O sintoma clássico é quando a própria IA começa a se perder: cada correção gera um bug novo. Nesse ponto, insistir em mais prompts costuma sair mais caro do que parar e reorganizar.

7. Lock-in: o quanto você depende da ferramenta

Lock-in é quando sair de um fornecedor fica tão difícil que você fica preso a ele. Com ferramentas de IA, o código do front-end geralmente pode ser exportado ou sincronizado com o GitHub. A parte mais delicada costuma ser o backend gerenciado:

• O Lovable Cloud é cobrado e gerenciado pelo Lovable. Segundo a documentação, não existe migração em um clique dele para um projeto Supabase próprio; é preciso exportar os dados e recriar a estrutura.
• Domínio, contas de pagamento e e-mail às vezes ficam em nome de quem montou o projeto, não da empresa.

Nada disso impede você de usar a ferramenta. Só vale decidir conscientemente, e manter código no seu GitHub e contas no nome da empresa desde o início. Se você ainda não usa Git, comece pelo nosso tutorial de Git para iniciantes.

Checklist rápido antes de lançar

Use esta lista como ponto de partida:

Quando é hora de chamar um dev

Você não precisa de um desenvolvedor para cada ajuste. Mas alguns sinais indicam que é hora de ter alguém técnico olhando:

1. Você vai colocar dados reais no ar: cadastros, documentos, dados de saúde, informações financeiras.
2. Vai cobrar dentro do app: integração de pagamento mal feita é risco direto de prejuízo.
3. A IA entrou em loop: cada prompt conserta uma coisa e quebra outra.
4. O app ficou lento ou os custos estão crescendo mais rápido que os usuários.
5. Precisa de algo que a ferramenta não faz bem: integrações complexas, rotinas agendadas, relatórios pesados.
6. Alguém vai investir ou auditar: investidor, cliente corporativo ou parceiro pode pedir evidências de segurança.

Um caminho que costuma funcionar bem é o híbrido: validar com IA e profissionalizar o que deu certo. Comparamos as opções em Lovable, Bolt, v0 ou contratar um desenvolvedor. Se decidir contratar, este guia de como contratar desenvolvedor ou software house ajuda a não cair em armadilhas.

Precisa de uma segunda opinião sobre o seu projeto?

Se você construiu algo com Lovable, Bolt, v0, Replit ou Cursor e quer colocar no ar com segurança, a Mobgeek oferece o serviço de resgate de projetos feitos com IA: auditoria de segurança, correções, deploy, performance e SEO, com a auditoria a partir de R$ 1.990. Se preferir, descreva o seu caso e peça um orçamento. Sem compromisso.