Porque é que o alojamento na UE importa para equipas de SaaS e IA: RGPD, Schrems II e CLOUD Act

O RGPD aplica-se quando trata dados pessoais no contexto das atividades de um estabelecimento na UE (artigo 3.º, n.º 1) e, se não tiver um estabelecimento na UE, ao tratamento de dados pessoais de pessoas que se encontram na UE se o tratamento estiver relacionado com a oferta de bens ou serviços a essas pessoas ou com o controlo do seu comportamento na UE (artigo 3.º, n.º 2). O local onde esses dados são alojados e a empresa que os aloja determinam em que medida estão em causa transferências internacionais e o acesso por autoridades estrangeiras. O RGPD restringe as transferências de dados pessoais para fora do EEE, a lei dos EUA pode obrigar fornecedores norte-americanos de cloud e de comunicações a entregar dados que guardam no estrangeiro, e os prompts de IA estão muitas vezes cheios de dados pessoais.

Este artigo explica as regras de forma simples e termina com uma lista de verificação para escolher um fornecedor. Não constitui aconselhamento jurídico: para o seu caso concreto, consulte o seu encarregado da proteção de dados ou um advogado.

A regra do RGPD para transferências

O capítulo V do RGPD (artigos 44.º a 50.º) trata das «transferências de dados pessoais para países terceiros ou organizações internacionais». Um país terceiro é qualquer país fora da UE e do Espaço Económico Europeu. O artigo 44.º estabelece o princípio: os dados pessoais só podem sair se as condições desse capítulo forem cumpridas. Há três vias principais:

• Decisão de adequação (artigo 45.º): a Comissão Europeia decide que um país protege os dados pessoais a um nível essencialmente equivalente ao da UE. Os dados podem então ser transferidos para esse país sem outras garantias.
• Garantias adequadas (artigo 46.º): por exemplo, as cláusulas contratuais-tipo que a Comissão adotou na Decisão de Execução (UE) 2021/914, ou regras vinculativas aplicáveis às empresas dentro de um grupo empresarial (artigo 47.º).
• Derrogações (artigo 49.º): exceções estritas para situações específicas, não uma base para alojamento corrente.

A violação destas regras enquadra-se no escalão mais elevado de coimas do RGPD: até 20 milhões de euros ou 4% do volume de negócios anual a nível mundial, consoante o montante que for mais elevado (artigo 83.º, n.º 5).

Schrems II: porque é que um contrato não bastava

Em 16 de julho de 2020, o Tribunal de Justiça da UE decidiu o processo C-311/18, conhecido como Schrems II. Declarou inválido o Privacy Shield UE-EUA, que era então a decisão de adequação para os Estados Unidos. O Tribunal concluiu que os programas de vigilância norte-americanos não se limitavam ao estritamente necessário e que as pessoas cujos dados eram transferidos não tinham forma de recorrer a um órgão independente com garantias equivalentes às do direito da UE.

As cláusulas contratuais-tipo mantiveram-se, mas com uma condição. A proteção tem de ser essencialmente equivalente à da UE, e a avaliação tem de ter em conta os elementos relevantes do sistema jurídico do país de destino, em particular o acesso por parte das autoridades públicas. O exportador e o destinatário têm de verificar isto antes da transferência. Se as cláusulas não puderem ser cumpridas, a transferência tem de ser suspensa ou terminada.

Para as equipas, assinar um contrato passou a exigir trabalho prévio: antes de confiar nas cláusulas, é preciso analisar a lei do país para onde vão os seus dados.

O EU-US Data Privacy Framework

Em 10 de julho de 2023, a Comissão adotou a Decisão de Execução (UE) 2023/1795, uma nova decisão de adequação para o EU-US Data Privacy Framework (DPF, Quadro de Privacidade de Dados UE-EUA). Os dados pessoais podem ser transferidos sem garantias adicionais para as empresas norte-americanas que participam no quadro. As empresas aderem comprometendo-se com um conjunto de obrigações de privacidade; o Departamento do Comércio dos EUA administra o quadro, e a Federal Trade Commission ou o Departamento dos Transportes, consoante a organização, faz cumprir os compromissos. Do lado governamental, o quadro limita o acesso dos serviços de informações norte-americanos ao que é necessário e proporcional e criou um Data Protection Review Court para queixas de pessoas da UE.

Dois pontos a ter em conta:

• Só abrange as empresas participantes. Um fornecedor norte-americano que não esteja certificado precisa de outra via, como as cláusulas contratuais-tipo.
• Foi contestado. O Tribunal Geral da UE negou provimento a um recurso de anulação em 3 de setembro de 2025 (processo T-553/23), e o recorrente interpôs recurso para o Tribunal de Justiça (processo C-703/25 P); o recurso ainda estava pendente quando este artigo foi escrito. Os dois quadros anteriores para os EUA, Safe Harbour e Privacy Shield, foram declarados inválidos por esse Tribunal.

O CLOUD Act dos EUA: a localização não é tudo

O Clarifying Lawful Overseas Use of Data Act foi promulgado em 23 de março de 2018 como parte do Consolidated Appropriations Act, 2018. Acrescentou o 18 U.S.C. 2713: os fornecedores de serviços de comunicações eletrónicas ou de computação remota têm de cumprir as obrigações previstas nesse capítulo (capítulo 121 do título 18) de preservar, fazer cópia de segurança ou divulgar comunicações e registos de clientes que estejam na sua «possession, custody, or control» (posse, guarda ou controlo), através do procedimento legal aplicável, independentemente de esses dados se encontrarem dentro ou fora dos Estados Unidos.

