CLOUD Act e empresas brasileiras: qual o risco real?

Em 2018, o Congresso americano aprovou o CLOUD Act para resolver um imbróglio jurídico específico: o caso United States v. Microsoft, em que o governo dos EUA queria acessar e-mails armazenados num datacenter da Microsoft na Irlanda. A Suprema Corte estava prestes a decidir se um mandado americano alcança dados fora do território americano. O Congresso respondeu antes: sim, alcança, desde que o provedor esteja sujeito à jurisdição dos EUA.

Isso é o CLOUD Act inteiro, na prática. Ele altera o Stored Communications Act de 1986 para deixar explícito que um mandado de busca americano vale sobre dados sob posse, custódia ou controle de uma empresa americana, não importa em qual país o servidor físico está. O texto não distingue infraestrutura sólida de infraestrutura frágil. Distingue apenas quem controla a empresa que guarda o dado.

Para quem constrói aplicações que rodam fora dos EUA, isso muda uma pergunta que antes parecia só técnica. Onde o servidor está deixa de ser suficiente. A menos que você adicione controles criptográficos extremos, como manter a gestão exclusiva das chaves de criptografia em um servidor físico no Brasil (External Key Management) ou criptografar tudo antes de subir para a nuvem, quem é o dono da empresa que opera o servidor entra na equação. Para não depender dessa complexidade operacional de gestão de chaves, manter a infraestrutura sob jurisdição brasileira elimina o risco na raiz.

O que o CLOUD Act autoriza, na letra da lei

O texto está codificado em 18 U.S.C. § 2713. A norma vale para qualquer “provedor de serviço de comunicação eletrônica ou serviço de computação remota” sujeito à jurisdição americana. Isso inclui empresas com sede nos EUA e qualquer empresa com operação relevante em território americano, sem exigir que a matriz esteja registrada lá.

O mandado precisa vir de um processo legal válido, normalmente um mandado de busca assinado por um juiz americano com base em causa provável, nos moldes da Quarta Emenda. Não é uma requisição administrativa qualquer. A defesa costuma usar essa distinção para argumentar que o mecanismo tem controle judicial, e tem, mas o controle é do judiciário americano, não do brasileiro.

A lei também criou o mecanismo de acordos executivos bilaterais. Um país pode negociar com os EUA um acordo que permite às próprias autoridades desse país requisitar dados diretamente de provedores americanos, sem passar pelo trâmite lento de tratado de assistência jurídica mútua (MLAT). O Brasil não tem esse acordo assinado até o momento. Na prática, isso significa que uma autoridade nacional que precisar de dados de um provedor americano ainda depende do caminho mais lento, enquanto o próprio governo americano usa o caminho direto do CLOUD Act para seus próprios mandados.

O que a AWS diz sobre isso, e o que isso não prova

A AWS publica desde 2020 um número específico: zero divulgações de conteúdo de cliente empresarial ou governamental armazenado fora dos EUA ao governo americano, via CLOUD Act, desde que começou a reportar a estatística. A empresa também afirma que a lei não dá acesso automático ou irrestrito a dados na nuvem, e que ela mantém controles técnicos e operacionais que o cliente pode configurar para dificultar acesso não autorizado.

O dado é real e vem direto da fonte, mas prova menos do que parece. Um mandado de acesso a dados pode vir acompanhado de ordens de sigilo (gag orders), o que impede o provedor de notificar a sua empresa sobre o acesso. Embora os relatórios de transparência precisem registrar estatisticamente o volume total de pedidos governamentais, “zero divulgações de conteúdo” significa apenas que os provedores conseguiram contestar ou redirecionar juridicamente os pedidos até agora. É um retrato do passado, não uma garantia estrutural para o futuro, visto que a subordinação legal à justiça americana permanece.

Isso não torna o CLOUD Act uma ameaça iminente para toda aplicação. Torna a divulgação da AWS um dado parcial, útil como piso de transparência, insuficiente como garantia.

Onde o risco do CLOUD Act é concreto, e onde é teórico?

Para a maioria das aplicações B2C ou de e-commerce local, o risco prático de um mandado individual do CLOUD Act é baixo. O mecanismo existe para investigações específicas, normalmente crimes graves: terrorismo, tráfico, crimes cibernéticos de grande escala, casos com elemento americano relevante. Uma aplicação de gestão financeira para pequenas empresas paulistas não é o alvo típico.

O risco muda de categoria em três cenários:

Dado que interessa a uma investigação americana. Se a aplicação lida com transações financeiras internacionais, comunicação de executivos, ou qualquer dado que possa aparecer numa investigação de lavagem de dinheiro, sanções ou fraude com nexo nos EUA, a superfície de exposição cresce.

Setor regulado que já exige rastreabilidade jurisdicional. Saúde, dados financeiros sob BACEN e informação classificada de governo já têm camadas de exigência que tornam a resposta “seu provedor pode ser obrigado a entregar isso a um governo estrangeiro sem que você saiba” inaceitável por si só, independentemente da probabilidade real de isso acontecer.

