Cloud soberana na Europa: residência não é o mesmo que jurisdição.

Esta página é a perspetiva de engenharia. Se o seu DPO, o seu auditor ou um gate de procurement estiver a perguntar o que "soberano" realmente significa em 2026, esta é a versão que resiste ao escrutínio.

Residência vs. soberania: a distinção que decide tudo

A indústria de cloud passou quinze anos a treinar os compradores para fazerem a pergunta errada. "Onde estão os dados hospedados?" é uma pergunta sobre residência. A resposta pode estar tecnicamente correta e ser legalmente irrelevante ao mesmo tempo, porque a soberania não é sobre geografia. É sobre quais tribunais podem obrigar um fornecedor a agir.

Uma região EU numa hyperscaler dos EUA, como AWS Frankfurt, Azure West Europe ou GCP Belgium, mantém os bits na UE. Isto não remove a empresa-mãe da jurisdição dos EUA. Ao abrigo do US CLOUD Act (2018), um fornecedor sediado nos EUA pode ser obrigado a divulgar dados de clientes armazenados em qualquer parte do mundo, incluindo em regiões EU. A FISA 702 impõe a mesma exposição do lado da vigilância. O European Data Protection Board já sinalizou explicitamente isto como um problema Schrems II.

"Soberano" significa, portanto, três coisas concretas, todas ao mesmo tempo:

1. A entidade legal que detém os seus dados não tem uma empresa-mãe num país terceiro com leis de divulgação de dados extraterritoriais.
2. Nenhum subprocessador no caminho dos dados está nesse país também.
3. É você, e não o fornecedor, quem controla as chaves de encriptação, ou as chaves ficam com um custodiante fora do país terceiro.

Passe os três testes e tem soberania. Falhe em apenas um e tem residência. A terminologia no seu DPA, na sua política de privacidade e nas suas páginas voltadas para o cliente deve refletir qual das duas situações se aplica de facto.

Porque é que "subsidiária na UE" não é a resposta

Uma solução comum apresentada pelas hyperscalers dos EUA é a estrutura de subsidiária na UE. Microsoft Ireland, AWS EMEA SARL, Google Cloud EMEA Ltd. O argumento é que a entidade europeia é a contraparte contratual ao abrigo do direito da UE.

Isto não resolve o problema jurisdicional. Segundo o CLOUD Act, o teste não é qual subsidiária assinou o contrato. É se a empresa-mãe tem "posse, custódia ou controlo" dos dados. Uma subsidiária na UE totalmente detida é, por definição, controlada pela empresa-mãe. A análise do TJUE e do EDPB no caso Schrems II trata a exposição da empresa-mãe como a determinante.

Por isso, quando um fornecedor oferece um plano "europeu" operado por uma subsidiária na UE de um grupo dos EUA, a pergunta certa a fazer é: "A vossa empresa-mãe nos EUA pode ser obrigada a instruir-vos a divulgar dados sem o nosso consentimento ou conhecimento?" A resposta honesta é sim.

O nível intermédio pseudo-soberano

De 2024 a 2026, vimos uma onda de parcerias "soberanas" anunciadas, tipicamente um integrador de sistemas europeu licenciando o stack tecnológico de um hyperscaler americano e operando-o sob gestão europeia. Exemplos no mercado atual:

• Ofertas soberanas licenciadas, construídas sobre tecnologia de hyperscaler americano, operadas por uma subsidiária da Telekom europeia.
• Bleu, uma cloud soberana francesa construída sobre a tecnologia Microsoft Azure, operada pela Capgemini e pela Orange.
• S3NS, uma joint venture da Thales e Google em França.

Estas ofertas podem ser úteis para regimes de conformidade específicos, mas não são o que uma equipa de engenharia deveria chamar de soberano sem qualificação. A stack tecnológica, as atualizações da plataforma, os patches de segurança e, crucialmente, o know-how operacional têm origem no parceiro dos EUA. No cenário de ameaça mais grave, em que o lado dos EUA retira a cooperação ou é obrigado a fazê-lo, o operador europeu herda uma stack que não consegue manter de forma independente.

Para a maioria dos compradores, a resposta arquitetural mais limpa é construir sobre infraestrutura onde não existe qualquer dependência dos EUA na cadeia de fornecimento. É isso que queremos dizer quando falamos de um stack soberano na Binadit.

Como é, na prática, uma stack soberana da UE

Aqui está uma arquitetura de referência concreta para uma carga de trabalho SaaS de mid-market ou regulada, a correr inteiramente sob jurisdição da UE. Nenhuma delas é exótica; todas são de nível produção.

