O Cloud and AI Development Act: o que a Europa está de facto a tentar resolver

O Cloud and AI Development Act (a proposta de regulamento sobre o desenvolvimento da nuvem e da IA) é a declaração mais clara até hoje daquilo em que se tornou a política tecnológica europeia. Não é uma lei de proteção do consumidor nem uma lei de segurança. É política industrial apontada a um único problema: a Europa faz correr a maior parte da sua economia digital em infraestrutura que não controla.

É um tipo de regulação diferente do RGPD ou do Regulamento da Inteligência Artificial, e vai chegar até si por um mecanismo diferente. Perceber qual é esse mecanismo importa mais do que ler os considerandos.

O problema a que responde

Os números por trás disto não são contestados por ninguém. A esmagadora maioria da despesa europeia em infraestrutura cloud vai para fornecedores não europeus. Os maiores modelos de IA usados pelas empresas europeias são treinados e alojados fora da Europa. A capacidade de computação europeia é uma pequena fração do total mundial.

Durante uma década, isto foi visto como um resultado do mercado. Desde 2022 passou a ser visto como uma vulnerabilidade estratégica, por razões que nada têm a ver com tecnologia: tensões comerciais, controlos às exportações e a descoberta de que a dependência de infraestrutura é um instrumento de pressão.

O Cloud and AI Development Act é o braço legislativo dessa reavaliação. Junta-se ao Plano de Ação para o Continente da IA, à iniciativa InvestAI, ao programa das gigafábricas de IA e à agenda mais ampla de competitividade que saiu do relatório Draghi.

O que a proposta faz

A Comissão publicou a proposta a 3 de junho de 2026 como COM(2026) 502, juntamente com um Chips Act 2.0. É um regulamento, construído em torno de três objetivos e de um conjunto de medidas para o setor público:

Investigação e inovação. Iniciativas de Liderança em Nuvem e IA para grandes projetos intersetoriais, uma rede de Centros de Experiência e Aceleração de IA assente nos Polos Europeus de Inovação Digital, capacidade de computação atribuída a projetos prioritários de IA de fronteira e uma estratégia nacional de nuvem e IA em cada Estado-Membro no prazo de um ano a contar da entrada em vigor.

Capacidade dos centros de dados. Os Estados-Membros designam zonas de aceleração de centros de dados, com um ponto único de informação e licenciamento mais rápido, e a Comissão pode designar projetos estratégicos de centros de dados. O objetivo declarado é, pelo menos, triplicar a capacidade de centros de dados da UE até 2030, com todas as licenças para um novo centro de dados obtidas em menos de 18 meses.

Um quadro de soberania para a nuvem. Quatro níveis de garantia da União. O nível 1 é uma autoavaliação; os níveis 2 a 4 são auditados por terceiros. O nível 3 exige que o fornecedor não seja controlado a partir de um país terceiro, a menos que a Comissão tenha reconhecido que esse país oferece garantias suficientes. Os serviços reconhecidos entram num repositório central da UE.

Adoção no setor público. É aqui que a proposta tem dentes. Os compradores públicos têm de contratar serviços cloud reconhecidos, no mínimo, no nível 1. Quando uma avaliação de risco conclui que uma atividade contribui para a ordem pública (nos setores da Diretiva NIS 2, na segurança nacional, na defesa, na justiça e na aplicação da lei, entre outros), só são permitidos os níveis 2, 3 ou 4. Os Estados-Membros têm também de aplicar critérios de valor acrescentado da União quando compram nuvem e IA, uma Federação EuroCloud permite aos organismos públicos partilhar serviços cloud, e os organismos públicos têm de incentivar e facilitar o uso de código aberto em vez de software proprietário.

Pouco que vincule os compradores privados. As empresas dos setores da NIS 2 podem fazer a mesma avaliação de risco de forma voluntária, e a Comissão poderá torná-la obrigatória para setores altamente críticos através de um ato delegado. Tal como foi proposto, o regulamento aplicar-se-ia um ano após a entrada em vigor, mas ainda tem de passar pelo Parlamento e pelo Conselho.

O mecanismo que vai de facto chegar até si

