Segurança
Como separar dado real de dado de teste (o que a LGPD cobra)
Testar com a base de produção é o atalho mais comum e o mais caro. Separar ambiente é mais simples do que parece, e a LGPD não trata isso como detalhe.
Tem um atalho que quase todo mundo pega no começo: testar direto na base de verdade.
É mais rápido. Os dados já estão lá, o cenário é real, não precisa inventar nada.
E é o atalho mais caro que existe.
Por que isso é problema, e não frescura
Primeiro, o lado prático. Teste quebra coisa. É pra isso que serve. A diferença é que quebrar em ambiente de teste é terça-feira comum, e quebrar em produção é o pedido do cliente sumindo.
Basta um comando de limpeza rodado na janela errada. Todo mundo que trabalha com isso há tempo suficiente tem essa história.
Segundo, o lado legal, que muita gente não enxerga. A LGPD exige finalidade específica para cada tratamento de dado pessoal. Seu cliente entregou o dado dele pra receber um serviço. Não entregou pra ser massa de teste.
Usar a base real em desenvolvimento é tratamento fora da finalidade. E tem um agravante silencioso: cada cópia local multiplica o número de lugares onde aquele dado existe e o número de pessoas que alcança ele. Você deixa de saber onde o dado do seu cliente está.
O teste de uma pergunta
Roda o projeto na sua máquina e responde:
Eu consigo apagar, daqui, um registro de um cliente de verdade?
Se a resposta é sim, não existe separação. Existe um único ambiente com dois nomes.
Como separar, em três partes
1. Dois bancos. Um de produção, um de desenvolvimento. Nos serviços que você já usa isso costuma ser criar um segundo projeto, e o segundo geralmente cabe no plano gratuito porque tem pouco dado.
2. Duas credenciais. Cada ambiente com as suas. A credencial de produção sai da sua máquina e vive só onde a aplicação roda de verdade. Isso vale mais que a separação em si: enquanto a chave de produção estiver no seu computador, qualquer descuido alcança o cliente.
3. Dados de mentira. Aqui tem duas escolhas.
A boa: gerar dados fictícios. Cinquenta usuários inventados, alguns pedidos, alguns casos estranhos de propósito. Nome com acento, e-mail gigante, campo vazio, valor negativo. Você ganha uma base que exercita o sistema melhor que a real.
A aceitável: copiar da produção e anonimizar, trocando nome, e-mail e documento por valores falsos consistentes. O cuidado é fazer direito. Anonimização meia boca é pior que nenhuma, porque dá sensação de proteção sem proteger.
Onde a IA ajuda de verdade
Gerar massa de teste é uma das tarefas em que a IA é boa e ninguém usa.
Peça uma base fictícia com os casos difíceis incluídos, e seja específico sobre o que quer ver ali: campo vazio, texto com acento e emoji, valor negativo, data invertida, nome muito longo. Vai levar dois minutos e cobre mais borda do que sua base real cobre.
O que ela não vai fazer sozinha é lembrar você de separar os ambientes. Isso é decisão, e decisão continua sendo sua, como em toda a camada de blindagem.
Se você já está testando em produção
Não precisa parar tudo hoje. Precisa parar de piorar.
Comece pelo mais perigoso: tire a credencial de produção da sua máquina. Depois crie o ambiente de desenvolvimento e vá movendo o trabalho pra lá.
Uma hora de trabalho pra nunca mais ter aquele frio na barriga de rodar um comando e pensar "espera, em qual banco eu estava?".
A decisão é sua.
Perguntas frequentes
Perguntas rápidas
+Testar com dado real é ilegal?
A LGPD exige finalidade específica para cada tratamento. O cliente forneceu o dado para receber um serviço, não para servir de massa de teste. Usar em desenvolvimento é tratamento fora da finalidade, e ainda multiplica o número de cópias e de pessoas com acesso.
+Qual o jeito mais rápido de separar?
Crie um segundo projeto no seu provedor, exclusivo para desenvolvimento, com credenciais próprias. Sua máquina aponta só para ele. Produção passa a ter credencial que não fica no seu computador.
+De onde tiro dados para testar?
Duas fontes: gerar fictício, que é o ideal, ou anonimizar uma cópia da produção, trocando nome, e-mail e documento por valores falsos consistentes. Anonimizar mal é pior que não anonimizar, porque dá falsa sensação de segurança.
+E se eu já venho testando em produção?
Comece pelo mais perigoso: tire de circulação a credencial de produção que está na sua máquina e crie o ambiente de desenvolvimento. Depois vá movendo o trabalho para lá. Não precisa parar tudo, precisa parar de piorar.
Continue lendo
O risco não é o código que você escreve. É o que você instala
Hackers injetaram malware no open source da Microsoft. A lição pra quem constrói com IA: seu maior risco não é o código que você escreve: é o que você instala.
SegurançaVocê soltou um agente de IA sem revisar o que ele pode
88% das empresas já tiveram incidente com agente de IA, mas só 14% subiram com aval de segurança. O que esse abismo ensina pra quem constrói com IA.
SegurançaSe a segurança mora no prompt, não é segurança
O system prompt de uma IA de ponta vazou no GitHub e revelou que a defesa era só texto. A lição pra quem constrói com IA: trava de verdade mora em camadas.