União Europeia detalha planos para reduzir dependência de provedores de cloud dos EUA

A Comissão Europeia não está proibindo AWS, Azure ou Google Cloud, mas está reescrevendo as regras de compra pública para que provedores europeus tenham vantagem real em cargas sensíveis. O núcleo disso é o Cloud and AI Development Act (CADA), proposto em 3 de junho de 2026, com um sistema de quatro níveis de soberania (SEAL-1 a SEAL-4) baseado em 48 critérios objetivos: localização física dos data centers, origem do hardware, controle do firmware, nacionalidade da equipe técnica e governança da empresa. O nível mais alto (SEAL-4) exige infraestrutura 100% europeia, propriedade majoritária por entidades da UE e pessoal técnico residente na UE, e só ele é elegível para sistemas de defesa, saúde pública e justiça.

O primeiro contrato operacional sob esse novo regime foi assinado em abril de 2026: até 180 milhões de euros, por seis anos, com quatro provedores europeus, OVHcloud, Scaleway, Deutsche Telekom Cloud e Orange Cloud for Business. A exigência não é 'não usar AWS', mas 'provar que sua nuvem atende ao SEAL-3 ou SEAL-4 para dados sensíveis'. E a Lei dos Dados da UE já começa a valer parcialmente em 12 de setembro de 2025, proibindo taxas de migração e bloqueios técnicos para trocar de provedor, uma alavanca direta contra o vendor lock-in.

Isso importa porque o CLOUD Act dos EUA e o GDPR da UE são incompatíveis por design: uma lei permite que o governo americano peça dados armazenados na Alemanha; outra proíbe isso. Até hoje, autoridades europeias usam nuvem americana mesmo para dados de cidadãos, sem garantia legal real de proteção. Agora, com o Cloud Sovereignty Framework em vigor desde abril de 2026, qualquer órgão público que use nuvem para processar dados de saúde ou identidade civil precisa justificar por que não escolheu um provedor com SEAL-3 ou superior. Não é ideologia, é risco jurídico concreto. E o déficit digital da UE (264 bilhões de euros/ano em pagamentos para provedores estrangeiros) mostra que há espaço fiscal e industrial para mudar, se os critérios forem aplicados com consistência.

Para desenvolvedores, isso muda o jogo em três frentes: primeiro, arquiteturas de aplicações públicas precisam ser redesenhadas para suportar portabilidade entre provedores, o que impõe uso estrito de padrões abertos (OpenAPI, OCI, CNCF) e evitar serviços proprietários como Azure Functions ou Lambda. Segundo, equipes de DevSecOps terão de validar continuamente o compliance com o SEALS, incluindo auditoria de cadeia de suprimentos (SOV-5), o critério mais pesado. Terceiro, há oportunidade real: o IPCEI-CIS já conectou Deutsche Telekom, Orange, Vodafone e TIM em um edge cloud federado, e projetos como GAIA-X Loire oferecem SDKs e ferramentas de conformidade prontas para integração. Quem constrói com esses blocos agora tem acesso antecipado a licitações públicas europeias.