Segurança de app feito com IA: o checklist antes de colocar dados de cliente

Um app de brinquedo, feito num fim de semana pra resolver um problema interno, vira risco no minuto em que passa a guardar nome, telefone, CPF ou histórico de compra de cliente real. O checklist mínimo antes de colocar dado de verdade nesse app cobre seis pontos: autenticação real (nada de senha fixa no código), permissão por usuário, criptografia do dado sensível, backup testado, LGPD básica e a pergunta certa pro fornecedor de IA sobre onde esse dado roda.

O que muda quando um app interno passa a guardar dado de cliente?

Muda o nível de risco, não o tamanho do projeto. Um app que só calcula uma métrica interna pode falhar sem grande consequência. Um app com nome, telefone ou CPF de cliente vazado vira incidente de LGPD, mesmo tendo sido feito num fim de semana com IA.

A confusão comum é achar que “é só uma ferramenta interna pequena” isenta de responsabilidade:

• O tamanho do time não muda a régua: a lei olha pro dado, não pro tamanho de quem fez o app.
• O tamanho do app não muda a régua: um script de fim de semana com CPF de cliente segue a mesma exigência de um sistema grande.

Imagine, de forma hipotética, uma farmácia com 3 balconistas usando uma planilha virada app pra controlar fidelidade de cliente. No dia em que esse app passa a guardar CPF e histórico de compra, ele entra na mesma régua de segurança de qualquer sistema comercial.

Autenticação de verdade: por que senha fixa no código é o erro mais comum?

Porque é o caminho mais rápido durante a construção. Quando você pede pra IA “criar um login simples”, ela às vezes gera uma senha fixa escrita direto no código (hardcoded) só pra destravar o teste, e isso vira uma porta aberta em produção.

O que resolve, sem exigir conhecimento técnico avançado:

• Autenticação de verdade via um provedor pronto (Supabase Auth, Clerk, Auth0, ou login nativo do Google/Microsoft), nunca senha escrita à mão no código.
• Nenhuma credencial em texto puro no repositório: senha, chave de API e token ficam em variável de ambiente, não no arquivo que qualquer um com acesso ao código consegue ler.
• Teste simples: peça pra IA buscar e listar se alguma senha ou chave está escrita direto no código antes de subir.

Sendo bem sincero, esse é o item que mais aparece em app feito rápido com IA, porque o modelo otimiza pra funcionar agora, não pra estar seguro depois.

Permissão por usuário: como evitar que qualquer um veja o dado de todo mundo?

Definindo, desde o início, quem enxerga o quê. Sem isso, o padrão mais comum de app construído rápido é todo usuário logado ver o banco de dados inteiro, porque foi mais simples de construir assim.

Dois níveis resolvem a maior parte dos casos:

• Permissão por papel (RBAC): administrador vê tudo, vendedor vê só os próprios clientes, atendente vê só o que precisa. A IA constrói isso se você pedir explicitamente, ela não assume sozinha.
• Permissão por linha (row-level security): em bancos como Supabase e Postgres, dá pra travar no próprio banco quem acessa qual registro, mesmo que alguém tente burlar pela tela.

Teste prático: peça pra um segundo usuário, sem privilégio de administrador, tentar ver o cadastro de um cliente que não é dele. Se conseguir, a permissão não está pronta.

Dado sensível precisa de criptografia? Quais campos entram nessa lista?

Precisa, e a lista é mais curta do que parece. CPF, dado de cartão, informação de saúde e senha de usuário são os quatro que mais aparecem em app de PME e exigem tratamento especial.

• Senha de usuário: nunca fica salva em texto puro. O padrão de mercado é hash irreversível (bcrypt ou Argon2), não criptografia reversível.
• CPF, dado de saúde: criptografia em repouso, com AES-256 como padrão de mercado, além de conexão criptografada em trânsito (HTTPS/TLS, que a maioria dos serviços de deploy já entrega por padrão).
• Dado de cartão: como estimativa conservadora, evite guardar dentro do seu app. Delegue pra um processador homologado (Stripe, Mercado Pago, PagSeguro), que já resolve PCI-DSS pra você.

