LGPD na sua PaaS: o que muda quando o deploy é brasileiro

A LGPD entrou em vigor em 2020 e nos anos seguintes virou hábito tratá-la como um problema do jurídico: política de privacidade, banner de cookies, DPO contratado, checkbox no formulário. Pronto, ufa.

Não é. A LGPD é, primeiro, uma decisão de arquitetura. Onde seus dados rodam, quem opera o cluster, como você responde a um pedido de exclusão, em que jurisdição está o backup do banco — todos esses pontos vivem na camada de infraestrutura. E é exatamente nessa camada que a maioria dos times brasileiros está despreparada, porque escolheu uma PaaS global sem ler o contrato com cuidado.

Esse post não é jurídico. É de engenharia. Vamos focar no que muda quando a infra é brasileira de fato — e no que continua igual, mesmo quando o app finge ser.

Por que LGPD virou problema de DevOps

A Lei Geral de Proteção de Dados (Lei 13.709/2018) trata o operador com a mesma responsabilidade do controlador. Tradução pro DevOps: a empresa que opera a infraestrutura onde seus dados rodam responde pela LGPD junto com você.

Isso significa que escolher uma PaaS não é só uma decisão de stack — é uma decisão de cadeia de responsabilidade.

Quando seu app está numa PaaS americana, três coisas acontecem por padrão:

1. Os dados atravessam a fronteira. Mesmo que o usuário esteja em São Paulo, o request normalmente é roteado pra us-east-1 ou eu-west-1.
2. O contrato é regido por lei estrangeira. Se a empresa for processada nos EUA, o juiz americano decide o que acontece com seus dados.
3. O suporte fala outro idioma. Em 2023, em vários incidentes de privacidade, o tempo de resposta foi prejudicado pelo fuso horário e pela barreira de linguagem.

Nenhum desses três pontos aparece no checklist do framework. Eles aparecem no artigo 33 da LGPD (transferência internacional) e no artigo 18 (direitos do titular).

Transferência internacional: o ponto cego

O artigo 33 da LGPD permite transferência internacional de dados pessoais, mas só em hipóteses específicas. As mais comuns são:

• País com nível adequado de proteção (a ANPD ainda não publicou a lista oficial)
• Cláusulas contratuais padrão aprovadas pela ANPD
• Consentimento específico do titular

Na prática, a maioria dos times brasileiros usando Vercel, Railway, Heroku ou Fly.io não tem nenhuma dessas três coisas formalizadas. O DPA padrão dessas empresas cobre GDPR, não LGPD. E pedir consentimento explícito por transferência internacional pra cada usuário é inviável.

O detalhe técnico que ninguém menciona: mesmo quando o provider oferece “região São Paulo”, o control plane (autenticação, billing, logs de auditoria) costuma rodar nos EUA. Então parte dos seus dados — incluindo metadados sensíveis como IPs de acesso, padrões de uso e estrutura de tenants — segue saindo do país.

Direitos do titular (Art. 18): checklist técnico

A LGPD dá ao titular nove direitos. Cinco deles têm impacto direto em engenharia:

1. Confirmação e acesso

O usuário pede: “quais dados meus vocês têm?”

Você precisa de uma rota — autenticada — que retorne tudo o que está vinculado ao usuário. Em prática:

-- Exemplo de uma export de dados de um usuário
SELECT * FROM users WHERE id = :user_id;
SELECT * FROM orders WHERE user_id = :user_id;
SELECT * FROM events WHERE user_id = :user_id;

A pegadinha: muitos times esquecem das fontes secundárias — logs de aplicação, eventos analíticos, backups. Esses também são dados pessoais.

2. Correção de dados incompletos ou inexatos

O usuário pede: “corrija meu CPF, está errado.”

Endpoint PATCH /users/me resolve. O que muitos esquecem: a propagação. Se o CPF está replicado em um CRM externo, num CDP, num backup, todas as cópias precisam ser corrigidas. Auditoria de réplicas é parte do design.

3. Anonimização, bloqueio ou eliminação

O usuário pede: “delete tudo.”

Esse é o pesado. Anonimização significa quebrar a possibilidade de reidentificação. Não basta UPDATE users SET email = 'deleted@x.com' WHERE id = :id — você precisa pensar no conjunto de dados:

4. Portabilidade dos dados

O usuário pede: “exporta tudo num formato que eu consiga importar em outro lugar.”

JSON estruturado, com schema explícito. CSV pra dados tabulares. Importante: o formato precisa ser interoperável — exportar um dump SQL proprietário não conta.

5. Eliminação dos dados tratados com consentimento

Diferente do item 3: aqui o titular revogou o consentimento e quer só os dados consentidos eliminados. Logs de auditoria que justifiquem base legal diferente (cumprimento de obrigação regulatória, por exemplo) podem ser mantidos.

A engenharia disso: base legal por campo. Se você só registra “user consented”, perde a granularidade.

Logs e PII: o vazamento mais comum

Em uma auditoria média de PaaS brasileira, logs de aplicação são a fonte mais frequente de vazamento de PII. Cenário típico:

// ERRADO — vaza CPF nos logs
app.post('/checkout', (req, res) => {
  console.log('Checkout request:', req.body)
  // req.body.cpf agora foi pra Loki, pra S3, pro Datadog...
})

Os logs vão pra um serviço de observabilidade que tipicamente:

• Roda em outra região (transferência internacional)
• Tem retenção de 30+ dias (sem TTL alinhado com a base legal)
• É acessível por toda a equipe (sem RBAC)
• Não tem masking automático de PII

Recomendação técnica simples: middleware de sanitização antes do log driver. Lista de campos sensíveis explicitamente mascarados.

const SENSITIVE = ['cpf', 'cnpj', 'rg', 'cnh', 'password', 'token', 'cardNumber']
function maskPII(obj) {
  const clone = { ...obj }
  SENSITIVE.forEach((k) => { if (clone[k]) clone[k] = '[REDACTED]' })
  return clone
}

Como a Upuai resolve por design

A Upuai Cloud nasceu com infraestrutura no Brasil — não como uma região disponível, mas como a única região. Isso muda a economia da decisão:

• Datacenters no Brasil (BH/MG), sem control plane internacional. Seus dados, metadados e logs não saem do território nacional.
• DPA LGPD-ready padrão, sem precisar pedir ao comercial.
• Operador submetido à ANPD, com jurisdição brasileira em caso de incidente.
• Suporte em português, com SLA em horário comercial brasileiro.
• BRL nativo, sem IOF nem variação cambial mensal.

A diferença prática: você não precisa adicionar uma camada de compliance por cima da PaaS. Ela já vem alinhada.

# upuai.toml — config do deploy
[build]
builder = "railpack"

[deploy]
startCommand = "node dist/server.js"
releaseCommand = "pnpm exec prisma migrate deploy"

E o deploy continua sendo git push. Compliance e ergonomia não são tradeoff.

Próximos passos

LGPD é só o começo. Em posts futuros vamos cobrir: criptografia em repouso, observabilidade com mascaramento, retenção alinhada com base legal e como modelar consentimento granular num app brasileiro.

Se sua stack está hoje em uma PaaS internacional e você quer ver como ficaria em uma infraestrutura 100% nacional, veja os planos da Upuai Cloud ou leia a doc do upuai.toml — em 5 minutos você tem um app em deploy.