Eis o que vale a pena perceber neste dossiê. A maior parte da regulação tecnológica atinge as empresas privadas diretamente: trata dados pessoais, logo o RGPD aplica-se-lhe. O Cloud and AI Development Act tem muito mais probabilidade de chegar à maioria das empresas de forma indireta, através da contratação pública.

A despesa tecnológica do setor público na UE é enorme. Se os organismos públicos dos Estados-Membros forem obrigados, ou fortemente incentivados, a comprar nuvem europeia, isso muda o mercado acessível de qualquer fornecedor que venda ao setor público, e o efeito desce em cascata pelos adjudicatários principais até aos seus fornecedores.

O padrão é conhecido da acessibilidade. O Ato Europeu da Acessibilidade tem obrigações diretas, mas na prática boa parte do trabalho de acessibilidade foi impulsionado por regras de contratação pública que excluíam fornecedores não conformes muito antes de a diretiva se aplicar.

Conte com o mesmo aqui. Se vende software a compradores públicos europeus, as perguntas sobre onde corre a sua infraestrutura, quem a controla e se pode ser migrada vão passar do questionário de segurança para os critérios de qualificação.

O que isto significa para a arquitetura

Perante uma política de soberania, o instinto é ignorá-la ou migrar em pânico. Nenhuma das duas está certa. O razoável é garantir que a pergunta tem resposta.

Saiba onde estão realmente os seus dados e a sua computação

Parece trivial e não é. Num sistema maduro, a resposta honesta a «onde é que isto corre» envolve muitas vezes uma região principal, uma região de backup, uma CDN com localizações de edge pouco claras, uma base de dados gerida, três dependências SaaS com os seus próprios subcontratantes, um fornecedor de observabilidade e uma API de IA cujo local de inferência não está documentado.

Construir um mapa rigoroso é o primeiro trabalho a sério, e é o mesmo mapa de que precisa para a análise das transferências no âmbito do RGPD e para as questões da cadeia de abastecimento da NIS 2. Faça-o uma vez.

Separe o que é portável do que não é

Quase todos os sistemas têm um núcleo portável e um conjunto de dependências específicas de um fornecedor. O núcleo portável costuma ser a aplicação. As partes não portáveis costumam ser serviços geridos: bases de dados proprietárias, runtimes serverless, filas de mensagens, identidade e, cada vez mais, APIs de modelos.

Não tem de as eliminar. Tem de saber quais são, porque essa lista é a resposta honesta sobre a dificuldade de uma migração, e é isso que um questionário de contratação pública está de facto a perguntar.

Trate os fornecedores de modelos como uma fronteira de abstração

É a mais recente e a que mais se salta. As aplicações que chamam diretamente a API de modelos de um único fornecedor, com formatos de prompt e tratamento de respostas próprios desse fornecedor espalhados pelo código, tomaram uma decisão de dependência sem dar por isso.

Uma camada de abstração fina sobre as chamadas aos modelos custa muito pouco a construir e dá-lhe a possibilidade de encaminhar para um fornecedor europeu, para um modelo de pesos abertos em infraestrutura europeia ou para outro fornecedor qualquer. Com a rapidez com que o panorama dos modelos muda, só por razões comerciais já vale a pena.

Teste a saída, não se limite a documentá-la

O Regulamento dos Dados já lhe dá o direito de mudar de fornecedor cloud, com os encargos de mudança a desaparecerem por completo a partir de 12 de janeiro de 2027. Muito poucos compradores usam esse direito, e ainda menos testam se a exportação a que têm direito permitiria de facto reconstituir o seu serviço.

Faça a exportação. Tente interpretá-la. A distância entre o que um fornecedor diz ser exportável e o que é utilizável é onde vive a dependência, e é também a resposta honesta a uma pergunta sobre soberania.

O que não é

Algum ceticismo sensato justifica-se, e mais vale ver as coisas com clareza agora do que ser surpreendido depois.

Não é uma proibição da nuvem americana. Nada na proposta proíbe as empresas privadas de usar fornecedores não europeus. O mecanismo é a preferência na contratação pública e o reforço de capacidade, não a proibição.

