O Data Act e o “cloud switching”: chaves de um novo regime de mudança de prestador de serviços de computação em nuvem

O Data Act (Regulamento (UE) 2023/2854) estabelece um novo quadro para facilitar a mudança de prestador de serviços de computação em nuvem, conhecido como cloud switching. Este conjunto de obrigações, previstas sobretudo nos artigos 23.º a 31.º (Capítulo VI), procura eliminar as barreiras técnicas e contratuais que dificultam a portabilidade de dados e serviços entre diferentes prestadores de serviços. O Regulamento entrou em vigor em 11 de janeiro de 2024 e é aplicável a partir de 12 de setembro de 2025. Os prestadores de serviços serão obrigados a adaptar progressivamente os seus contratos e procedimentos internos para se alinharem com o novo quadro de portabilidade previsto no Data Act. Neste contexto, analisamos as principais características deste regime, os seus potenciais riscos e as suas implicações para as empresas.

O que é o ‘cloud switching’ segundo o Data Act?

O Data Act concebe o cloud switching como a possibilidade de um cliente de serviços de tratamento de dados mudar de um prestador de serviços para outro com o mínimo de atrito. Isto abrange a migração de um serviço de computação em nuvem para outro equivalente oferecido por um prestador de serviços diferente, ou o regresso de dados e aplicações a uma infraestrutura local (on-premise) da própria empresa. Além disso, contempla cenários que envolvem a utilização simultânea de vários prestadores de serviços (multicloud), impondo aos prestadores de serviços a obrigação de não impedirem os seus clientes de distribuir os seus serviços por diversas nuvens ao mesmo tempo.

Para o efeito, o Capítulo VI estabelece que os prestadores de serviços “não podem impor, e devem eliminar, os obstáculos pré-comerciais, comerciais, técnicos, contratuais e organizativos” que impeçam os clientes de mudar de serviço, migrar para a sua própria infraestrutura TIC ou a utilizar vários prestadores de serviços em paralelo (artigo 23.º). O objetivo operacional é que a transferência seja "segura e atempada", em formatos normalmente utilizados e através de "interfaces abertas", mantendo a "continuidade do serviço" durante o processo de troca (Cons. 97). O objetivo estratégico é evitar o vendor lock-in.

Obrigações para os prestadores de serviços de computação em nuvem

O novo regime impõe obrigações técnicas, contratuais e organizacionais para facilitar a portabilidade e a interoperabilidade entre serviços. Em termos gerais, estas são as implicações práticas mais relevantes:

1. Obrigações contratuais

O Data Act prevê que os contratos estabeleçam expressamente o direito de o cliente mudar de prestador de serviços, detalhando um procedimento de migração claro. Deve ser estabelecido um período de transição até 30 dias, durante o qual o prestador cessante continuará a prestar o serviço enquanto apoia o cliente na migração. Durante este período, o prestador de serviços manterá a continuidade do serviço com a devida diligência, prestará assistência técnica razoável ao cliente e, quando apropriado, ao novo prestador, informará sobre quaisquer riscos de continuidade e garantirá elevados níveis de segurança durante a transferência. Além disso, os contratos devem incluir a colaboração na estratégia de saída (exit strategy) do cliente, fornecendo as informações necessárias para o planear a migração.

Outros aspetos contratuais relevantes incluem: um prazo máximo de pré-aviso para o cliente iniciar o processo de mudança (não superior a dois meses); a especificação de que dados e ativos digitais do cliente podem ser exportados (pelo menos todos os dados de entrada e saída gerados pela utilização do serviço) e quais são excluídos por serem internos do prestador de serviços (por exemplo, segredos comerciais, desde que a migração não seja prejudicada); uma janela mínima de recuperação de 30 dias após a cessação do serviço, durante a qual o cliente pode continuar a recuperar os seus dados; e a garantia de eliminação completa dos dados do cliente após a conclusão do processo. Além disso, uma vez concluída a mudança com êxito ou terminado o prazo de pré-aviso (caso o cliente opte por não migrar os seus dados), considerar-se-á que o contrato foi resolvido nos termos legais.

Interação com o Regulamento de IA