A pergunta que resolve a maioria dos casos: “esse campo, se vazar amanhã, causa dano real pro cliente?” Se a resposta for sim, ele entra na lista de criptografia.

Qual é o backup mínimo aceitável pra um app interno com dado de cliente?

O mínimo aceitável é backup automático, em local separado do banco principal, testado ao menos uma vez. A regra de mercado conhecida como 3-2-1 resume bem: 3 cópias do dado, em 2 tipos de mídia diferentes, com 1 cópia fora do ambiente principal.

Na prática, pra um app pequeno:

• Backup automático diário, não manual. Supabase e a maioria dos bancos gerenciados já oferecem isso configurável em poucos cliques.
• Retenção de 7 a 30 dias de backups anteriores, pra cobrir o erro descoberto tarde (alguém apaga um cadastro e só nota uma semana depois).
• Teste de restauração ao menos uma vez. Backup que nunca foi restaurado é uma suposição, não uma garantia.

Não acho que dá pra tratar backup como “depois eu configuro”. Ele precisa existir antes do primeiro dado real de cliente entrar no app.

O que a LGPD exige de um app interno pequeno?

Exige o mesmo conjunto básico que qualquer sistema que trata dado pessoal, ajustado pro tamanho do projeto: minimização, base legal e transparência. Detalhamos isso em profundidade no nosso guia de LGPD e IA no WhatsApp, e os mesmos princípios valem aqui.

Os três pontos que mais pesam num app interno de PME:

• Minimização: colete só o dado que o app realmente usa, não peça um campo a mais só porque “pode ser útil depois”.
• Base legal: pra atendimento e relação comercial em andamento, legítimo interesse (art. 7º, inciso IX) costuma cobrir. Numa finalidade nova, como campanha, aí sim entra consentimento explícito.
• Direito do titular: o cliente pode pedir acesso, correção ou exclusão do dado dele (art. 18), mesmo num app interno de 5 usuários.

A LGPD prevê multa de até 2% do faturamento, limitada a R$50 milhões por infração (art. 52). Não existe piso de faturamento que isenta a empresa dessa régua.

Que pergunta fazer pro fornecedor de IA sobre onde o dado do cliente roda?

Antes de colocar dado real de cliente num app construído com Claude, ChatGPT ou qualquer outra IA, valem cinco perguntas de due diligence, sem exigir conhecimento técnico:

1. O dado que passa pela IA durante o desenvolvimento (prompts, arquivos anexados) é usado pra treinar modelo de terceiro?
2. Onde fica hospedado o banco de dados do app depois de pronto (Brasil ou fora)?
3. O provedor de hospedagem (Vercel, Supabase, Cloudflare) tem contrato de processamento de dados (DPA) disponível?
4. Existe algum subprocessador na cadeia (outro serviço que recebe o dado por trás) que você não escolheu diretamente?
5. Qual é o prazo de retenção padrão desses serviços, e dá pra configurar exclusão?

Sendo bem sincero, a maioria de quem constrói um app rápido com IA nunca fez essas perguntas, porque o fluxo de “pedir pra IA construir” não força essa pausa. Ela precisa ser deliberada, antes do primeiro dado de cliente real entrar no sistema.

Quando o projeto exige revisão de um dev de verdade?

Quando a criticidade do dado ou da operação passa de um ponto que checklist e boas práticas genéricas não cobrem mais. Não é sobre o tamanho da empresa, é sobre o tipo de dado e o tipo de uso.

Casos que pedem revisão profissional, mesmo que o app tenha nascido com IA:

