LGPD em app feito com IA: os sinais de que ninguém revisou o tratamento de dado

Quem constrói um aplicativo com Lovable, Cursor, n8n ou Claude Code costuma validar a ideia primeiro e pensar em conformidade depois, se pensar. O problema aparece quando esse protótipo passa a receber dado real de cliente, paciente ou lead, e ninguém nunca parou para mapear o que a LGPD exige daquele fluxo. Não é má-fé, é o preço natural de construir rápido sem uma etapa de revisão. Este texto lista os sinais concretos de que isso já aconteceu no seu projeto, e o que fazer a partir daí sem travar o que já está no ar.

O ponto cego que a velocidade cria

Ferramentas de IA generativa comprimiram meses de desenvolvimento em dias. O que elas não comprimem é a etapa que, num processo tradicional, forçaria alguém a parar e perguntar o que aquele formulário faz com o CPF que acabou de coletar, ou por que aquele campo de observações vai direto para um modelo de linguagem de terceiro sem nenhum filtro. Quando o ciclo é prompt, teste, deploy, essa pergunta simplesmente nunca chega à mesa, porque não existe mesa: existe só o próximo prompt.

O resultado é um aplicativo que funciona bem, valida a ideia e, silenciosamente, acumula um passivo de conformidade proporcional ao volume de dado real que passou a processar. Quanto mais o protótipo dá certo, maior fica esse passivo, porque mais gente e mais dado entram nele todos os dias.

Os sinais de que ninguém revisou o tratamento de dado no seu app

1. Dado sensível circula sem controle de acesso por usuário

Se qualquer pessoa autenticada no sistema consegue, mudando um número na URL ou olhando uma tabela, ver dado de outro cliente que não é o dela, o problema não é só de segurança da informação, é de tratamento de dado sem controle de acesso, um dos pontos que a LGPD cobra diretamente.

2. Ninguém sabe apontar a base legal do tratamento

Pergunte para quem construiu o app: por que qual base legal (consentimento, execução de contrato, legítimo interesse) esse dado está sendo coletado e usado. Se a resposta for "porque precisávamos para a funcionalidade funcionar", sem nenhuma decisão consciente por trás, essa base nunca foi definida, só foi assumida.

3. Excluir ou exportar o dado de uma pessoa depende de mexer direto no banco

Direito de acesso, correção e eliminação são obrigações da lei, não cortesia. Se atender um pedido desses hoje significa abrir o banco de dados na mão e escrever uma query, o app não tem esse direito operacionalizado, só tem alguém disposto a resolver na unha quando o pedido chegar.

4. Ferramentas de IA e webhooks recebem dado real sem necessidade

É comum um protótipo mandar o payload inteiro de um formulário para um modelo de IA externo, ou para um webhook de automação, porque foi mais rápido enviar tudo do que filtrar o que de fato precisa sair dali. Cada envio desnecessário de dado pessoal para um terceiro é uma superfície a mais de risco, e normalmente ninguém documentou para quantos serviços externos aquele dado já viajou.

5. Ninguém consegue responder quem tem acesso a isso hoje

Se a pergunta "quem, com que login, consegue ver a base de clientes inteira agora" não tem resposta rápida e precisa, o controle de acesso não existe como política, existe como acidente de arquitetura. É o sinal mais simples de testar, e o mais revelador.

Por que isso se repete tanto em projeto construído com IA

Não é falta de cuidado de quem constrói, é ausência de uma etapa que o processo tradicional de desenvolvimento, mesmo o mais informal, costumava forçar por atrito: código revisado por outra pessoa antes de subir, ambiente de homologação separado do de produção, alguém perguntando "isso aqui pode mesmo receber dado real?". Vibe coding remove esse atrito de propósito, é o que o torna rápido, e remove junto o freio que existia para essa pergunta.

O que fazer sem parar de construir

A correção não exige jogar fora o que já existe nem contratar um departamento jurídico. Exige uma revisão pontual, com prioridade no que é crítico primeiro:

• Mapear, campo por campo, qual dado pessoal o sistema coleta e para onde cada um viaja, incluindo toda ferramenta de IA e todo webhook de automação.
• Definir a base legal de cada tratamento e registrar essa decisão em algum lugar, mesmo que simples.
• Isolar o acesso por usuário e por conta, testando de fato se um cliente enxerga o dado de outro.
• Reduzir o que é enviado a terceiros ao mínimo necessário para a funcionalidade funcionar, não ao que é mais fácil de implementar.
• Criar um caminho, ainda que manual no início, para atender pedido de exclusão ou exportação de dado sem precisar abrir o banco na mão.

Nenhum desses pontos é exclusivo de app feito com IA: são a mesma auditoria que qualquer sistema que trata dado pessoal deveria passar. A diferença é que, em vibe coding, ninguém parou para fazer essa auditoria antes de o sistema já estar em uso com cliente de verdade dentro.

Ter LGPD no radar não é o mesmo que ter LGPD auditada

Muita empresa responde "sim, a gente sabe da LGPD" quando pergunta é sobre intenção, não sobre prática. Saber que a lei existe não corrige controle de acesso quebrado, não define base legal retroativamente e não documenta para onde o dado já viajou até aqui. Entre saber que o tema importa e ter uma auditoria concreta desses cinco pontos, existe uma distância que só se fecha revisando o código e os fluxos de dado que estão de fato em produção.

Se o seu time reconheceu mais de um desses sinais no aplicativo que construiu, vale mapear o tamanho real do risco antes de continuar escalando o uso. O diagnóstico gratuito do projeto de IA, 45 minutos com um engenheiro, existe para isso: você sai com o mapa de riscos do que já foi construído, incluindo o que precisa de correção de LGPD, feche ou não com a gente depois. Acesse /construa-com-ia.