A interação com o Regulamento de IA (Regulamento (UE) 2024/1689, doravante, “RIA”) assume uma relevância especial quanto à obrigação de apagamento de dados. Nos projetos que envolvam sistemas de IA de alto risco na nuvem, o switching abrange dois âmbitos: o Data Act exige o apagamento de dados e ativos do cliente ao encerrar o processo, após a janela de recuperação (artigo 25.º, n.º 2, alínea h); o RIA impõe o registo automático dos eventos e a conservação dos logs e da documentação, com o dever de cooperação com as autoridades (artigos 12.º, 16.º, 18.º, 21.º e 26.º). A questão prática numa migração é o que é exportado e apagado, o que é retido, por quem e durante quanto tempo. Além disso, uma mudança de plataforma que modifique elementos técnicos essenciais pode ser considerada uma "modificação substancial" e exigir uma nova avaliação de conformidade (artigo 43.º, n.º 4 do RIA).

Por exemplo, se uma instituição financeira migrar um SaaS de avaliação de solvência para outro prestador de serviços, o Data Act prevê a resolução, regula a exportação e exige o apagamento de dados exportáveis e ativos digitais com o encerramento. Por sua vez, o RIA exige a manutenção dos logs do sistema durante um período mínimo enquanto estiverem sob o controlo do prestador e o seu fornecimento às autoridades, se tal lhe for pedido (artigos 12.º e 21.º). Neste caso, é necessário identificar que registos estão sujeitos a conservação, determinar quem os guarda e verificar se a alteração afeta a conformidade.

2. Obrigações técnicas e de interoperabilidade

Os prestadores de serviços devem facilitar a portabilidade dos dados e a interoperabilidade dos seus serviços para que os clientes possam operar os seus dados e aplicações no serviço de destino com o menor esforço possível. Isto implica o fornecimento de interfaces abertas (APIs) e formatos padrão para a exportação de dados, acessíveis em igualdade de circunstâncias por todos os clientes e prestadores de serviços de destino, e sem custos adicionais. As informações técnicas necessárias (por exemplo, estruturas de dados, formatos, metadados, etc.) devem ser disponibilizadas num registo online atualizado para que terceiros possam desenvolver ferramentas de conversão ou migração compatíveis.

As obrigações dependem do tipo de serviço: tratando-se de infraestrutura como serviço (IaaS) ou recursos básicos de computação, o prestador de serviços de origem deve tomar medidas razoáveis para facilitar ao cliente a obtenção de equivalência funcional no serviço de destino, sempre dentro dos limites do que é tecnicamente viável e sem comprometer a segurança ou a integridade dos seus sistemas. Isto significa que, ao mudar para outra infraestrutura equivalente, as aplicações do cliente irão funcionar de forma comparável, obtendo resultados materialmente semelhantes para as mesmas entradas, sempre para funcionalidades comuns. O Regulamento esclarece que o prestador de serviços cessante não é obrigado a recriar todo o seu serviço na infraestrutura do concorrente, mas é obrigado a fornecer os recursos, a documentação, a assistência técnica e as ferramentas necessárias para que a transição seja eficaz (Cons. 92). Um exemplo é a utilização de ferramentas de conversão de máquinas virtuais ou contentores para deslocar cargas de trabalho para outro ambiente. Nos serviços de plataforma (PaaS) ou de software (SaaS), a prioridade é a abertura de interfaces e a normalização para migrar dados entre diferentes aplicações.

Os pormenores da normalização estão estabelecidos no artigo 35.º. Em síntese: o Capítulo VI estabelece o "quê" e o artigo 35.º, o "como". Quando a Comissão publicar, no repositório central, uma norma harmonizada ou uma especificação comum aplicável, o prestador terá doze meses para garantir a compatibilidade; tudo isto sem exigir o desenvolvimento de novas tecnologias, a divulgação de ativos protegidos (por exemplo, o seu código-fonte ou algoritmos) ou o comprometimento da segurança ou integridade dos seus sistemas como condição para a migração.

De acordo com a versão mais recente das Perguntas Frequentes da Comissão (12 de setembro), a pergunta 57 indica que o repositório assumirá a forma de uma plataforma online, com balcão único para cada tipo de serviço. Como primeiro passo, em setembro de 2025, a Comissão concluiu um mapeamento das normas harmonizadas e das especificações abertas elegíveis para o seu reconhecimento e, antes de publicar uma referência, consultará as partes interessadas e adotará um ato de execução. A primeira versão do repositório será publicada em europa.eu e será progressivamente expandida por tipo de serviço.. Por enquanto, e na ausência de normas aplicáveis, os clientes devem, pelo menos, poder exportar todos os seus dados num formato estruturado, de uso corrente e de leitura automática, se assim o pedirem. Recorde-se que ainda não existe uma taxonomia fechada do "mesmo tipo de serviço", o que condiciona quando é possível exigir equivalência funcional ou compatibilidade.

