Fiz meu sistema com IA. É seguro? Um checklist de 15 minutos

Você construiu um sistema conversando com uma IA. Ele funciona, as pessoas estão usando e agora bate a dúvida: será que está seguro?

Este checklist não substitui uma revisão profissional, mas cobre os problemas que mais aparecem em projetos feitos assim. Dá para fazer em uns 15 minutos, e cada item tem uma pergunta simples e o que fazer se a resposta for "não sei".

Se você ainda está decidindo se o seu protótipo já virou produto, comece pelo guia Vibe coding: do protótipo ao produto.

1. Segredos no código

A pergunta: existe alguma chave, senha ou token escrito direto no código?

Chaves de API (de pagamento, de e-mail, de IA, de banco de dados) costumam aparecer no código porque é o jeito mais rápido de fazer funcionar. O problema é quando esse código roda no navegador: qualquer pessoa pode abrir as ferramentas do desenvolvedor e ler.

Como verificar: peça para a própria IA: "liste todos os lugares do projeto onde existem chaves, senhas ou tokens". Depois abra o site, aperte F12, vá na aba de rede ou de fontes e procure por "key", "secret" ou "token".

O que fazer: chaves secretas devem ficar no servidor, em variáveis de ambiente, nunca no código que vai para o navegador. Se alguma já esteve exposta, troque a chave no painel do serviço. Apagar do código não basta, porque ela pode ter sido copiada antes.

2. Regras de acesso ao banco de dados

A pergunta: se alguém descobrir o endereço do seu banco de dados, o que consegue ler ou alterar?

Serviços como Supabase e Firebase são muito usados em projetos feitos com IA. Eles permitem que o navegador fale direto com o banco, o que é prático, mas exige regras dizendo quem pode ler e escrever o quê. Sem essas regras, o banco pode ficar aberto para qualquer pessoa.

Como verificar: no painel do serviço, procure por "Row Level Security" (Supabase) ou "Security Rules" (Firebase). Veja se estão ativadas em todas as tabelas e se não existe nenhuma regra do tipo "todo mundo pode ler e escrever".

O que fazer: ative as regras em todas as tabelas e escreva, para cada uma, quem pode ver e quem pode alterar. Por exemplo: "cada usuário só vê os próprios pedidos".

3. Login e permissões

A pergunta: o sistema confere, a cada ação, se aquela pessoa pode fazer aquilo?

Um erro comum é esconder um botão na tela para quem não é administrador, mas deixar a ação funcionando para qualquer um que chame o endereço certo. Esconder não é proteger.

Como verificar: entre com um usuário comum e tente acessar diretamente o endereço de uma página de administrador. Tente também trocar um número na barra de endereço (por exemplo, /pedido/120 para /pedido/121) e veja se aparece o pedido de outra pessoa.

O que fazer: a verificação de permissão precisa acontecer no servidor ou nas regras do banco, em toda ação, e não só na tela.

4. Dados pessoais

A pergunta: você sabe exatamente quais dados de clientes o sistema guarda, e por quê?

Nome, telefone, e-mail, CPF e endereço são dados pessoais, e guardá-los coloca o seu sistema sob a LGPD. Muitas vezes o sistema coleta mais do que precisa, só porque o formulário veio assim.

O que fazer: liste os dados que você coleta e risque os que não usa. Menos dados guardados significa menos risco se algo vazar.

5. Dependências

A pergunta: as bibliotecas que o projeto usa existem de verdade, são conhecidas e estão atualizadas?

A IA às vezes sugere pacotes com nomes que parecem certos mas não são, ou bibliotecas abandonadas há anos.

Como verificar: abra o arquivo de dependências (em projetos JavaScript, o package.json) e confira cada nome no site do gerenciador de pacotes (npmjs.com, no caso do JavaScript). Desconfie de pacotes com pouquíssimos downloads, sem página oficial ou publicados há poucos dias. Rodar npm audit ou yarn npm audit aponta falhas conhecidas.

6. Mensagens de erro

A pergunta: quando algo dá errado, o que o usuário vê?

Se aparece um texto técnico enorme, com nomes de tabelas, caminhos de arquivos ou trechos de código, você está entregando um mapa do sistema para quem quiser atacá-lo.

O que fazer: mostre ao usuário uma mensagem simples ("algo deu errado, tente de novo") e guarde os detalhes num registro que só a equipe vê.

7. Formulários e uploads

A pergunta: o sistema confere o que recebe antes de guardar?

Um campo de nome que aceita qualquer coisa, inclusive código, ou um upload de imagem que aceita qualquer tipo de arquivo, são portas clássicas para problemas.

O que fazer: valide no servidor o tipo e o tamanho de tudo o que chega. Para uploads, limite as extensões permitidas e o tamanho máximo.

8. Backup

A pergunta: se o banco de dados fosse apagado hoje, você conseguiria recuperar os dados de ontem?

O que fazer: ative o backup automático do serviço que você usa e, pelo menos uma vez, teste a restauração. Backup que nunca foi testado é só uma esperança.

9. Histórico de versões

A pergunta: se uma mudança quebrar o sistema, dá para voltar à versão anterior em minutos?

O que fazer: use controle de versões (Git), mesmo que você trabalhe sozinho. Muitas ferramentas de vibe coding já oferecem integração com o GitHub. Assim, cada mudança fica registrada e pode ser desfeita.

10. Limites de uso e de custo

A pergunta: se alguém fizer mil cadastros falsos por minuto, ou disparar milhares de chamadas para a IA, o que acontece com a sua conta?

O que fazer: configure alertas e limites de gasto nos serviços cobrados por uso. Onde possível, limite quantas ações cada usuário pode fazer por minuto.

Como usar o resultado

Marque cada item como "ok", "não" ou "não sei". Os itens 1, 2 e 3 são os mais urgentes: um "não" ou "não sei" em qualquer um deles merece atenção ainda esta semana, principalmente se o sistema guarda dados de clientes ou movimenta dinheiro.

Se a lista de "não sei" ficou longa, isso não é motivo para pânico. É só o sinal de que o projeto cresceu além do que dá para cuidar no improviso, e que vale ter alguém de engenharia olhando junto.

Se você fez o checklist e quer uma segunda opinião sobre o que encontrou, vale uma conversa.