Cliente ou parceiro que audita a cadeia de fornecedores. Empresas que vendem para governo, para setor financeiro regulado ou para clientes corporativos com política de segurança madura cada vez mais perguntam, no processo de due diligence, sob qual jurisdição os dados do fornecedor estão. Não ter resposta clara já é um ponto perdido antes de qualquer mandado ser emitido.

Fora desses três cenários, o CLOUD Act é menos o problema em si e mais sintoma de uma pergunta maior que a arquitetura já deveria estar respondendo: sob qual jurisdição o dado do usuário está, e quem decide isso além de você?

LGPD e CLOUD Act resolvem o mesmo problema?

É comum ver os dois tratados como concorrentes diretos, e não são. O artigo 33 da LGPD regula a transferência internacional de dados: quando um dado pessoal sai do Brasil, sob qual base legal isso pode acontecer. A Resolução CD/ANPD nº 19/2024, com o período de adequação encerrado em agosto de 2025, exige que essa transferência esteja documentada por cláusulas contratuais padrão, decisão de adequação da ANPD ou consentimento específico.

O CLOUD Act é outra coisa: uma lei americana que autoriza o governo dos EUA a requisitar dados de provedores sob sua jurisdição, independentemente de o dado ter sido transferido internacionalmente de forma regular ou não. Uma empresa brasileira pode estar em conformidade plena com o artigo 33, com as cláusulas contratuais padrão da Resolução CD/ANPD nº 19/2024 assinadas e o ROPA atualizado, e ainda assim ter o dado sujeito a um mandado americano, porque a base legal para a transferência e a jurisdição do provedor são questões diferentes.

Isso derruba um raciocínio comum: “meu contrato de transferência internacional está em dia, logo estou protegido”. Protegido da LGPD, talvez. Do CLOUD Act, não. São duas exposições que se resolvem por caminhos distintos, e resolver uma não resolve a outra.

O que muda na decisão de arquitetura

Jurisdição do provedor vira critério de projeto, não só de conformidade jurídica. A pergunta não é apenas “o servidor está no Brasil”. É “o provedor tem sede jurídica e controle operacional fora dos EUA e de qualquer país com acordo executivo ativo”. Um datacenter físico em São Paulo operado por uma empresa sujeita à jurisdição americana continua exposto ao mecanismo do CLOUD Act.

Mapeamento de dado sensível por domínio de negócio ou microsserviço, não por sistema inteiro. Nem todo dado de uma aplicação carrega o mesmo peso de exposição. Separar o que é dado pessoal sensível, dado financeiro regulado ou comunicação interna de executivos do que é log operacional ou métrica agregada permite decidir a arquitetura por serviço, hospedando a aplicação completa que lida com o escopo sensível num provedor de sede nacional. Tentar dividir apenas a camada de dados de uma mesma aplicação entre nuvens diferentes gera custos de transferência (egress) e latência de rede que inviabilizam a performance.

Documentação de jurisdição como artefato de auditoria, não como resposta improvisada. Quando um cliente corporativo perguntar sob qual jurisdição o dado dele está, a resposta correta é um documento, não uma explicação verbal construída na hora. Isso vale tanto para conformidade com o artigo 33 quanto para a due diligence de segurança que parceiros maiores já cobram.

Backup e disaster recovery entram na mesma análise. Um workload em nuvem nacional pode ter uma réplica de contingência hospedada num provedor sujeito a outra jurisdição sem que ninguém tenha decidido isso conscientemente. Vale mapear onde cada camada de redundância mora, não só onde a produção roda.

Isso não substitui o trabalho já necessário de entender o que a soberania de dados exige na prática. O CLOUD Act é uma peça específica dentro dessa análise mais ampla, a que trata do acesso por autoridade estrangeira, não da localização física em si. Uma base de infraestrutura sólida resolve a segunda pergunta. Só a jurisdição do provedor resolve a primeira.

A decisão prática

Para uma aplicação com usuários majoritariamente no país, rodar no core da internet brasileira, com sede jurídica e servidor físico no Brasil, elimina a exposição ao CLOUD Act de forma estrutural, não como mitigação parcial. Não é sobre desconfiar de um provedor específico. É sobre remover uma camada inteira de jurisdição estrangeira de uma equação que já tem complexidade suficiente com LGPD, BACEN e ECA Digital.

O Locaweb Cloud roda em duas zonas de disponibilidade em território nacional, com SLA de 99,9%, cobrança em reais e suporte a Terraform para quem já trabalha com infraestrutura como código. Migrar workload de produção inteiro é decisão grande. Mapear primeiro qual camada de dado hoje depende de jurisdição estrangeira, e se essa dependência ainda faz sentido técnico ou é herança de contrato antigo, costuma ser o primeiro passo que revela mais do que parece.

FAQ – Perguntas frequentes sobre CLOUD Act e empresas brasileiras