Seu servidor está nos EUA e você nem sabia: o que a LGPD exige agora

Um cliente da região de Blumenau nos procurou porque o contador dele viu, numa auditoria de fornecedores, que o sistema de folha de pagamento roda num data center em Virginia, nos EUA. Ninguém tinha percebido. O contrato com o fornecedor de software foi assinado três anos atrás, ninguém leu a cláusula de localização de dados, e a empresa vinha mandando CPF, PIS e dado de saúde de funcionário pra fora do país todo mês, sem nenhum mecanismo formal de proteção.

Isso não é exceção, é regra. Se sua empresa usa AWS, Google Workspace, Azure, Salesforce, HubSpot ou qualquer SaaS americano, ela provavelmente já transfere dado pessoal pra fora do Brasil. A pergunta não é "eu transfiro dado internacional?". É "eu tenho o mecanismo legal que a LGPD exige pra isso?". Na maioria dos casos que vemos, a resposta é não.

O que a LGPD chama de transferência internacional (art. 33)

A lei não define transferência internacional como algo excepcional. Qualquer envio, armazenamento, processamento ou acesso a dado pessoal por servidor, empresa ou pessoa fora do território brasileiro entra na regra. Não importa se o dado "só passa" por lá pra backup, ou se o servidor principal é no Brasil e só a réplica fica nos EUA. Se o dado sai, é transferência.

O art. 33 lista dez hipóteses que autorizam essa transferência. As mais usadas na prática empresarial são:

• País ou organização com nível de proteção adequado (inciso I)
• Cláusulas-padrão contratuais, cláusulas contratuais específicas ou normas corporativas globais aprovadas pela ANPD (inciso II)
• Cumprimento de obrigação legal do controlador (inciso VI)
• Execução de contrato ou procedimento preliminar solicitado pelo titular (inciso VII)
• Consentimento específico e destacado do titular pra aquela transferência (inciso IX)

Na prática: a maioria das empresas que contrata SaaS americano se enquadra no inciso II, via cláusula contratual, ou no inciso VII, porque o serviço só funciona transferindo o dado. O problema é que isso precisa estar escrito e formalizado, não presumido.

Cláusula-padrão da ANPD: o que mudou de verdade

Em agosto de 2024 a ANPD publicou a Resolução CD/ANPD nº 19, que aprovou o modelo brasileiro de cláusulas-padrão contratuais para transferência internacional, inspirado nas Standard Contractual Clauses do GDPR europeu. Isso deu um caminho prático que antes não existia formalmente: em vez de negociar cláusula própria, a empresa incorpora o modelo pronto da ANPD no contrato com o fornecedor estrangeiro.

Falando sério: isso é bom pra empresa pequena, porque negociar cláusula específica com a AWS ou o Google, um a um, é inviável pra quem fatura R$ 2 milhões por ano. O modelo pronto resolve isso. Mas ele só vale se estiver de fato anexado ao contrato ou ao termo de uso do fornecedor, com aceite registrado. Não basta o fornecedor "dizer que segue LGPD" no site institucional.

Decisão de adequação: por que "país seguro" ainda não existe na prática

O art. 34 da LGPD prevê que a ANPD pode declarar que um país tem nível de proteção adequado, avaliando legislação local, direitos garantidos ao titular, existência de autoridade supervisora independente e compromissos internacionais assumidos. É o mesmo raciocínio do GDPR europeu, que já reconheceu formalmente países como Japão, Reino Unido, Coreia do Sul e Argentina como "adequados".

A ANPD, até onde acompanhamos, ainda não publicou uma lista própria de países com decisão de adequação. Isso significa que, na prática, nenhuma empresa brasileira pode simplesmente alegar "os EUA são um país seguro" e dispensar mecanismo contratual. Enquanto essa lista não existir, o caminho seguro continua sendo cláusula-padrão, cláusula específica ou consentimento, não presunção de adequação.

GDPR e LGPD ao mesmo tempo: quando cai nas duas leis

Vale do Itajaí exporta têxtil, móveis e software pra Europa. Se sua empresa vende produto ou serviço pra consumidor final na União Europeia, mesmo sem escritório lá, o GDPR pode se aplicar por extraterritorialidade, junto com a LGPD. São regimes parecidos, mas não idênticos: o GDPR tem multa de até 4% do faturamento global (não só nacional), e exige nomeação de representante na UE em certos casos.

Nossa leitura: empresa que só vende B2B pro mercado interno raramente precisa se preocupar com o GDPR. Empresa de e-commerce, SaaS ou marketplace que atende consumidor europeu direto, sim. Vale checar isso antes de simplesmente copiar a política de privacidade de um concorrente americano ou europeu, porque as bases legais não se equivalem ponto a ponto.

Onde configurar o servidor pra evitar o problema (quando dá)

Boa parte da dor de cabeça desaparece configurando a região certa no provedor de nuvem. Os três grandes já operam data center no Brasil:

• AWS: região sa-east-1, em São Paulo
• Google Cloud: região southamerica-east1, também em São Paulo
• Azure: região Brazil South

Manter o dado nessas regiões elimina a transferência internacional na maior parte dos fluxos, sobra só o que já é estruturalmente global, como e-mail transacional, CDN ou ferramenta de suporte americana. É gratuito verificar isso, leva menos de uma hora de trabalho de TI, e reduz o risco de forma real, não cosmética.

O que fazer nas próximas duas semanas

• Levantar todos os fornecedores de nuvem, SaaS e e-mail que a empresa usa e identificar em qual país cada um armazena dado
• Verificar se o contrato de cada fornecedor estrangeiro tem cláusula de transferência internacional (SCCs, cláusula ANPD ou cláusula própria)
• Onde não houver cláusula, contatar o fornecedor e pedir o addendum de proteção de dados (a maioria dos grandes players já tem modelo pronto pra assinar)
• Checar, junto ao encarregado (art. 41), se algum desses fluxos envolve dado sensível (saúde, biometria) e priorizar esses primeiro
• Se a empresa vende pra consumidor europeu, avaliar separadamente a exposição ao GDPR

O erro mais comum que vemos não é falta de intenção, é achar que "estar na nuvem" já resolve tudo por padrão. Não resolve. A responsabilidade pela base legal da transferência é do controlador, não do fornecedor de tecnologia.