Todo fundador de SaaS acha que LGPD é problema pra depois. Aí vem a due diligence de uma rodada seed, ou pior, vem o cliente enterprise perguntando "cadê o relatório de impacto e quem é o encarregado de vocês" e ninguém no time sabe responder. Nessa hora, o código já está em produção, os dados já estão misturados no banco, e corrigir custa dez vezes mais do que teria custado desenhar certo desde o início.
Trabalhamos com startups de tecnologia aqui em Blumenau e no Vale do Itajaí, região que virou polo relevante de SaaS B2B em Santa Catarina, e o padrão se repete: o produto nasce rápido, o compliance nasce nunca. Esse post é sobre o que fazer antes que vire crise.
Multi-tenant não é feature, é decisão de arquitetura sob LGPD
A arquitetura multi-tenant do seu SaaS determina, na prática, se você consegue cumprir a LGPD ou não. Não é uma camada de UI, é o desenho do banco.
Se você usa schema compartilhado com tenant_id em cada linha, cada query sem filtro de tenant é um vazamento potencial. Já vimos SaaS com row-level security mal configurado expor dado de um cliente pra outro por um bug de filtro esquecido numa API interna. Isso não é hipótese teórica, é auditoria que a gente já fez.
Privacy by design, na prática de código, significa três coisas concretas:
- Isolamento de dado por tenant garantido no nível de banco, não só na camada de aplicação (RLS no Postgres, schema separado, ou banco físico separado pra cliente enterprise que exigir)
- Minimização real: se o módulo de faturamento não precisa do CPF do usuário final do seu cliente, ele não deve nem receber esse campo na query
- Logs de acesso a dado sensível com retenção definida, não logs que ficam pra sempre "porque disco é barato"
Nossa leitura: startup que projeta isso desde o MVP gasta pouco. Startup que tenta encaixar depois de 50 mil linhas de código gasta um trimestre inteiro de engenharia só reescrevendo camada de acesso a dado.
Quem é o encarregado da sua startup? (E não, não pode ser "ninguém por enquanto")
O art. 41 da LGPD exige encarregado (DPO) pra todo controlador de dados. Startup SaaS que processa dado pessoal de usuários finais de seus clientes é controladora, às vezes operadora, dependendo do contrato. Em qualquer dos dois papéis, alguém precisa estar formalmente nomeado.
Na prática: não precisa ser um DPO full-time custando R$ 15 mil por mês num time de 8 pessoas. A Resolução CD/ANPD 02/2022 criou regime simplificado pra microempresa, EPP e startup, permitindo estrutura mais enxuta de governança. Mas simplificado não é ausente.
Falando sério: o mínimo é ter uma pessoa nomeada, canal de contato publicado (mesmo que seja um e-mail dedicado), e processo documentado pra responder titular de dado em até 15 dias, prazo do art. 19. Se seu SaaS lida com dado sensível, saúde ou biometria embutida no produto, por exemplo, esse prazo e essa estrutura pesam mais na fiscalização.
Contrato com fornecedor de infraestrutura: cloud, e-mail transacional, analytics
Toda SaaS depende de terceiro: AWS, GCP, SendGrid, Mixpanel, Stripe, Intercom. Cada um desses é operador de dado pessoal em algum grau, e cada contrato precisa prever isso.
O erro mais comum que vemos: startup assina termo de uso padrão do fornecedor internacional, em inglês, sem checar se existe cláusula de tratamento de dado compatível com a LGPD, e sem saber onde o dado fisicamente reside.
- Verifique se o contrato do fornecedor cita expressamente LGPD ou, no mínimo, GDPR com compatibilidade documentada
- Confirme onde o dado é armazenado (região do datacenter importa pra transferência internacional, art. 33)
- Exija cláusula de notificação de incidente em prazo curto, 48h é razoável, pra você conseguir cumprir seu próprio prazo de comunicação à ANPD
- Documente essa análise: se a ANPD perguntar "vocês avaliaram o fornecedor?", a resposta não pode ser "confiamos"
Isso vale em dobro pra ferramenta de IA generativa integrada no produto. Se seu SaaS manda dado do cliente pra uma API de LLM de terceiro, isso é transferência de dado pessoal pra processamento externo, e precisa estar no seu mapeamento de dados e no seu aviso de privacidade.
Due diligence de investidor vai perguntar isso, prepare antes
Fundo de venture capital sério, principalmente os que já levaram susto com portfólio anterior, inclui checklist de LGPD na due diligence. Não é boa vontade, é proteção do próprio investimento: passivo de compliance reduz valuation e pode travar rodada inteira.
Os itens que mais aparecem em due diligence de SaaS: relatório de impacto à proteção de dados (RIPD) se o produto processa dado em volume ou dado sensível, registro das operações de tratamento, contrato com operadores assinado e vigente, e evidência de que existe base legal (art. 7º) definida pra cada tipo de dado coletado, não "consentimento genérico" jogado num termo de uso que ninguém lê.
Na prática: startup que chega na Series A com essa documentação pronta economiza semanas de negociação e evita cláusula de indenização pesada no term sheet.
Segregação por cliente também é argumento comercial, não só jurídico
Cliente enterprise, banco, plano de saúde, fintech, vai perguntar como você isola o dado dele dos outros tenants antes de assinar contrato. Se sua resposta for vaga, você perde negócio, não só risco de multa.
Empresas de SaaS B2B que vendem pra setor regulado (financeiro, saúde, jurídico) já tratam certificação de segurança e clareza de arquitetura multi-tenant como parte do pitch de vendas. É um diferencial competitivo, não um custo de compliance escondido.
O que fazer nas próximas duas semanas
Não precisa resolver tudo de uma vez, mas precisa sair do zero:
- Mapeie que dado pessoal seu SaaS coleta, de quem, e com que base legal do art. 7º isso se sustenta
- Nomeie formalmente um encarregado, mesmo que acumulando função, e publique o canal de contato
- Liste todos os fornecedores terceiros que tocam dado pessoal e confira se o contrato com cada um cobre isso
- Rode um teste simples: peça pra um dev tentar acessar dado de um tenant a partir da sessão de outro tenant. Se conseguir, você tem prioridade zero antes de qualquer outra coisa nesta lista
Isso não elimina risco, mas transforma "não sabemos" em "sabemos e estamos corrigindo", que é exatamente a diferença que pesa numa fiscalização da ANPD ou numa negociação de investimento.
Fale com um advogado da RSA.
Diagnóstico objetivo em até 24h úteis.