Na prática, um fornecedor norte-americano com um centro de dados em Frankfurt pode receber uma ordem dos EUA que abranja os dados aí armazenados. O RGPD impõe limites em sentido contrário: nos termos do artigo 48.º, uma decisão judicial ou de uma autoridade de um país terceiro que exija uma transferência ou divulgação só pode ser reconhecida ou executada na UE se tiver como base um acordo internacional, como um acordo de auxílio judiciário mútuo. Isto não exclui todas as divulgações, porque o artigo 48.º se aplica «sem prejuízo de outros motivos de transferência», mas qualquer divulgação continua a precisar de um fundamento jurídico nos termos do artigo 6.º e de um motivo de transferência nos termos do capítulo V. O fornecedor tem de resolver esse conflito, com os seus dados no centro da questão.

Para um destinatário norte-americano certificado ao abrigo do DPF, a decisão de adequação cobre a própria transferência: segundo o CEPD, não é necessário um instrumento de transferência separado nem medidas suplementares. Verifique se o destinatário consta atualmente da DPF List e continue a cumprir as suas outras obrigações do RGPD. O que uma região na UE, por si só, não muda é a lei do país a que o fornecedor está sujeito.

Porque é que a IA torna isto mais urgente

O RGPD define dados pessoais como qualquer informação relativa a uma pessoa identificada ou identificável, por exemplo por referência a um nome, um número de identificação, dados de localização ou identificadores por via eletrónica (artigo 4.º, ponto 1). Veja o que as funcionalidades de IA costumam tratar:

• pedidos de suporte e históricos de chat com nomes, endereços de e-mail e números de encomenda,
• currículos, contratos, faturas e cartas médicas carregadas para resumos ou extração de dados,
• transcrições de chamadas e notas de reuniões,
• repositórios inteiros de documentos indexados para retrieval-augmented generation (RAG).

Cada prompt com esse conteúdo implica o tratamento de dados pessoais e, se o modelo correr num país terceiro, pode ser uma transferência. Por isso, para cada componente de IA, faça as mesmas perguntas que faz para a sua base de dados: onde corre a inferência, os prompts e as respostas são armazenados ou registados em logs e durante quanto tempo, são usados para treino, e que fornecedor do modelo está por trás da API como subcontratante ulterior?

Lista de verificação: escolher um fornecedor

1. Sede e propriedade. Onde está constituído o fornecedor e quem é o seu proprietário? O CLOUD Act diz respeito a dados na posse, guarda ou controlo de um fornecedor, por isso a empresa por trás do serviço conta tanto como o centro de dados.
2. Região dos dados. É possível escolher uma região na UE para aplicações, bases de dados, backups e logs, e os dados ficam lá a menos que os mova? Onde correm o dashboard, a API e os dados da conta?
3. Acesso remoto e transferências ulteriores. Quem pode aceder aos dados, e a partir de onde? O acesso pelo próprio pessoal do fornecedor no estrangeiro exige segurança adequada. Disponibilizar dados a uma empresa distinta fora do EEE, como um subcontratante ulterior, exige um fundamento de transferência nos termos do capítulo V, que o exportador tem de avaliar e documentar. Servidores em Frankfurt não resolvem isto por si só.
4. Subcontratantes ulteriores. Peça a lista com o país de cada empresa. Nos termos do artigo 28.º, n.º 2, um subcontratante não pode contratar outro subcontratante sem a sua autorização prévia por escrito, específica ou geral. Verifique como é informado das alterações.
5. Acordo de tratamento de dados (DPA). O artigo 28.º, n.º 3, exige um contrato (ou outro ato normativo) com o seu subcontratante. Verifique se o pode assinar sem um contrato enterprise e em que via de transferência se baseia se os dados saírem da UE.
6. Certificações. Os relatórios ISO 27001 ou SOC 2 do fornecedor e dos seus centros de dados mostram que os controlos de segurança são auditados. Não dizem nada sobre a lei de que país se aplica, por isso leia-os em conjunto com os pontos 1 e 2.
7. Especificidades da IA. Localização da inferência, retenção de prompts e respostas, utilização para treino e o fornecedor do modelo por trás da API.

Como a Nodion trata disto

A Nodion é gerida pela Nodion GmbH, uma empresa alemã com sede em Stuttgart. As APIs e o control plane da Nodion estão alojados na Alemanha. A região EU Central fica em Frankfurt am Main; segundo a documentação das regiões, o seu centro de dados tem certificações ISO 27001, ISO 9001, ISO 14001 e ISO 50001, cumpre o PCI DSS e tem um relatório SOC 2, e o fornecedor de infraestrutura tem certificação ISO 27001, cumpre o PCI DSS e tem um relatório SOC 1.

A região é escolhida quando cria um serviço e não muda depois. As aplicações, bases de dados, volumes, buckets, o registry, os logs e as métricas desse serviço ficam na região escolhida. Os fornecedores de infraestrutura de cada região estão listados como subcontratantes ulteriores na documentação das regiões, e o DPA pode ser celebrado diretamente pelo cliente. A Nodion também tem regiões nos EUA, por isso escolha EU Central quando criar um serviço que deva correr na UE.