Meus dados estão seguros em um construtor com IA?

Meus dados estão seguros em um construtor com IA?

A pergunta precisa ser dividida, porque existem três dados diferentes em jogo: o texto que você escreve no pedido, o conteúdo do projeto e as informações dos seus clientes. As duas últimas categorias moram em contas suas, como Supabase e Stripe, e o código sai para o seu GitHub. A responsabilidade legal pelo que você coleta continua sendo sua.

Quem responde "sim, é seguro" sem separar essas camadas está simplificando demais uma pergunta que tem respostas diferentes em cada uma delas.

Quais dados existem em um projeto gerado?

Vale colocar tudo na mesa antes de discutir segurança, porque a maior parte da confusão vem de tratar coisas muito diferentes com a mesma palavra.

A linha mais sensível é a quarta, e é justamente a que menos aparece nas conversas sobre o assunto. Quando o seu projeto tem login ou formulário, você passa a guardar informação de outras pessoas, e isso muda o tamanho da sua obrigação.

Repare também que quatro das seis linhas apontam para contas que são suas. Essa é a diferença estrutural entre depender de um fornecedor e usar um fornecedor: as informações críticas não ficam em nome dele.

Onde moram os dados dos seus clientes?

No Supabase, quando o projeto usa banco, login ou armazenamento de arquivos. A conta é sua desde o primeiro dia, criada por você, com a sua senha e o seu painel de administração.

Na prática isso significa que você consegue ver as tabelas, exportar tudo, apagar um registro a pedido de um usuário e revogar acessos sem depender de abrir chamado com ninguém. O detalhamento de como essa ligação funciona está em construtor com IA e Supabase.

O mesmo desenho vale para cobrança. Assinaturas e pagamentos passam pelo Stripe, na sua conta, e o número do cartão do seu cliente não fica em uma tabela do seu projeto. Essa separação é boa por dois motivos: reduz o que você precisa proteger e tira do seu colo a parte mais regulada do assunto.

O ponto que exige atenção é a configuração de acesso ao banco. Um banco com regras frouxas expõe informação mesmo estando na sua conta, e isso não é característica de projeto gerado: acontece igual em projeto escrito à mão. Pedir explicitamente que cada usuário veja apenas os próprios registros é uma frase no pedido e vale a edição de 3 créditos.

O que acontece com o que eu escrevo no prompt?

Essa é a única camada que fica fora do seu controle direto, e a resposta honesta é: leia a política de privacidade do fornecedor no dia em que você contratar, porque políticas mudam e um artigo não é fonte confiável para isso.

O que dá para recomendar com segurança é o hábito, que vale para qualquer ferramenta de IA. Não cole no pedido aquilo que você não colocaria em um documento compartilhado: senha de outro sistema, chave de API ativa, planilha com dados de clientes, contrato assinado.

Isso quase nunca é necessário. Para gerar um site você precisa descrever público, objetivo e seções, e nada disso exige informação sigilosa. Quando o projeto precisa de uma chave de serviço externo, ela entra pelas integrações e não pelo texto da conversa.

O caso em que a regra é mais rígida: dados de terceiros. Colar a lista de pacientes de uma clínica no pedido para "criar uma tela com esses nomes" é um problema legal antes de ser um problema técnico, e a saída correta é gerar a tela vazia e importar os dados pelo banco.

E se eu parar de usar a ferramenta?

Essa é a pergunta de segurança que quase ninguém faz e que tem o maior impacto prático. Segurança inclui continuidade: um projeto que só existe dentro de um painel alheio depende de esse painel continuar existindo com as mesmas regras.

O código sai para um repositório seu no GitHub, e essa exportação não consome crédito. A partir daí ele é um repositório comum: você clona, versiona e passa para quem quiser, com o processo explicado em dá para exportar o código?.

A publicação também pode ir para a sua conta na Vercel, o que torna a entrega independente. São duas independências separadas, a do código e a da hospedagem, e ter uma não implica ter a outra.

Os dados dos seus clientes já estão do lado de fora por construção, no Supabase e no Stripe. Somando as três camadas, sair deixa de ser um evento traumático e vira uma tarefa de uma tarde. Guardar cópias periódicas fecha o assunto, e o método está em como fazer backup do projeto.

Quem responde pela LGPD do meu site?

Você, se o site é seu e coleta dados de pessoas. Isto não é orientação jurídica e um advogado é quem deve olhar o seu caso concreto, mas a lógica geral da LGPD costuma cair sobre quem decide o que coletar e para quê.

Na prática, isso se traduz em três obrigações que independem da ferramenta. Ter uma política de privacidade que descreva o que você coleta e por quê. Pedir consentimento quando ele for necessário. Conseguir atender um pedido de exclusão dentro de um prazo razoável.

O erro comum em projeto pequeno é coletar por reflexo. Formulário com oito campos quando três resolvem, cadastro obrigatório para ver o preço, telefone exigido em um contato que poderia ser por e-mail. Cada campo a mais é um dado a mais para proteger e justificar.

A recomendação prática é inverter o padrão: comece pelo mínimo e adicione campo apenas quando alguém conseguir explicar o uso. Isso reduz o seu risco, aumenta a taxa de preenchimento do formulário e não custa nada além de um pedido bem escrito.

O que a verificação antes da entrega garante?

Antes de chegar até você, a construção é aberta em um ambiente isolado para checar se ela roda. Uma versão que não abre é reportada como falha em vez de ser entregue quebrada.

É importante ser exato sobre o alcance disso. A verificação responde "isto funciona?", não "isto está seguro?". São perguntas diferentes, e prometer a segunda a partir da primeira seria desonesto.

Segurança de aplicação depende de decisões que aparecem no seu pedido e nas suas configurações: quem pode ver o quê, o que é público, como as senhas são tratadas, qual serviço externo recebe qual chave. Nada disso é adivinhado pela ferramenta.

Por isso, em projeto que guarda dado de outras pessoas, o limite honesto precisa ser dito: o Zugo não substitui um time de desenvolvimento em um produto complexo. Para um cadastro simples ou uma loja pequena, o conjunto padrão dá conta. Para saúde, finanças ou volume grande de dados pessoais, vale ter alguém revisando antes de abrir ao público.

Que perguntas fazer a qualquer fornecedor?

Cinco perguntas separam uma escolha informada de uma aposta, e elas servem para qualquer ferramenta do mercado, inclusive esta.

Se as respostas às duas primeiras forem "não", o preço deixa de ser o critério principal da comparação. Um serviço barato do qual você não consegue sair é caro no primeiro dia em que precisar sair.

Como reduzir risco sem virar especialista?

Quatro hábitos cobrem a maior parte do que dá errado em projeto pequeno, e nenhum deles exige conhecimento técnico.

Colete o mínimo. Cada campo que você não pede é um dado que não pode vazar, não precisa de justificativa e não entra em pedido de exclusão.

Peça a regra de acesso explicitamente. "Cada usuário vê apenas os próprios dados e ninguém acessa a lista completa" é uma frase que muda o comportamento do banco e cabe em uma edição.

Guarde cópias em algum ritmo. Exportar o código e baixar os dados uma vez por mês é chato e resolve o cenário que mais assusta.

Revise o que está público. Abra o site em uma janela anônima e tente chegar em algo que deveria exigir login. Esse teste leva dois minutos, não custa crédito e pega o erro mais frequente de projeto novo. Dá para montar e testar esse fluxo inteiro em zugo.dev antes de convidar o primeiro usuário de verdade.