A capacidade não aparece porque uma lei o diz. A capacidade cloud europeia é limitada porque construir centros de dados e treinar modelos de fronteira exige muito capital, e a Europa só recentemente começou a comprometer capital à escala necessária. Os programas de financiamento tratados no nosso guia de financiamento tecnológico da UE são o verdadeiro instrumento. A lei é o enquadramento à volta deles.

Um rótulo soberano não é soberania. Há várias soluções que se apresentam como nuvem soberana mas que correm em tecnologia não europeia sob licença, com graus variáveis de independência operacional. A resposta da proposta são os níveis de garantia: o controlo a partir de um país terceiro mantém um serviço fora do nível 3 e superiores, a menos que a Comissão reconheça esse país. Onde ficará finalmente a fronteira entre os níveis 2 e 3 é o que as negociações vão decidir.

É uma proposta. Já há um texto, mas a 10 de outubro de 2026 nem o Conselho nem o Parlamento tinham posição sobre ele, e no Parlamento o dossiê continua nas comissões ITRE e IMCO. Os níveis de garantia são a parte com mais probabilidade de mudar. A direção tem sido coerente ao longo de três anos de comunicações da Comissão.

Como isto se liga a tudo o resto

O Cloud and AI Development Act é uma peça de um esforço coordenado, e lê-lo isoladamente fá-lo parecer mais fraco do que é.

O Regulamento da Inteligência Artificial regula o comportamento dos sistemas de IA. O Regulamento dos Dados ataca contratualmente a dependência da nuvem. A Diretiva NIS 2 faz descer o escrutínio da cadeia de abastecimento até aos fornecedores. O Regulamento de Ciber-Resiliência impõe obrigações de segurança aos produtos. A InvestAI e o programa das gigafábricas põem dinheiro na capacidade de computação. O Cloud and AI Development Act acrescenta a camada da contratação pública e da soberania.

Cada uma, isoladamente, parece um encargo incremental. Juntas descrevem uma aposta bastante coerente: a de que a Europa consegue, pela via da regulação, construir uma base tecnológica própria, combinando regras de acesso ao mercado com dinheiro público.

Se a aposta vai resultar é uma pergunta legítima. Que está a ser feita, não há dúvida.

O que fazer nos próximos doze meses

Construa o mapa da infraestrutura. Onde corre tudo, quem o opera, qual é o caminho contratual de saída. Este mapa tem outras quatro utilizações.

Identifique as dependências que não são mesmo portáveis e orce a migração com honestidade, mesmo que nunca a faça. É a resposta à pergunta da contratação pública e é, simplesmente, boa higiene de arquitetura.

Ponha uma camada de abstração sobre os fornecedores de modelos, se ainda não o fez. Barato agora, caro depois, e útil por razões que nada têm a ver com política.

Se vende a compradores públicos europeus, apure que nível de garantia o seu serviço poderia atingir. As regras de contratação pública da proposta são o sítio onde a exigência apareceria primeiro como critério de qualificação, e a proposta de Public Procurement Act de 9 de setembro de 2026 acrescenta por cima um quadro geral de preferência europeia.

Não migre por especulação. Mudar a infraestrutura por causa de uma proposta que ninguém negociou ainda é a forma de uma organização gastar um ano e um orçamento avultado em algo que, afinal, não era obrigatório.

Obter ajuda

Concebemos e construímos infraestrutura cloud, plataformas de dados e integrações de IA para empresas que operam na Europa, incluindo o trabalho pouco vistoso de tornar um sistema portável de verdade e não apenas no nome.

Se precisa de um mapa da infraestrutura e das dependências, de um teste de saída do seu fornecedor atual ou de uma camada de abstração sobre os fornecedores de modelos, escreva para office@c9group.dev. Saiba mais sobre o nosso trabalho de infraestrutura na página de otimização de custos da AWS e sobre o nosso trabalho europeu na página de entrada no mercado da UE.

O panorama legislativo mais amplo está no nosso calendário da legislação digital da UE, e o dinheiro por trás desta agenda está mapeado no nosso guia de financiamento tecnológico da UE.

Somos engenheiros e não consultores de políticas públicas. Isto é uma leitura de planeamento sobre uma proposta, não aconselhamento jurídico.