3. Dever de cooperação e boa-fé

O processo de cloud switching envolve o cliente, o prestador de serviços cessante e, quando aplicável, o novo prestador de serviços. O Data Act impõe a todos o dever geral de cooperação de boa-fé para garantir que a migração é eficaz, rápida e segura. Isto inclui a cooperação técnica do prestador de serviços de destino com o cliente (e, se necessário, com o prestador de serviços original) para garantir a continuidade do serviço no novo ambiente. O objetivo é impedir que qualquer parte — por ação ou omissão — dificulte a mudança. Esta obrigação complementa as medidas específicas impostas ao prestador de serviços cessante e reforça a ideia de que a migração deve ser um esforço conjunto em benefício do cliente.

4. Transparência sobre localização de dados e acesso governamenta

No âmbito do Capítulo VI, os prestadores de serviços devem ainda informar publicamente quanto à jurisdição onde se encontra a sua infraestrutura e as medidas que adotam para impedir o acesso governamental extrajudicial a dados não pessoais na UE. Esta obrigação (artigo 28.º, n.º 1, alíneas a) e b)) pretende dar aos clientes confiança quanto à localização dos seus dados e à forma como estes são protegidos contra ordens de países terceiros que possam entrar em conflito com o Direito da União ou com o Direito nacional correspondente. Estas informações devem estar disponíveis no site do prestador de serviços e referenciadas nos contratos (artigo 28.º, n.º 2). Embora isto não afete diretamente a portabilidade, faz parte do quadro de confiança na computação em nuvem estabelecido pelo Data Act, complementando o direito a mudar de prestador de serviços com garantias em matéria de soberania dos dados.

5. A cláusula sobre custos de mudança: “charges… strictly limited to the costs incurred”

Um aspeto fundamental da portabilidade diz respeito aos custos que um prestador de serviços pode cobrar a um cliente que pretenda mudar de serviço. Historicamente, muitos prestadores de serviços impunham tarifas elevadas para a extracção de dados (taxas de saída de dados, egress) ou outros encargos ao terminar antecipadamente um contrato, o que tinha um forte efeito dissuasor. O Data Act aborda este problema com uma supressão gradual dos encargos decorrentes da mudança (artigo 29.º).

Em termos práticos, a cobrança ao cliente pelo processo de mudança será proibida a partir de 12 de janeiro de 2027. Até lá, apenas poderão ser cobrados "encargos decorrentes da mudança reduzidos", que não podem exceder os custos incorridos pelo prestador de serviços de tratamento de dados diretamente relacionados com o processo de mudança em causa ("charges imposed by the provider strictly limited to the costs incurred" (artigo 29.º, n.º 3). Isto inclui despesas objetivamente imputáveis à migração (por exemplo, largura de banda para transferência de dados, tempo de assistência técnica, utilização de ferramentas específicas de exportação), mas exclui margens de lucro e custos não relacionados (por exemplo, custos gerais da infraestrutura ou penalizações).

O considerando 89 alerta que determinados custos não podem ser repercutidos sobre o cliente, como os decorrentes da subcontratação escolhido pelo prestador de serviços. Apenas se o cliente solicitar serviços adicionais para além do exigido pela norma (por exemplo, assistência extraordinária ou personalizada), poderá ser cobrado esse serviço extra, mediante acordo prévio sobre o preço. Em última análise, a regra sobre custos do artigo 29.º pretende que, durante o período transitório, o cliente pague, no máximo, o custo real da transferência dos seus dados. E, a partir de 2027, a mudança deverá ser gratuita para o cliente, com o prestador de serviços a assumir quaisquer custos internos envolvidos. Resta saber como serão verificados os custos cobrados até 2027, em conformidade com esta limitação, o que poderá exigir transparência contabilística. A Comissão, ciente desta situação, tem poderes de acompanhamento durante o período de transição (artigo 49.º, n.º 1, alínea i)).

6. Microempresas e PME: isentas do ‘cloud switching’?

O Data Act introduz no artigo 7.º uma isenção para as microempresas e pequenas empresas de determinadas obrigações. Mais concretamente, as disposições do Capítulo II não se aplicarão aos dados gerados por produtos ou serviços de uma micro ou pequena empresa, desde que não faça parte de um grupo empresarial maior nem atue ao abrigo da subcontratação por outra empresa. Esta isenção foi incluída para evitar sobrecarregar os pequenos fabricantes de dispositivos ou prestadores de serviços com obrigações de partilha de dados do âmbito IoT. No entanto, esta isenção estende-se às obrigações de cloud switching do Capítulo VI?

