Inventário de PII para banco de protótipo: localizar e reduzir dados

Por que você precisa de um inventário de PII antes do seu protótipo crescer

Protótipos coletam dados sensíveis mais rápido do que você imagina. Um simples formulário de cadastro adiciona emails e nomes. Um fluxo de convite cria mais emails. O login adiciona tokens. Logs de debug copiam isso de novo. Em pouco tempo, seu “aplicativo de teste” está guardando dados reais de pessoas em lugares que você nunca quis manter.

O risco não é só uma violação. É também confusão e retrabalho. Se emails e tokens ficam sem dono, você não consegue responder perguntas básicas: quem pode ver esses dados? Quanto tempo os mantemos? Podemos apagar a pedido? Quando o protótipo vira um produto real, você acaba fazendo uma limpeza de emergência enquanto tenta lançar funcionalidades.

Um inventário de PII reduz esse risco rápido. Não é papelada. É um mapa de para onde os dados pessoais vão, junto com um plano para coletar menos e apagar no prazo. Essa página muda como você constrói: você para de adicionar campos “só por precaução”, percebe quando tokens estão armazenados em texto puro, e define uma regra de retenção antes que o banco cresça.

No final, você quer dois resultados: um mapa claro de dados (onde emails, nomes e tokens são criados, armazenados, copiados e enviados) e um plano de retenção (o que manter, o que evitar coletar e quando expirar ou excluir). Pelo caminho, você também terá uma lista curta de pontos de alto risco (logs, eventos de analytics, backups, visões administrativas, tabelas esquecidas) e um responsável para cada repositório de dados.

Se você herdou um protótipo gerado por IA (de ferramentas como Bolt, v0, Cursor ou Replit), isso importa ainda mais. Essas builds frequentemente copiam segredos em arquivos de configuração, armazenam tokens sem expiração ou espalham dados de usuários por várias tabelas.

O que conta como PII e dados sensíveis em um protótipo

PII (informação pessoal identificável) é qualquer dado que possa identificar uma pessoa real, sozinho ou quando combinado com outros campos. A parte de “combinado” é o que pega as equipes: um nome de usuário mais o nome da empresa, ou um IP mais um timestamp, pode apontar para um usuário específico.

Comece pelos campos óbvios do perfil do usuário e depois procure cópias sombreadas fora da sua tabela principal de usuários.

PII comum em protótipos inclui emails, nomes, números de telefone, endereços, usernames e handles, data de nascimento, localização, fotos de perfil, metadados relacionados a pagamento (mesmo se você não armazena dados de cartão), endereços IP e identificadores de dispositivo.

Alguns dados nem sempre são PII, mas continuam sensíveis porque podem desbloquear contas ou sistemas. Trate estes como alto risco: tokens de autenticação, IDs de sessão, refresh tokens, links de redefinição de senha ou códigos de uso único, chaves de API, segredos de cliente OAuth e segredos de assinatura de webhooks.

Inclua também lugares que coletam ou duplicam dados discretamente. Protótipos frequentemente vazam PII para logs (corpos de requisição, traces de erro), eventos de analytics (por exemplo, "invite_sent" com um email), tickets de suporte (screenshots, tokens colados) e CSVs exportados compartilhados em bate-papo.

Um exemplo simples: seu fluxo de convite armazena o email do convidado em uma tabela invites, loga a requisição completa em caso de erro e envia analytics com o mesmo email como propriedade. São três locais para rastrear, expirar e excluir.

Liste todo lugar onde seu app pode armazenar ou copiar dados

Um inventário de PII começa com uma ideia simples: dados raramente vivem em apenas um lugar. Protótipos copiam valores por conveniência, e essas cópias viram as partes mais difíceis de encontrar depois.

Mapeie o caminho completo de um detalhe do usuário (como um email) desde o momento em que entra no app até todos os lugares onde pode terminar. Inclua lugares criados pelo seu framework, hosting e ferramentas de terceiros, não apenas o que você codou de propósito.

A maioria das equipes encontra dados pessoais em alguns buckets:

