LGPD para SaaS: o bug de multi-tenant que vira incidente

Startup SaaS tem uma característica que muitos founders não processam direito ao pensar em LGPD: o produto é o tratamento de dados. Não é uma empresa que usa dados como insumo. É uma empresa cuja operação principal consiste em receber, processar e armazenar dados pessoais de clientes de terceiros, em escala, no mesmo ambiente técnico. Isso coloca o SaaS numa posição jurídica específica: você é controlador dos dados dos seus próprios usuários e, ao mesmo tempo, operador dos dados que seus clientes colocam dentro da plataforma.

O problema que a gente vê com frequência: o founder passa horas formatando a política de privacidade do site e ignora que o banco de dados compartilhado sem isolamento adequado é o risco real. Uma query que vaza registro de tenant errado não é um bug de lógica de negócio. É um incidente de segurança com dado pessoal, com prazo de 72 horas para comunicação à ANPD (Resolução CD/ANPD 02/2022) e potencial de multa de até 2% do faturamento.

Multi-tenant sem isolamento: quando o bug vira infração administrativa

A maioria dos SaaS usa banco compartilhado com todos os clientes na mesma instância, separados por um campo tenant_id. A abordagem funciona, mas depende de uma premissa inegociável: nenhuma consulta pode devolver dados de tenant errado. Se uma rota da API retorna registros sem filtrar pelo tenant do usuário autenticado, você tem um vazamento de dados pessoais.

Nossa leitura: row-level security no banco de dados é uma camada de defesa eficaz, mas precisa ser aplicada de forma sistêmica. O art. 46 da LGPD exige medidas técnicas aptas a proteger dados de acesso não autorizado. "Esquecemos de filtrar por tenant nessa rota" não qualifica como medida adequada. Faça um levantamento de todas as rotas que retornam dados de usuário final e confirme onde o filtro de tenant é aplicado em cada uma.

Privacy by design: o que o art. 46 pede do seu código

Privacy by design tem consequência técnica concreta. O art. 46 exige medidas de segurança técnicas desde a concepção do sistema. Decisões de arquitetura tomadas no sprint zero têm peso jurídico. Você não pode construir o sistema inteiro e colocar privacidade como camada decorativa no final.

• Minimização de dados: se o formulário pede CPF mas o sistema não usa CPF em nenhuma funcionalidade, você está tratando dado sem finalidade. Viola o princípio da necessidade (art. 6º, III).
• Criptografia em repouso e em trânsito: TLS 1.2+ no tráfego, criptografia de campos sensíveis no banco. Não é opcional.
• Exclusão efetiva de dados: quando um cliente encerra o contrato e exerce o direito à exclusão (art. 18), você consegue deletar dados dele em todos os ambientes, incluindo backups?
• Privacidade como default: o usuário começa com compartilhamento desligado. Ele habilita. Não o contrário.

Falando sério: o maior erro em SaaS não é ausência de política de privacidade. É coleta excessiva sem finalidade definida. A ANPD pode questionar qualquer campo do seu schema e perguntar qual a base legal para aquele tratamento. Se a resposta for "a gente coleta pra analisar depois", você tem um problema.

Você é controlador. O Stripe, AWS e SendGrid são seus operadores

Founder contrata AWS, Stripe, SendGrid, Twilio e age como se a responsabilidade pelos dados tivesse migrado para esses fornecedores. Não migrou. Você continua sendo o controlador. O art. 39 da LGPD é direto: o operador processa dados conforme as instruções do controlador, e o controlador responde pelo tratamento. Terceirizar processamento não terceiriza responsabilidade.

Cada fornecedor que toca dados pessoais dos seus clientes precisa estar coberto por um DPA (Data Processing Agreement). AWS, Google Cloud e Stripe já oferecem DPAs padrão. Você precisa aceitar formalmente e guardar comprovante. Sem DPA, a transferência de dados para esses fornecedores está sem base legal documentada. E se eles armazenam dados fora do Brasil, você tem transferência internacional (art. 33 da LGPD) que precisa de cobertura contratual específica.

Due diligence de fornecedor: o que verificar antes de integrar

Cada integração nova é um novo operador de dados pessoais dos seus clientes. Antes de qualquer API key em produção, verifique:

• O fornecedor tem política de privacidade pública e atualizada? Se não tem, não integra.
• Oferece DPA? Sem DPA, você não documenta a base legal para transferir dados pessoais.
• Onde os dados são armazenados fisicamente? Brasil, Europa, EUA? Cada cenário tem implicação diferente no art. 33.
• Qual o prazo contratual de notificação de incidente? Você tem 72 horas para reportar à ANPD. Se o fornecedor demora 5 dias para te avisar de uma invasão, você já está em descumprimento antes de saber do problema.
• O fornecedor aceita ser auditado? Um questionário de segurança anual já demonstra diligência e deve ser documentado.

O registro de operações de tratamento exigido pelo art. 37 da LGPD é exatamente essa planilha: todos os fornecedores com acesso a dados pessoais, base legal da transferência, DPA assinado, localização dos dados, prazo de notificação. Esse documento vai ser o primeiro pedido numa fiscalização.

Captação de investimento e M&A: LGPD já entrou no due diligence

Fundos de venture capital e acquirers sérios já incluem LGPD na análise. A gente viu isso em operações no ecossistema do Sul. O investidor contrata revisão de contratos, políticas de privacidade, mapeamento de dados e DPAs com fornecedores. Quadro bagunçado vira desconto no valuation ou condição suspensiva. Às vezes inviabiliza o negócio se o dado tratado é sensível e a startup nunca mapeou.

A captação de leads também está no escopo. Cold email, formulários inbound e enriquecimento de dados de terceiros precisam de base legal definida para cada canal. Consentimento informado (art. 7º, I) para inbound. Legítimo interesse (art. 7º, IX) para outbound, com documentação da ponderação. Dado comprado de lista sem procedência verificável é passivo imediato que aparece no due diligence.

O que colocar em ordem nos próximos 14 dias

• Mapear as rotas da API que retornam dados pessoais e verificar o isolamento de tenant em cada uma.
• Listar todos os fornecedores com acesso a dados pessoais e confirmar se há DPA assinado. Priorizar os que armazenam fora do Brasil.
• Nomear um encarregado (DPO) formalmente, ainda que seja o próprio founder ou advogado externo (art. 41). Publicar nome e contato no site.
• Criar procedimento documentado para requisição de titular de dados. Prazo máximo: 15 dias (art. 19).
• Criar procedimento documentado para comunicação de incidente à ANPD. Prazo: 72 horas da descoberta.
• Revisar formulários de captação e garantir que o consentimento é específico, informado e registrado com timestamp.

Essas ações não encerram a adequação. Mas colocam a startup num patamar de razoabilidade que a ANPD considera na gradação de sanções. A autoridade diferencia empresa que documenta esforço real de conformidade de empresa que nunca pensou no tema. Essa diferença importa quando o incidente acontece.