A resposta, de acordo com a letra da norma, é não. A exceção do artigo 7.º limita-se ao Capítulo II e não menciona qualquer isenção para as regras de mudança de prestador de serviços de computação em nuvem. Por conseguinte, mesmo as micro e pequenas empresas que ofereçam serviços de tratamento de dados na nuvem estarão sujeitas ao regime de cloud switching. Isto pode colocar desafios para estes intervenientes, pois a implementação de normas de interoperabilidade, ferramentas de exportação de dados ou suportar o custo de migrações gratuitas podem exigir um esforço proporcionalmente maior.

O legislador está ciente deste potencial impacto: o artigo 49..º, n.º 2 determina que a Comissão avalie, até 12 de setembro de 2028, os efeitos das obrigações de mudança de cloud switching (artigos 23.º a 31.º) no mercado, com especial atenção às PME prestadoras de serviços. Recorde-se ainda que o artigo 31.º prevê um regime específico para determinados serviços de tratamento de dados, como o software desenvolvido especificamente para um único cliente (soluções altamente personalizadas não oferecidas em escala) ou versões de teste não produtivas, a que não se aplicam algumas obrigações de mudança. Esta é uma exceção devido à natureza do serviço, e não à dimensão da empresa.

Em conclusão, o regime de cloud switching do Regulamento de Proteção de Dados marca um ponto de viragem na relação entre os clientes e os prestadores de serviços de computação em nuvem. A partir de setembro de 2025, a mudança de prestador de serviços será facilitada com o estabelecimento de um direito com etapas, prazos e limites mais claros. As empresas utilizadoras conquistarão a liberdade de escolher a solução que melhor lhes convém em cada momento, o que, como consequência lógica, conduz a uma maior competitividade na qualidade dos serviços. O cenário é de um mercado mais aberto e dinâmico, onde a capacidade de switching e a interoperabilidade serão fatores centrais para a inovação e a concorrência. Como qualquer transformação, trará desafios de adaptação, mas também oportunidades para quem souber antecipar-se.

'Checklist': Principais etapas para o novo regime de ‘cloud switching’

Para prestadores de serviços de computação em nuvem:

• Atualizar contratos e modelos: integrar o pré-aviso, a transição, recuperação, resolução e apagamento; eliminar práticas que constituam obstáculos; política de custos baseada nos "custos incorridos" até 2027 e zero após isso.
• Ativar ferramentas: exportação em formatos estruturados e de uso corrente, APIs abertas e informações técnicas no registo online; em IaaS, medidas para equivalência funcional; em PaaS/SaaS, foco nas interfaces abertas.
• Operação de switching: playbook interno com responsáveis, SLA para o período de transição, apoio razoável ao cliente e, quando apropriado, ao novo prestador; segurança durante a transferência e apagamento seguro com o encerramento.
• Identificar e ajustar políticas técnicas e contratuais que possam ser consideradas obstáculos à mudança, como limitações de desempenho (throttling), exclusividade ou penalizações, adaptando-as gradualmente ao novo quadro de portabilidade; reduzir os custos de mudança até 2027 e eliminá-los após essa data; permitir a utilização paralela de acordo com o regime legal.
• Governação e normas: manter a secção pública de transparência; monitorizar o repositório do artigo 35.º e ativar o período de compatibilidade de 12 meses quando as referências forem publicadas.

Para clientes (utilizadores empresariais):

• Rever os contratos em vigor: pré-aviso de mudança (≤ 2 meses), período de transição (30 dias), recuperação (≥ 30 dias), resolução e apagamento; eliminar penalizações e obstáculos incompatíveis.
• Elaborar um plano de saída: inventário de dados e ativos exportáveis, dependências técnicas, formatos e APIs disponíveis, prazos e responsabilidades internas.
• Utilizar a transparência do prestador de serviços: consultar os procedimentos de switching, os formatos suportados, as limitações e as jurisdições publicadas.
• Avaliar alternativas e multicloud: comparar as propostas e os custos, incluindo a regra de custos até 2027 e o egress pelo custo em utilização em paralelo.
• Exercer direitos: documentar avisos e pedidos; se existirem obstáculos ou atrasos, encaminhar através dos canais estabelecidos.
• Se existir IA de risco elevado: identifique os logs sujeitos a conservação e as funções de custódia antes de exportar ou apagar.