• Tabelas e colunas do banco de dados: tabelas de usuários, tabela de convites, tabelas de auditoria, tabelas temporárias e qualquer coisa que armazene payloads brutos de requisição.
• Provedor de autenticação e armazenamento de perfil: emails e nomes podem viver no banco do app e também em um sistema de auth separado, muitas vezes com metadados extras (último login, IP, dispositivo).
• Uploads de arquivos e armazenamento de objetos: imagens de perfil, importações CSV, anexos e exports gerados. Nomes de arquivo e conteúdo de arquivos podem conter PII.
• Jobs em background, filas e caches: payloads de jobs frequentemente incluem objetos de usuário completos; caches podem mantê-los por mais tempo do que você espera; re-tentativas duplicam dados.
• Relatórios de crash, logs de requisição e painéis administrativos: erros podem capturar headers, cookies e corpos de requisição; telas de busca admin e exports CSV viram outra cópia.

Para cada lugar, registre quais campos são armazenados (email, name, tokens), por que são necessários, quem pode acessá-los e por quanto tempo ficam por padrão. Se você não consegue responder a pergunta de retenção, assuma “para sempre” até definir uma expiração.

Um exemplo rápido: um login por magic link pode armazenar o email em users, armazenar o token em login_tokens, copiar o email para uma fila de jobs para enviar a mensagem e então vazar o token para logs de requisição se você o incluir em uma URL.

Passo a passo: construa seu inventário de PII em uma tarde

Comece com caminhos reais que as pessoas fazem no seu app, não com seu esquema. Escolha 3 a 5 jornadas de usuário que acontecem hoje (ou vão acontecer na próxima semana). As mais comuns são signup, login, redefinição de senha, convidar um colega e checkout. Se você só documentar tabelas, vai perder o que é copiado em logs, analytics e ferramentas de suporte.

Para cada jornada, anote todo campo que você coleta e o motivo simples pelo qual precisa dele. Se você não consegue explicar o motivo em uma frase, é um bom candidato a remover ou adiar.

Depois, trace cada campo de ponta a ponta: onde entra (formulário ou API), onde é validado, onde é armazenado (tabela e coluna) e onde pode ser duplicado (logs, jobs em background, trackers de erro, ferramentas de email).

Uma planilha simples (doc ou spreadsheet) é suficiente. Use uma linha por campo e capture:

• Nome do campo e um valor de exemplo (para clareza)
• Propósito (por que você precisa dele agora)
• Tag de tipo de dado: PII, sensível ou não sensível
• Para onde flui: requisição, tabela/coluna DB, logs, terceiros
• Quem pode acessar (tela admin, acesso direto ao banco, ferramentas de suporte)

Se seu protótipo foi gerado por uma ferramenta de IA, adicione uma checagem extra: procure por logging de debug e payloads de requisição copiados. Esses são lugares comuns onde emails, nomes e tokens acabam sendo armazenados por acidente.

Como localizar emails e nomes no seu banco de dados

Comece com um scan do esquema. A maioria dos campos de email e nome não está escondida, está apenas espalhada. Abra sua lista de tabelas e procure o óbvio primeiro, depois cópias extras que foram adicionadas durante prototipagem rápida.

Verifique nomes de coluna comuns em todas as tabelas, não apenas users. Você procura tanto campos diretos (email, first_name) quanto campos auxiliares (contact_email, displayName, invited_by).

Uma abordagem rápida é buscar padrões no esquema e depois confirmar com algumas linhas de dados.

-- Postgres example: find likely PII columns
select table_name, column_name
from information_schema.columns
where column_name ilike '%email%'
   or column_name ilike '%name%'
   or column_name ilike '%contact%'
order by table_name, column_name;

Depois dos campos óbvios, procure lugares onde emails e nomes se escondem dentro de texto livre ou blobs. Apps protótipo frequentemente despejam input do usuário em uma coluna metadata, notes, message ou json e depois esquecem que existe.

Lugares comuns onde se escondem:

• Campos de texto livre e JSON (notes, message, metadata, profile, payload)
• Migrations e scripts de seed que criaram usuários de teste com emails reais
• Tabelas duplicadas (users + billing/customers + analytics/events)
• Filas e logs armazenados no banco (jobs de email, logs de convite)
• Backups e snapshots (dados antigos podem sobreviver à tabela principal)

Cheque de realidade: se seu app tem convites, provavelmente você armazena emails em pelo menos dois lugares (o registro do usuário e a tabela de convites). Anote onde cada cópia vive e qual é a fonte da verdade.

Onde tokens vivem e o que registrar sobre eles

Tokens são frequentemente o caminho mais rápido para um comprometimento num protótipo. Eles funcionam como chaves: se alguém copia um, pode repetir a ação para entrar, chamar APIs ou redefinir senha. Trate tokens como dados sensíveis mesmo se não forem “pessoais” por si só.

Tipos comuns de token incluem IDs de sessão, refresh tokens, tokens de magic link, tokens de redefinição de senha e tokens de API (para serviços de terceiros ou seus próprios endpoints). O risco aumenta quando tokens são de longa duração, reutilizáveis ou funcionam de qualquer lugar sem checagens extras.

Tokens também acabam em lugares que ninguém espera:

• Tabelas do banco (sessions, auth_tokens, password_resets)
• Cookies do navegador (incluindo "remember me")
• Local storage ou session storage no frontend
• Logs da aplicação e sistemas de tracking (headers de requisição, query strings)
• Templates de email e logs de envio (magic links)

Para cada token, registre o que ele faz, onde é armazenado e por quanto tempo fica válido. Mantenha as regras simples: armazene o mínimo, expire rápido, roteie no uso e armazene tokens com hash quando possível para que um vazamento do banco não dê acesso instantâneo.

Responda a essas perguntas para cada token:

• Que ação esse token permite (login, reset, acesso à API)?
• Onde ele é armazenado e copiado (DB, cookie, logs, email)?
• Qual é o tempo de vida e pode ser reutilizado?
• Como ele é protegido (hash, criptografia, escopo, vinculado a dispositivo/IP)?
• O que acontece no logout, mudança de senha ou cancelamento de convite?

Minimizar coleta: mantenha apenas o que seu protótipo precisa

Um banco de protótipo enche rápido porque é mais fácil salvar tudo do que decidir o que importa. Esse hábito de "salvar tudo" é como você acaba com PII extra, tokens de longa vida e dados que não consegue explicar depois.

Desafie cada campo com uma pergunta: o que quebra se não armazenarmos isto? Se a resposta for "nada, só seria bom", não colete ainda. Você pode adicionar campos opcionais depois, quando tiver certeza de que sustentam uma funcionalidade real.

Progressive profiling ajuda a manter cadastros iniciais simples. Colete o mínimo para o primeiro passo (frequentemente apenas um email), depois peça mais somente quando o usuário chegar a um ponto que realmente precise (cobrança, convites, suporte).

Cortes de alto impacto que funcionam na maioria dos protótipos:

• Use display names em vez de nomes legais completos, salvo motivo claro.
• Não armazene submissões brutas de formulários ou payloads completos para debugging. Logue o erro e um request ID.
• Reduza campos de texto livre. Se precisar tê-los, adicione aviso claro (não cole segredos) e limite de caracteres.
• Campos “nice to have” sejam opcionais e empurrados para um passo posterior.
• Prefira "país" em vez de endereço completo até que envio exija.

Exemplo: um fluxo de convite frequentemente tenta fazer equipes armazenarem nome do convidante, nome do convidado, nota pessoal e histórico completo de emails. Para um protótipo, talvez você só precise do inviter user ID, invitee email, status do convite e um timestamp de expiração.

Crie um plano de expiração e exclusão que você realmente consiga seguir

Um inventário de PII só é útil se terminar com uma regra simples: quando cada coisa expira e como ela é excluída.

Defina janelas de retenção por tipo de dado e escreva-as ao lado de cada tabela ou campo no seu inventário, mesmo que você ainda não as esteja aplicando:

• Cadastros não verificados: deletar após 7 dias
• Contas abandonadas (sem login, sem atividade): deletar após 30–90 dias
• Emails de suporte ou formulários de contato: deletar após 90 dias
• Logs de auditoria (evite PII se possível): manter 30–180 dias
• Backups: mantenha a menor janela possível (para protótipos, 7–30 dias costuma ser suficiente)

Tokens merecem regra própria porque são fáceis de usar indevidamente e difíceis de detectar depois. Expire tokens de sessão e reset rapidamente e assegure que você pode invalidá-los cedo. Uma baseline razoável é tokens de acesso em minutos, refresh tokens em dias, e revogar todos os tokens na mudança de senha.

Auto-delete é o que torna o plano real. Adicione um job de limpeza agendado que rode diariamente: remova usuários não verificados passados do cutoff, delete registros de invite após aceitos ou expirados, e limpe tokens antigos.

Pedidos de exclusão de usuário devem ser previsíveis. Defina o escopo para não perder cópias escondidas:

• Excluir perfil do usuário e registros de autenticação
• Excluir ou anonimizar conteúdo relacionado (comentários, projetos, arquivos)
• Deletar tokens, sessões e chaves de API
• Remover de exports e ferramentas de terceiros daqui pra frente
• Registrar um log mínimo de exclusão (sem PII extra)

Backups e exports são a parte difícil. Talvez hoje você não consiga apagar cirurgicamente backups antigos, mas pode planejar: encurtar retenção de backups, parar de exportar PII bruto por padrão e rotacionar exports antigos numa agenda.

Controles de acesso e logging sem complicar demais

Você não precisa de uma solução enterprise para proteger um protótipo. Precisa de papéis claros, menos chaves circulando e logging suficiente para responder uma pergunta depois: quem olhou ou mudou dados sensíveis?

Escreva só os papéis que você tem hoje. A maioria dos protótipos cabe num conjunto pequeno: fundador/admin (acesso total), suporte (somente leitura a registros de usuário), contratado (acesso apenas à parte que desenvolve) e uma conta admin de "break-glass" usada raramente. O objetivo é impedir que “todo mundo vê tudo” vire permanente.

Um plano simples de acesso que funciona:

• Dê a cada pessoa seu próprio login. Não use usuários de banco compartilhados nem senhas admin compartilhadas.
• Limite acesso direto ao banco a 1–2 pessoas. Todo mundo usa a tela admin do app.
• Use acesso somente leitura para suporte quando possível e limite no tempo o acesso de contratados.
• Revise acessos mensalmente e remova contas desnecessárias.
• Tenha uma conta admin de emergência, guardada com segurança e usada só quando preciso.

O logging pode ser leve. Registre ações administrativas que toquem PII: visualizar perfil, exportar usuários, resetar senha, mudar email, gerar links de convite. Mesmo um log básico com timestamp, usuário admin, ação e registro alvo é suficiente para detectar erros e responder a dúvidas.

Mascare PII sempre que puder. Em telas admin, mostre só o necessário (por exemplo, email parcial como j***@domain.com). Em logs, evite armazenar emails completos, nomes ou tokens. Logue IDs em vez disso.

Por fim, mantenha segredos fora do código e fora do banco. Chaves de API, segredos de assinatura JWT e salts de token de redefinição devem viver em um storage de segredos apropriado, não em um arquivo de configuração ou tabela de settings.

Exemplo: inventário rápido de PII para um protótipo de signup e convite

Imagine um protótipo gerado por IA: usuários se cadastram com email, criam um workspace e convidam colegas por email. Funciona em testes, mas ninguém documentou onde os dados pessoais ficam.

Percorra o fluxo completo uma vez (signup, convite, redefinição de senha) e depois pesquise onde os dados caem e onde são copiados. Em uma configuração típica você encontrará PII em mais de um lugar:

