Fiz um sistema com IA num fim de semana. Posso colocar a equipe pra usar?

Sexta à noite, você abre o Lovable (ou o Replit, o Bolt, o Cursor) e descreve o que precisa: um sistema para controlar pedidos, com cadastro de cliente, status e um painel. No domingo à tarde ele está no ar, com login, tela bonita e um link pronto para mandar pro time.

Você testou com três pedidos inventados e tudo bateu.

A pergunta que quase ninguém faz antes da segunda-feira: dá pra colocar a equipe inteira e os dados dos clientes ali dentro?

Eu uso IA todo dia para escrever código, então a discussão aqui não é se IA presta. O que você construiu no fim de semana é um protótipo. Provavelmente um ótimo protótipo. E protótipo e sistema em produção (o que a equipe usa de verdade, com dado de verdade) carregam responsabilidades muito diferentes.

O que o protótipo feito com IA faz muito bem

O protótipo resolve o problema mais caro de qualquer projeto de software: entender a regra do negócio. Quando você monta as telas, descobre que "pedido aprovado" tem três significados diferentes na sua empresa, que o financeiro precisa de um campo que ninguém lembrou e que o vendedor nunca preenche o CNPJ. Num projeto tradicional, isso aparece depois da entrega.

Ele também prova valor. Se o time usou a tela por uma semana e não quer voltar para a planilha, você tem a resposta que importa: vale investir nisso.

O erro está em outro lugar: tratar protótipo como sistema pronto.

O que os números mostram sobre apps feitos com IA

Um estudo acadêmico de 2026, "Understanding the (In)Security of Vibe-Coded Applications", olhou para isso com cuidado. "Vibe coding" é o nome que pegou para esse jeito de criar software descrevendo o que você quer para a IA, sem escrever o código na mão. Os pesquisadores coletaram 9.041 apps open source feitos com agentes de IA (Claude Code e Lovable) e auditaram 200 que estavam publicados na internet.

Encontraram 1.186 vulnerabilidades. Dos 200 apps, 182 (91%) tinham pelo menos uma falha, e 65,77% das falhas eram de gravidade crítica ou alta. Entre os apps vulneráveis, a mediana foi de 6 falhas por app.

As mais comuns: controle de acesso quebrado, injeção e falhas de autenticação. Em português de dono: gente vendo o que não devia, sistema aceitando um comando disfarçado de dado e login que dá pra contornar.

O mesmo estudo mostra que prompts e ferramentas melhores reduzem o problema, mas não eliminam.

E isso já aconteceu fora do laboratório. Em 2025, o pesquisador Matt Palmer varreu 1.645 projetos feitos no Lovable e encontrou 170 (cerca de 10,3%) com 303 pontos de acesso expostos, porque as regras de permissão do banco de dados estavam ausentes ou fracas. Dava para ler dados de usuários, transações e até chaves de serviços de terceiros. Em um dos casos, dava para gravar um pagamento como "pago" sem pagar. A falha ganhou registro público de vulnerabilidade: CVE-2025-48757.

Nenhum desses apps parecia quebrado na demonstração. Esse é o ponto.

Cinco coisas que separam protótipo de sistema

Você não precisa ser programador para fazer estas cinco perguntas.

1. Quem consegue ver o quê

No protótipo, todo mundo que entra vê tudo. Normal, porque só você testou. Na segunda-feira, o estagiário vai ver o faturamento de todos os clientes? O vendedor A vai ver a carteira do vendedor B? Um cliente com o link consegue abrir o pedido de outro cliente?

Isso é controle de acesso, e foi a falha mais comum no estudo. O detalhe que engana: esconder um botão na tela não protege nada. A regra precisa estar onde o dado fica guardado, para que ninguém consiga pedir a informação direto, por fora da tela. O caso do Lovable foi exatamente esse.

2. Onde ficam os dados de verdade e os de teste

No fim de semana, você testou com dados inventados no mesmo banco que vai receber os dados reais. Num sistema sério, existe um lugar para testar e outro para trabalhar, separados.

O caso mais conhecido é de julho de 2025. Jason Lemkin, fundador da SaaStr, passou 9 dias construindo um app com o agente de IA da Replit. Mesmo com o pedido explícito para "congelar" o código, o agente apagou o banco de dados de produção, com registros de 1.206 executivos e mais de 1.196 empresas. Depois disso, a Replit passou a separar automaticamente o banco de desenvolvimento do banco de produção.

Repare: a própria ferramenta concluiu que os dois não podiam morar juntos.

3. Como voltar atrás

No mesmo caso, o agente disse que não dava para recuperar os dados. A restauração funcionou mesmo assim. A lição: tenha cópia de segurança, teste a restauração antes de precisar dela e não confie na IA para dizer o que dá para recuperar.

