Índice
- O que realmente significa soberania de dados
- Soberania de dados vs residência de dados vs localização de dados
- O panorama das ameaças legais: CLOUD Act, FISA 702 e GDPR
- Por que a jurisdição importa mais do que a localização do servidor
- Como alcançar a soberania de dados: controlos técnicos e organizacionais
- Soberania de dados para indivíduos
- Soberania de dados para organizações
- FAQ
O que realmente significa soberania de dados
A soberania de dados é enganadoramente simples de enunciar e surpreendentemente difícil de alcançar. O princípio central: os dados estão sujeitos às leis e quadros de governança da nação onde a entidade controladora está localizada. Não onde os servidores estão. Não onde os dados foram criados. Onde a organização que os controla está incorporada e opera.
Esta distinção tem enormes consequências práticas. Uma empresa dos EUA que armazena dados em servidores em Amesterdão continua a ser uma empresa dos EUA. O governo dos EUA pode obrigá-la a produzir esses dados sob a lei dos EUA — especificamente, sob o CLOUD Act, um estatuto de 2018 que explicitamente estendeu o alcance legal dos EUA aos dados mantidos no exterior por fornecedores baseados nos EUA. O centro de dados de Amesterdão é irrelevante para este cálculo.
A verdadeira soberania de dados significa que três coisas estão alinhadas:
1. Jurisdição legal. A organização que detém os seus dados está incorporada num país com fortes proteções de privacidade doméstica e sem acordos de acesso a dados extraterritoriais com a jurisdição que está a tentar evitar.
2. Controlo físico. Os servidores são operados por essa organização, não subcontratados a um fornecedor de nuvem dos EUA ou da China (AWS, Azure, Google Cloud, Alibaba Cloud) que pode ser independentemente servido com uma ordem legal.
3. Arquitetura criptográfica. A organização não pode ler os seus dados mesmo que seja ordenada a produzi-los, porque a encriptação de ponta a ponta significa que eles detêm apenas o texto cifrado, não as chaves.
A maioria das soluções de nuvem "soberanas" satisfaz uma ou duas destas condições, raramente todas as três.
Soberania de dados vs residência de dados vs localização de dados
Estes três termos são frequentemente confundidos, inclusive em contextos de aquisição empresarial. Eles são distintos:
Residência de dados refere-se à localização física do armazenamento de dados. Uma organização com uma política de residência de dados mantém os dados dos clientes da UE em servidores baseados na UE. Isto é principalmente uma postura de conformidade — satisfaz os requisitos do GDPR em torno da transferência de dados fora da UE e dá às organizações certeza contratual sobre onde os seus dados estão. Não altera qual entidade legal controla esses dados ou qual sistema legal os governa.
Localização de dados é a versão do mandato regulatório. Países como a Rússia (Lei Federal 242-FZ), China (PIPL, Lei de Segurança de Dados) e Índia (Lei DPDP 2023) exigem que certas categorias de dados sobre seus cidadãos sejam armazenadas e processadas dentro das fronteiras nacionais. Isto é o governo a impor residência de dados às empresas, em vez de as empresas a adotarem voluntariamente. Os requisitos de localização criam obrigações de conformidade para qualquer organização que lide com dados dessas jurisdições.
Soberania de dados é a camada de governança acima de ambas. Pergunta: quem controla legalmente estes dados em última instância? Qual sistema judicial pode obrigar o acesso? Qual lei de privacidade os protege? Uma empresa pode satisfazer os requisitos de residência de dados (todos os servidores na Alemanha) e ainda não ter soberania de dados se a entidade controladora for uma empresa-mãe dos EUA sujeita a ordens do FISA 702 ou do CLOUD Act.
A implicação prática para as organizações: a residência de dados é necessária, mas não suficiente para a soberania de dados. Escolher um fornecedor de nuvem sediado numa jurisdição favorável é pelo menos tão importante quanto a localização dos seus centros de dados.
O panorama das ameaças legais
Compreender a soberania de dados requer compreender os instrumentos legais específicos que a minam.
CLOUD Act (EUA, 2018). O Clarifying Lawful Overseas Use of Data Act permite que a aplicação da lei dos EUA emita mandados para dados mantidos no exterior por fornecedores baseados nos EUA, sem passar pelos procedimentos do Tratado de Assistência Jurídica Mútua (MLAT). O processo MLAT era lento e dava aos países anfitriões a oportunidade de se opor; o CLOUD Act contorna isso. Qualquer fornecedor de nuvem com sede nos EUA — AWS, Microsoft Azure, Google Cloud, Salesforce, Dropbox — pode ser obrigado a produzir dados mantidos em servidores europeus sem notificar o estado-membro da UE onde os servidores estão.
FISA Seção 702 (EUA). A Seção 702 da Lei de Vigilância de Inteligência Estrangeira autoriza a NSA a coletar comunicações de pessoas não americanas de fornecedores baseados nos EUA sem mandados individuais, sob um quadro de coleta em massa renovado até 2026. O FISA 702 opera secretamente; os fornecedores não podem divulgar pedidos específicos. Qualquer serviço que use infraestrutura baseada nos EUA para usuários não americanos cai dentro deste quadro.
Investigatory Powers Act (Reino Unido, 2016). A "Carta do Espião" exige que as empresas do Reino Unido mantenham capacidades para interceptação de dados em massa sob demanda e proíbe a divulgação de avisos de interceptação. Pós-Brexit, o Reino Unido opera seu próprio quadro de vigilância distinto (mas amplamente semelhante) ao direito da UE.
GDPR (UE, 2018). O Regulamento Geral sobre a Proteção de Dados restringe transferências de dados pessoais da UE para países sem níveis de proteção de dados "adequados". No entanto, o GDPR governa principalmente os controladores de dados (organizações) em vez de fornecer forte proteção contra o acesso governamental — não impede que os governos da UE emitam ordens de acesso a dados, e o quadro de "adequação" não resolve completamente o conflito do CLOUD Act. O Quadro de Privacidade de Dados UE-EUA de 2023 tenta abordar a decisão do tribunal Schrems II que invalidou o Privacy Shield anterior, mas sua durabilidade sob futuros desafios legais permanece incerta.
Swiss nDSG (2023). A Lei Federal de Proteção de Dados revisada da Suíça aplica a lei de privacidade suíça a qualquer organização que processe dados sobre residentes suíços, com alcance extraterritorial espelhando o GDPR. Mais relevante para fins de soberania de dados, as leis domésticas da Suíça fornecem proteções processuais contra pedidos de dados estrangeiros — os tribunais suíços podem e revisam pedidos antes da produção, e as leis de sigilo suíças impõem penalidades por divulgação prematura.
Por que a jurisdição importa mais do que a localização do servidor
O princípio é simples: a compulsão legal segue a estrutura corporativa, não a geografia do centro de dados.
Considere um exemplo concreto. A Proton AG está incorporada em Genebra, Suíça. Os seus servidores também estão na Suíça e na Islândia. Uma agência de aplicação da lei dos EUA não pode servir à Proton um mandado do CLOUD Act porque a Proton não é uma pessoa dos EUA ou um fornecedor baseado nos EUA. Deve usar canais legais suíços — MLAT com a Suíça, que envolve tribunais suíços e procuradores suíços. Os tratados MLAT da Suíça exigem que a conduta solicitada constitua um crime sob a lei suíça (dualidade criminal), o que filtra muitos pedidos dos EUA que seriam automaticamente concedidos contra um fornecedor dos EUA.
Contraste isso com uma empresa dos EUA que move os dados dos seus usuários europeus para Frankfurt. Ela satisfez os requisitos de residência de dados do GDPR. Mas a empresa-mãe em Seattle ainda pode ser servida com um mandado do CLOUD Act, e a entidade legal que controla os dados — que é a empresa-mãe dos EUA, não a subsidiária alemã — deve cumprir.
É por isso que a escolha do fornecedor de nuvem é uma decisão de soberania de dados, não apenas uma decisão de aquisição. Organizações que processam dados sensíveis — registos de saúde, dados financeiros, comunicações legais, correspondência pessoal — e querem uma verdadeira soberania de dados não podem alcançá-la usando fornecedores de nuvem sediados nos EUA, independentemente da localização do centro de dados.
Para indivíduos, a decisão equivalente é o fornecedor de email e armazenamento em nuvem. Os seus ficheiros no Google Drive, independentemente de qual centro de dados eles estão, são detidos por uma empresa dos EUA que está sujeita à lei de vigilância dos EUA e a pedidos do CLOUD Act.
Como alcançar a soberania de dados
Alcançar uma soberania de dados significativa requer operar em três camadas simultaneamente.
Camada 1: Seleção de jurisdição legal. Escolha fornecedores de serviços, plataformas de nuvem e estruturas organizacionais incorporadas em jurisdições com fortes leis de privacidade doméstica e sem partilha obrigatória de inteligência com os Five Eyes ou alianças semelhantes. Suíça, Islândia e Noruega são as opções mais fortes para organizações europeias. Dentro da UE, Alemanha e Áustria têm proteções de privacidade doméstica relativamente fortes além do GDPR.
Para organizações, isso pode significar reestruturar as entidades legais que controlam dados sensíveis — criando uma subsidiária suíça ou da UE que controla genuinamente os dados em vez de atuar como um intermediário para uma empresa-mãe dos EUA.
Camada 2: Controles criptográficos. A proteção baseada na jurisdição tem limites. Os processos legais evoluem, os governos chegam a acordos, as empresas são adquiridas. A única proteção que sobrevive à compulsão legal é a encriptação de ponta a ponta onde o fornecedor nunca detém o texto em claro.
A arquitetura de conhecimento zero significa que o operador do serviço não pode fornecer nada útil a qualquer pedido legal, exceto o texto cifrado. O Proton Mail implementa isso para emails entre usuários Proton (e opcionalmente para destinatários externos com uma senha). O Proton Drive implementa isso para todos os ficheiros armazenados. Mesmo que um tribunal ordene à Proton que produza dados, eles só podem produzir blobs encriptados.
A troca é funcional: a encriptação de conhecimento zero remove a capacidade do fornecedor de oferecer pesquisa no lado do servidor, filtragem de spam baseada em conteúdo e recursos de IA que exigem acesso ao texto em claro. As organizações que escolhem ferramentas de conhecimento zero devem aceitar essas restrições.
Camada 3: Independência da infraestrutura. Evite subcontratar a fornecedores de nuvem dos EUA para cargas de trabalho sensíveis. AWS, Azure e Google Cloud são todas empresas dos EUA com exposição direta a ordens do FISA 702 e do CLOUD Act. Uma empresa suíça que executa sua aplicação na infraestrutura AWS EU-West resolveu o problema da jurisdição legal para si mesma, mas reintroduziu-o na camada de infraestrutura.
As alternativas incluem OVHcloud (francês), Hetzner (alemão) e Infomaniak (suíço). Estes são fornecedores menores com perfis de SLA diferentes, o que é uma verdadeira troca operacional. Para cargas de trabalho sensíveis, a infraestrutura auto-hospedada em hardware próprio ou alugado oferece a garantia mais forte.
Soberania de dados para indivíduos
A implementação prática para indivíduos é mais simples do que para organizações, porque os indivíduos geralmente precisam proteger comunicações pessoais, documentos e dados de navegação em vez de fluxos de dados corporativos multi-jurisdição.
Email. Afaste-se do Gmail, Outlook e Yahoo — todas empresas dos EUA sujeitas à vigilância do CLOUD Act e do FISA 702. Proton Mail é a alternativa mais credível que respeita a privacidade: jurisdição suíça, encriptação de ponta a ponta para mensagens Proton-to-Proton (e com destinatários externos via senha), clientes de código aberto e um histórico de resistência bem-sucedida a pedidos de dados estrangeiros.
Divulgação: o link abaixo é um link de afiliado. Ganhamos uma comissão se você subscrever — sem custo adicional para você.
Mude para Proton Mail → Proton Mail (Plano gratuito disponível — jurisdição suíça, encriptação de ponta a ponta)
Armazenamento em nuvem. Google Drive, Dropbox e OneDrive são todas empresas dos EUA. O Proton Drive oferece armazenamento encriptado de ponta a ponta sob jurisdição suíça. Os ficheiros são encriptados antes do upload; a Proton não pode lê-los. Para necessidades de armazenamento maiores, o Nextcloud auto-hospedado em infraestrutura europeia é uma opção viável para usuários tecnicamente capazes.
Armazene ficheiros sob a lei suíça → Proton Drive (Armazenamento gratuito, encriptação de ponta a ponta, jurisdição suíça)
VPN e tráfego de rede. Uma VPN não resolve diretamente a soberania de dados — o conteúdo do seu email permanece sob a jurisdição do seu fornecedor independentemente de qual VPN você usa. Mas uma VPN com jurisdição suíça ou escandinava mantém os seus padrões de navegação e consultas DNS fora do alcance da vigilância dos EUA. Veja o nosso guia de privacidade do navegador para uma análise técnica do que uma VPN realmente protege.
Pesquisa e produtividade. Substituir o Google Search por alternativas que respeitam a privacidade (Brave Search, Startpage, DuckDuckGo) remove a camada de coleta de dados comportamentais. O nosso guia de alternativas ao Google cobre a migração completa serviço por serviço, incluindo pesquisa, calendário e edição de documentos.
Soberania de dados para organizações
Para organizações, a soberania de dados envolve tanto controles técnicos quanto estrutura legal. As questões são maiores:
Infraestrutura de nuvem. Onde está sediado o seu fornecedor de nuvem? Qual é a jurisdição da empresa-mãe? O CLOUD Act aplica-se a qualquer fornecedor com ligação aos EUA, independentemente de onde na estrutura corporativa o seu contrato está. Avalie OVHcloud, Hetzner, Scaleway e Infomaniak como alternativas ao AWS/Azure/GCP para cargas de trabalho sensíveis.
Ferramentas SaaS. A maioria dos SaaS empresariais funciona em infraestrutura dos EUA e é operada por empresas dos EUA. Slack, Salesforce, Zoom, Notion e GitHub estão todos sujeitos ao processo legal dos EUA. Existem alternativas europeias para muitas categorias — Element (baseado em Matrix) para mensagens seguras, Nextcloud para colaboração de documentos — mas a fricção de adoção é real.
Acordos de processamento de dados (DPAs). O GDPR exige DPAs com todos os processadores. Certifique-se de que os seus DPAs especificam não apenas a residência de dados (onde estão os servidores), mas a entidade legal que controla o processamento e a jurisdição que governa o acordo. Um DPA com uma subsidiária da UE de uma empresa dos EUA não impede que a empresa-mãe dos EUA seja servida com uma ordem do CLOUD Act.
Dados de funcionários. Na maioria das jurisdições da UE, os dados dos funcionários estão sujeitos a proteções mais fortes do que os dados dos clientes. Armazenar registos de RH numa plataforma SaaS dos EUA (Workday, SAP SuccessFactors) cria obrigações de conformidade de transferência do GDPR e riscos de soberania que muitas organizações subestimam.
Resposta a incidentes. Se você experimentar uma violação, as questões de soberania de dados tornam-se agudas. Um fornecedor de jurisdição dos EUA pode ter obrigações de resposta a incidentes que exigem que notifiquem as autoridades dos EUA antes de notificá-lo ou aos reguladores da UE, criando conflitos com os prazos de notificação de violação do GDPR. Esclareça essas obrigações contratualmente com antecedência.
O mínimo organizacional para a soberania de dados é: dados sensíveis processados apenas por fornecedores incorporados fora dos Five Eyes e sem empresas-mãe dos EUA; encriptação de ponta a ponta ou arquitetura de conhecimento zero para as categorias mais sensíveis; e revisão legal de qualquer transferência de dados transfronteiriça contra o GDPR e as leis nacionais das jurisdições envolvidas.
Para a camada técnica que complementa as escolhas de jurisdição, veja o nosso guia de modelagem de ameaças para usuários tecnicamente conscientes — ele percorre a construção de um modelo de adversário estruturado que mapeia os seus riscos reais para os controles que os abordam.