• Tabelas do banco: users (email, name), invites (invitee email, inviter id), audit_logs (às vezes armazena payloads brutos)
• Logs do app: corpos de requisição, logs de erro, logs de jobs em background
• Provedor de email: templates, webhooks de eventos, logs de entrega que incluem endereços dos destinatários
• Analytics/monitoramento: identificadores de usuário, às vezes emails completos se alguém os logou por engano
• Caches e filas: payloads de convite ou eventos de auth mantidos mais do que o esperado

Uma descoberta comum de risco é o tratamento de tokens. Por exemplo, o protótipo pode armazenar um token de redefinição de senha em texto puro na tabela password_resets, sem expiração (ou com padrão de 30 dias). Se alguém obtiver acesso de leitura ao banco, pode usar esse token para tomar contas. Registre se tokens são hasheados, quanto tempo vivem e se podem ser usados mais de uma vez.

Decida então o que parar de coletar agora versus depois. Muitos protótipos não precisam de nomes completos no cadastro, e convites geralmente não precisam manter o email do convidado para sempre depois de aceitos ou expirados.

Aqui está uma tabela de retenção simples que você pode colar em um doc e atribuir um responsável:

Erros comuns que mantêm PII e tokens por aí

A maioria dos protótipos não vaza dados por causa de um grande hack. Vaza porque pequenas escolhas se acumulam e ninguém volta para limpar.

Uma armadilha comum é tratar dados de teste como inofensivos. Equipes colam emails reais de clientes, nomes e telefones em seed files, telas admin e importações CSV. Uma semana depois, esse mesmo banco é copiado para o laptop de um colega ou um servidor de staging. Agora PII real está em três lugares e ninguém lembra de onde veio.

Outro vazamento discreto é logar demais. Logs de debug que armazenam corpos completos de requisição ou headers frequentemente capturam tokens de sessão, tokens de redefinição, links de convite ou chaves de API. Esses logs vivem mais do que os tokens deviam e são compartilhados em tickets e chats.

Tokens também viram “dados para sempre” se você manter refresh tokens, magic links ou tokens de convite sem expiração (ou sem job de limpeza). Isso cria uma lista longa de credenciais ainda válidas.

Duplicar PII por conveniência piora tudo: replicar um email em várias tabelas, armazená-lo em eventos de analytics ou salvá-lo novamente em uma tabela de busca. Seu inventário deve marcar cada cópia para que você possa deletar e expirar dados em um único lugar.

Por último, registre decisões. Sem uma nota curta como "nunca logamos headers Authorization", um conserto rápido futuro trará o problema de volta.

Checklist rápido e próximos passos

Faça esta verificação antes de compartilhar o protótipo com mais usuários. O objetivo é encontrar cópias e garantir que dados não vivam para sempre.

Checagens rápidas que pegam a maioria dos problemas:

• Emails e nomes: busque em tabelas, colunas JSON, eventos de analytics e dumps de debug por campos como email, name, firstName, lastName, profile, invitee.
• Tokens: observe onde aparecem tokens de sessão, chaves de API e links de reset (banco, cookies, localStorage, logs do servidor, ferramentas de terceiros).
• Segredos: escaneie variáveis de ambiente, arquivos .env, output de build e páginas admin temporárias por chaves hardcoded.
• Expiração: escreva o que deve expirar (convites, resets, sessões), o tempo exato e qual job ou código faz a exclusão.
• Acesso: liste quem vê dados de produção hoje (fundadores, contratados, agência, caixa de suporte, dashboards do banco).

Quando tiver respostas, transforme em um pequeno conjunto de correções que você consegue terminar nesta semana. Mantenha entre 3 e 5 itens para que realmente aconteçam.

Se seu protótipo foi gerado por IA e já está estrangulando com usuários reais, um diagnóstico de base de código direcionado pode ajudar a encontrar onde PII, tokens e segredos estão vazando. FixMyMess (fixmymess.ai) foca em pegar protótipos gerados por IA com problemas e torná-los prontos para produção, e a auditoria de código gratuita deles é uma forma prática de obter uma lista clara de problemas antes de se comprometer com uma reescrita maior.