Pergunta prática: se alguém apagar todos os pedidos de ontem, quanto tempo leva para voltar? Se a resposta é "não sei", você ainda não tem um sistema.

4. O que acontece quando dá erro

Protótipo é testado no caminho feliz: tudo preenchido certo, ninguém clica duas vezes no botão. Na operação real, dois atendentes editam o mesmo pedido ao mesmo tempo e o pagamento falha no meio.

Um sistema pronto sabe o que fazer nesses casos e avisa alguém quando algo sai do esperado. O protótipo normalmente mostra uma tela branca. Ou pior: segue em frente como se nada tivesse acontecido.

5. Quem mantém

Essa pesa daqui a seis meses. Quem conserta quando quebrar numa terça às 18h? Se a pessoa que montou sair da empresa, alguém entende o que ela fez?

Sistema sem dono piora aos poucos. Com código gerado por IA, mais rápido: muitas vezes nem quem pediu o código sabe como ele funciona por dentro.

Antes de colocar a equipe pra usar

Um checklist curto. Se alguma resposta for "não" ou "não sei", ainda é protótipo.

• Cada pessoa vê só o que precisa ver. Vocês testaram entrando com usuários diferentes e tentando abrir dados alheios por fora da tela.
• Dados de teste e dados reais ficam em lugares separados.
• Existe cópia de segurança automática, e vocês já restauraram uma vez para ver se funciona.
• Senhas e chaves de outros serviços não ficam expostas no código nem no navegador.
• Quando algo falha, uma pessoa com nome recebe um aviso.
• Existe um responsável por manter, com tempo reservado para isso.
• Você sabe quais dados pessoais de clientes estão ali e quem pode acessá-los.

O caminho que eu recomendo: protótipo como especificação viva

Não jogue o protótipo fora. Em vez de um documento de 30 páginas que ninguém lê, você tem telas clicáveis com a regra do negócio funcionando.

O caminho que eu sugiro:

1. Use o protótipo para validar. Poucas pessoas, dados fictícios ou não sensíveis, e anote tudo o que muda.
2. Separe regra de implementação. A regra (quem aprova, quais campos, que status existem) vale ouro. O código pode ou não ser aproveitado.
3. Reconstrua ou reforce o que vai para produção. Às vezes dá para corrigir o que existe. Às vezes sai mais barato refazer a base com acesso, ambientes separados, cópia de segurança e alertas desde o início, usando o protótipo como referência.
4. Defina quem mantém antes de liberar para a equipe.

É assim que tratamos sistemas sob medida na Nov.IA: quando a empresa chega com um protótipo, ele vira o ponto de partida. Se ele também vai conversar com outras ferramentas, as mesmas perguntas sobre falha e manutenção aparecem no guia de automação de processos. E se você não sabe em que ponto o seu está, o diagnóstico serve para isso.

Fontes

• Understanding the (In)Security of Vibe-Coded Applications (arXiv 2606.23130, 2026)
• The Register: Replit apaga banco de dados de produção da SaaStr (julho de 2025)
• SaaStr: nova versão da Replit e os problemas encontrados com vibe coding
• Matt Palmer: comunicado sobre o CVE-2025-48757
• Matt Palmer: detalhes técnicos do CVE-2025-48757

Perguntas frequentes

Sistema feito com IA é seguro?

Pode ser, mas não por padrão. Um estudo de 2026 auditou 200 apps feitos com agentes de IA e encontrou ao menos uma falha em 91% deles. A segurança depende de revisar acesso, dados, cópia de segurança e manutenção antes de usar com dados reais.

Posso usar um app feito no Lovable com dados de clientes?

Só depois de conferir as regras de permissão do banco de dados, separar dados de teste e dados reais e ter cópia de segurança. Em 2025, uma varredura encontrou cerca de 10% dos projetos analisados no Lovable com dados expostos por permissões ausentes ou fracas.

Qual a diferença entre protótipo e sistema pronto?

O protótipo prova a ideia e captura a regra do negócio. O sistema pronto controla quem vê o quê, separa teste de produção, tem cópia de segurança, avisa quando dá erro e tem alguém responsável por manter.

Preciso jogar fora o que fiz com IA?

Normalmente não. O protótipo funciona como especificação viva: mostra telas e regras de verdade. Às vezes dá para corrigir o código; às vezes é mais barato reconstruir a base usando o protótipo como referência.

---

Montou algo com IA e quer saber se dá pra colocar a equipe? No diagnóstico gratuito de 30 minutos, você mostra o sistema e como pretende usar. A gente aponta o que já está bom e o que precisa mudar antes de entrar dado de cliente.

Agendar diagnóstico gratuito (30 min)