• Compute & storage: compute gerido e hardware dedicado da Binadit, em infraestrutura UE sob jurisdição UE.
• Object storage: Ceph ou MinIO, compatível com S3, operado por nós na mesma infraestrutura.
• CDN: Bunny.net (SI), KeyCDN (CH), ou gestão própria na edge para controlo total.
• DNS: PowerDNS ou Knot, autoritativo e assinado com DNSSEC, ou Bunny DNS onde se pretenda integrado com o CDN.
• Entrega de email: Mailgun EU (com cuidado, devido à empresa-mãe americana), ou opções totalmente UE como Postmark EU, Mailpace, Tuta business, ou Postfix self-hosted na mesma infraestrutura.
• Rastreio de erros: GlitchTip ou Sentry self-hosted, ou o deployment de região UE do Sentry com os trade-offs documentados.
• Analytics: Plausible (hospedado na UE), Matomo (self-hosted ou cloud UE), Pirsch.
• Observability: Prometheus + Grafana + Loki self-hosted, ou equivalentes geridos na UE (Grafana Cloud EU, Last9 com região EU).
• Gestão de chaves: Hashicorp Vault em infraestrutura UE, ou fornecedores de KMS geridos na UE; para cenários de alta confiança, HSM on-premises com BYOK do lado da cloud.
• CI/CD: GitLab self-hosted, Forgejo, Gitea, ou a instância GitLab.com UE. Nunca o github.com por defeito para código que envolve dados pessoais sem medidas suplementares.

A questão não é que qualquer uma destas seja "a" resposta. A questão é que toda a stack pode ser montada com fornecedores sediados na UE, e um parceiro de infraestrutura gerida pode operá-la da mesma forma que um parceiro nativo AWS operaria a AWS.

O teste das quatro perguntas, em detalhe

1. Residência: onde, exatamente

Não "na UE", mas sim qual datacenter, em que país, sob que jurisdição. A UE não é um regime legal único; o GDPR está harmonizado, mas a autoridade de supervisão é local, e o mesmo se aplica ao recurso legal caso um provider falhe. Documente o código de país das localizações primária, secundária e de backup no seu DPA.

2. Subprocessadores: cada um deles

Nas nossas auditorias a ambientes de mid-market, a cadeia de subprocessadores não mapeada é o achado mais comum. A aplicação está em infraestrutura da UE, o que é bom. Mas a API de otimização de imagens que ela chama está hospedada nos EUA. O email transacional é enviado através de um ESP dos EUA. O error tracker é o padrão dos EUA. O widget de suporte ao cliente carrega JavaScript a partir de um CDN dos EUA. Cada um é um fluxo de dados separado. Cada um precisa de uma base legal se os dados atravessarem para um país terceiro.

Uma stack soberana requer uma lista completa de subprocessadores, incluindo as APIs de terceiros que a sua aplicação chama e não apenas os fornecedores de infraestrutura. A nossa está nomeada na íntegra no acordo de processamento de dados, e enviamo-la antes de assinar seja o que for.

3. Jurisdição: quem pode exigir divulgação

A questão do processo legal. Para cada entidade no percurso dos seus dados, identifique a sede da empresa-mãe. Se alguma empresa-mãe estiver nos EUA, na China, na Rússia ou noutro país com leis de acesso a dados extraterritoriais, essa entidade está exposta. O estatuto de subsidiária na UE de uma empresa-mãe dos EUA não resolve o problema.

É aqui que o diagrama de arquitetura se torna um documento legal. Desenhe-o uma vez, reveja-o trimestralmente.

4. Custódia de chaves: quem consegue tecnicamente ler os dados

Encriptação em repouso é necessária mas não suficiente. A questão é quem detém as chaves. Chaves geridas pelo fornecedor não oferecem proteção contra o fornecedor ser obrigado a decifrar. BYOK (Bring Your Own Key) ajuda a narrativa de compliance; o fornecedor continua a ter uma cópia em runtime. HYOK (Hold Your Own Key) é o único modelo em que o fornecedor cloud fisicamente não consegue ler os dados sem uma chamada ativa ao seu custodiante de chaves. Escolha o modelo que o threat model exige.

O caminho de migração: da AWS Frankfurt para uma stack soberana

O medo de sair de um hyperscaler é normalmente maior do que o projeto em si. Uma migração típica de mid-market decorre em três fases:

1. Inventário e auditoria (1-2 semanas). Mapeie todos os fluxos de dados, identifique todos os subprocessadores, classifique por exposição aos EUA. Resultado: uma lista de remediação ordenada por risco e complexidade de migração.
2. Remoções rápidas (2-4 semanas). Substitua primeiro as dependências soft: error tracking, analytics, CDN, DNS, email. Estas movem-se com pouca ou nenhuma alteração na aplicação.
3. Migração core (4-8 semanas). Compute, storage, base de dados. Use streaming replication para movimentações de base de dados sem downtime; use padrões blue-green ou DNS-failover na camada de aplicação. A parte difícil raramente é a tecnologia. É a coreografia.

Tempo total decorrido para uma equipa de engenharia de 6 a 8 pessoas, com os seus empregos diários, realizar isto: dez a dezasseis semanas. Com um parceiro de infraestrutura gerida a conduzir a migração, quatro a doze. A diferença de custo entre executar a stack soberana e o hyperscaler é, pela nossa experiência, neutra a negativa para workloads previsíveis, moderadamente superior para workloads com picos, e significativamente inferior quando o egress e a largura de banda são tidos em conta.

"A cloud soberana é mais cara?" A resposta honesta

Para 80% das cargas de trabalho de mid-market, o stack soberano é mais barato ao longo de cinco anos, principalmente porque os providers europeus não cobram taxas de egress punitivas e porque o preço de dedicated e bare-metal é dramaticamente melhor do que os tipos de instância equivalentes de hyperscaler. Os casos em que o stack soberano é mais caro são: cargas de trabalho altamente bursty que beneficiam de autoscaling sub-segundo, cargas de trabalho que dependem de um serviço managed específico (DynamoDB, BigQuery, Lambda) sem equivalente direto, e cargas de trabalho de treino de ML que exigem uma geração específica de acelerador.

Uma revisão de engenharia competente diz-lhe em uma semana em que categoria se encontra. Se quiser uma, é isso que fazemos para viver.

Vento regulatório favorável: NIS2, DORA, EHDS e AI Act

A direção regulatória entre 2025 e 2027 aponta para uma responsabilização mais estrita da cadeia de fornecimento:

• NIS2 (Artigo 21.º): as entidades essenciais e importantes devem realizar avaliações de risco da cadeia de fornecimento e transmitir contratualmente as obrigações de segurança aos subprocessadores. Um subprocessador sob jurisdição dos EUA é difícil de justificar nesta avaliação sem medidas suplementares.
• DORA (em vigor desde janeiro de 2025): as entidades financeiras devem manter um registo de fornecedores terceiros de TIC e uma estratégia de saída para fornecedores críticos. A linguagem sobre risco de concentração visa explicitamente a dependência de fornecedores dominantes não europeus.
• Espaço Europeu de Dados de Saúde (EHDS): a utilização secundária de dados de saúde está restrita a ambientes de processamento sob jurisdição UE.
• EU AI Act: os sistemas de IA de alto risco exigem proveniência rastreável dos dados de treino, o que é praticamente muito difícil numa API de modelo de fundação americano.

Nenhuma destas regulações proíbe providers dos EUA. Tornam a documentação e o esforço de medidas suplementares suficientemente elevados para que, na maioria dos casos de uso, um stack soberano seja a escolha de menor fricção.

O que não afirmamos

Para ser honesto: há cargas de trabalho em que um stack soberano na UE é mais difícil do que num hyperscaler. Multi-region active-active com latência global sub-50ms. Data warehouses analíticos managed específicos. Inferência de ML hyperscale nos aceleradores mais recentes. Diremos quando a sua carga de trabalho se encaixa nessa categoria. Para 90% do SaaS, e-commerce, plataformas B2B e cargas de trabalho reguladas que vemos, o stack soberano não é apenas compliant. É também mais rápido, mais barato e mais fácil de compreender.

Onde a Binadit se enquadra

Somos um subcontratante de dados ao abrigo do Artigo 28, sedeados em Roterdão, Países Baixos. A nossa infraestrutura assenta 100% em fornecedores sedeados na UE. A nossa lista de subprocessadores está totalmente identificada no acordo de processamento de dados e disponível mediante pedido. Não aceitamos projetos que exijam um subprocessador sob jurisdição dos EUA no percurso de dados por defeito. Quando um workload exige genuinamente um (um SaaS de terceiros em que o cliente insiste), documentamo-lo por escrito, incluímos as medidas suplementares e apresentamos o risco residual ao DPO antes da assinatura.

Se isto parece o tipo de parceiro que tem procurado, o próximo passo é uma chamada de scoping de 30 minutos.