• Dado sensível em escala (milhares de CPFs, saúde, dado financeiro de terceiros).
• Exigência de compliance setorial (saúde, financeiro, jurídico) com auditoria formal prevista.
• Sistema que vai externo, com cliente fora da empresa acessando diretamente.
• Lógica de permissão complexa, com múltiplos papéis e regras cruzadas.

Nesses casos, uma revisão pontual de dev, focada em segurança, resolve a maior parte do risco sem jogar fora o que já foi construído com IA. É o mesmo raciocínio da nossa análise de custo entre ferramenta interna com IA e dev contratado: a decisão certa depende da criticidade do problema, não do orçamento disponível.

FAQ

Preciso contratar um dev antes de colocar qualquer dado de cliente num app feito com IA? Não necessariamente. Pra um app interno simples, com autenticação real, permissão por usuário e criptografia básica nos campos certos, dá pra seguir sem dev dedicado, aplicando o checklist deste artigo com cuidado. A revisão profissional se torna necessária quando o dado é sensível em escala (saúde, financeiro, muitos CPFs) ou existe exigência formal de compliance setorial. Na dúvida sobre o próprio caso, uma revisão pontual de segurança, focada nos pontos mais críticos, já reduz boa parte do risco antes de escalar o uso do app.

Senha fixa no código é sempre um problema, mesmo em app que só o time interno usa? Sim. Mesmo um app só pro time interno pode vazar código-fonte (repositório compartilhado sem querer, backup mal configurado, saída de funcionário, notebook perdido). Senha fixa escrita no código fica exposta em qualquer um desses cenários, mesmo sem ninguém mal-intencionado por perto. O correto é sempre variável de ambiente e um provedor de autenticação de verdade, independente do público do app. Peça pra IA revisar o próprio código em busca de senha ou chave escrita direto no arquivo antes de considerar o app pronto pra uso.

Como sei se um campo do meu app precisa de criptografia? Pergunte se esse dado, caso vazasse amanhã, causaria dano real pro cliente. CPF, dado de cartão, saúde e senha de usuário quase sempre entram nessa lista. Senha nunca fica em texto puro, usa hash (bcrypt ou Argon2), nunca criptografia reversível. Os demais campos sensíveis pedem criptografia em repouso, com AES-256 como padrão de mercado, além de conexão criptografada em trânsito (HTTPS). Dado de cartão, como estimativa conservadora, o mais seguro é nem guardar dentro do próprio app: delegue pra um processador homologado, como Stripe ou Mercado Pago.

Um app interno de 5 pessoas também precisa seguir a LGPD? Precisa. A LGPD regula o tratamento de dado pessoal, não o tamanho da empresa nem quantas pessoas usam o sistema. Se o app guarda nome, telefone ou CPF, os princípios de minimização, base legal e direito do titular se aplicam do mesmo jeito que se aplicariam a um sistema grande. Na prática, isso significa coletar só o dado necessário, ter uma justificativa clara pra guardar cada campo e conseguir responder rápido se o cliente pedir acesso, correção ou exclusão do próprio dado.

Backup automático do provedor de hospedagem já é suficiente? Na maioria dos casos de app interno, sim, desde que a retenção seja configurada (7 a 30 dias é uma faixa comum) e o backup seja testado ao menos uma vez com uma restauração real. O erro mais comum não é a ausência de backup, é nunca ter verificado se ele realmente restaura o dado quando precisa. Backup automático que nunca passou por um teste de restauração é uma suposição de segurança, não uma garantia, e só aparece como problema no pior momento possível.

Posso perguntar direto pro Claude ou ChatGPT se o app que ele construiu tem falha de segurança? Pode e vale a pena, como primeira camada de checagem, antes de qualquer revisão profissional. Peça pra revisar o código procurando senha ou chave escrita direto no arquivo, verificar se existe controle de permissão por usuário e confirmar se o backup automático está ativo. Isso não substitui revisão humana em casos críticos, com dado sensível em escala ou exigência formal de compliance, mas resolve boa parte dos erros comuns antes de chegar numa revisão profissional paga.