Dados pessoais na réplica (LGPD) — a definir¶
Status: Rascunho · Responsável: Gustavo Madruga · Atualizado em: 2026-08-11
Status: rascunho / placeholder. Este documento marca uma pendência de política, não uma decisão tomada. O conteúdo abaixo lista o que precisa ser definido — preenchimento é do dono do produto / jurídico, não derivável do código.
Fato (confirmado no código)¶
O integrador mantém uma réplica do banco do X-Adm na nuvem (banco por cliente, que o hub
possui). Notas e pedidos carregam CPF/CNPJ — e o fluxo de entrada PIED usa o documento
(CNPJ/CPF, só-dígitos) como chave natural (int-pied, PiedClienteRepository). Ou seja:
dado pessoal trafega e repousa na cópia em nuvem, por desenho (a integração é espelho do ERP,
decisão D0).
A definir (política — não é decisão de engenharia)¶
- Base legal: é do cliente (controlador). Registrar qual, por cliente.
- Retenção: por quanto tempo a réplica guarda dado pessoal; política de expurgo/anonimização.
- Acesso: quem pode acessar as consoles (views server-render) que expõem esses dados —
hoje o gate é login Google
@xadm.com.br+ SSO nas portas (ver Segurança). - Logs: o que dos dados pessoais aparece em log/observabilidade (Sentry/GlitchTip) e por
quanto tempo — hoje
send-default-pii: truenoapplication.yml(revisar). - Papéis: controlador (cliente) × operador (nós). Retenção, acesso e logs são responsabilidade nossa como operador.
Onde isso deveria morar¶
Quando a arquitetura-alvo estabilizar, um parágrafo de LGPD entra na spec do hub (repo central). Este stub existe só para a pendência não sumir. Ver a seção "Ainda abertas" em arquitetura-alvo.