Um caso típico — e suas consequências
Uma assistente de direção quer resumir rapidamente um contrato confidencial com um fornecedor. Ela cola as 40 páginas no ChatGPT Free, recebe uma visão clara em 30 segundos. O que ela não vê: o nome do contrato, o fornecedor, os preços e as cláusulas agora estão em servidores americanos da OpenAI — e podem entrar nos dados de treinamento de novos modelos, porque é o padrão do ChatGPT Free. Dados confidenciais do negócio dentro de um modelo que qualquer pessoa pode consultar amanhã.
Ou: uma profissional de uma ONG escreve um relatório sobre clientes em situação vulnerável. Ela digita: «Refine este parágrafo: Sra. M. (52) de Berna, mãe solo de três filhos, está sem moradia há dois meses...» Nome, situação, endereço estão agora em uma empresa americana.
Os dois casos não são exceções — são realidade do dia a dia em PMEs suíças, escritórios de advocacia e ONGs. Na maioria das vezes ninguém percebe os rastros que isso deixa nem as consequências legais possíveis. Este artigo mostra como reconhecer esses riscos — e como usar AI na sua organização sem violar o revDSG suíço ou o RGPD da UE.
O que «conforme à proteção de dados» realmente significa para AI
Muitos provedores de AI anunciam conformidade com o RGPD ou servidores na UE. Soa tranquilizador — mas é insuficiente. Um servidor em Frankfurt ou Genebra ajuda pouco se a empresa por trás é americana. Empresas americanas estão sujeitas ao CLOUD Act dos EUA — independentemente de onde estão seus servidores. Isso se aplica igualmente à OpenAI, Microsoft, Google e Amazon.
A questão decisiva, portanto, não é «onde está o servidor?» — mas: «Qual lei governa a empresa que processa meus dados?»
Quem entendeu isso enxerga rapidamente a diferença entre uso «seguro» e «inseguro» de AI — e pode decidir conscientemente quais dados podem fluir por qual sistema.
Chatbot de AI para seu site
Como construir um chatbot conforme à proteção de dados — SaaS ou sob medida.
O CLOUD Act — o risco subestimado
O CLOUD Act (Clarifying Lawful Overseas Use of Data Act) é uma lei federal americana de 2018. Ele autoriza as autoridades americanas a exigirem acesso a dados de empresas americanas — independentemente de onde os dados estão armazenados.
O que isso significa na prática: uma empresa americana que armazena dados em servidores europeus ainda deve fornecer acesso a uma autoridade americana. Não é obrigada a informar você ou os indivíduos afetados sobre isso.
Esse não é um cenário hipotético. As autoridades americanas usam ativamente essa possibilidade. Para PMEs suíças com obrigações de proteção de dados perante clientes, funcionários ou autoridades, esse é um risco legal real.
Um Acordo de Processamento de Dados (APD) com um provedor americano reduz seu risco de conformidade no papel. Mas não protege contra o acesso governamental americano aos dados. O APD regula o que o provedor pode fazer com seus dados — não o que ele deve fazer sob instrução do governo americano.
Uma subsidiária europeia protege contra o CLOUD Act?
Um contraargumento comum: a Microsoft opera a Microsoft Ireland, o Google tem a Google Ireland Limited, a Amazon tem a Amazon EU SARL. Não são empresas europeias sob lei europeia?
Não — não segundo o CLOUD Act. A lei aplica-se explicitamente a empresas americanas e todas as entidades por elas controladas. «Controle» significa que a empresa-mãe pode dar instruções à subsidiária. Isso é definitivamente verdade em relação a subsidiárias.
Uma autoridade americana obtém uma ordem contra a Microsoft Corp — não contra a Microsoft Ireland. A Microsoft Corp então instrui a Microsoft Ireland a fornecer os dados. A empresa-mãe tem tanto a obrigação legal quanto os meios técnicos para cumprir. O descumprimento arrisca desacato ao tribunal. A localização do servidor e o registro europeu da subsidiária não alteram nada nessa lógica.
A subsidiária europeia pode recusar o acesso americano aos dados?
Teoricamente sim — e aqui existe um conflito legal genuíno e não resolvido. O RGPD Art. 48 estabelece que transferências de dados para países terceiros com base em ordens governamentais estrangeiras devem ocorrer por canais MLAT ou acordos reconhecidos — não por compulsão direta. Uma subsidiária europeia tem portanto uma base legal para recusar.
Três razões pelas quais isso não oferece proteção real na prática:
O tribunal americano compele a empresa-mãe — não a subsidiária. A ordem é dirigida à Microsoft Corp. A empresa-mãe tem a obrigação de cumprir e o risco em caso de recusa.
Não existe um acordo bilateral EU-EUA sobre o CLOUD Act. A lei inclui uma cláusula de «governo estrangeiro qualificado»: se um país assinou um acordo bilateral com os EUA, provedores podem contestar ordens que conflitem com a lei desse país. O Reino Unido assinou tal acordo em 2022. A UE não. Sem esse acordo, não há caminho formalizado para bloquear ordens americanas.
O conflito recai sobre a empresa. Cumprir o CLOUD Act viola o RGPD Art. 48. Recusar arrisca desacato ao tribunal para a empresa-mãe. A Microsoft e a AWS tentam criar arquiteturas «EU Sovereign Cloud» que impedem tecnicamente o acesso de funcionários americanos aos dados europeus. Nenhum tribunal reconheceu isso como barreira legal.
Residência de dados ≠ soberania de dados. «Residência de dados» refere-se a onde os dados estão fisicamente armazenados. «Soberania de dados» refere-se a quem detém o controle legal final. Subsidiárias europeias garantem a primeira. Apenas a ausência de uma empresa-mãe americana na cadeia de controle elimina o CLOUD Act.
Três níveis de risco em perspectiva
Nem toda solução de AI carrega o mesmo risco. Três níveis bastam para estruturar a decisão — conforme os dados processados e os requisitos de conformidade aplicáveis.
O único critério decisivo é a entidade legal do provedor contratante: empresas americanas estão sujeitas ao CLOUD Act, empresas europeias não. A localização do servidor é secundária — uma «residência de dados na UE» oferecida por um provedor americano (AWS Bedrock UE, Azure OpenAI UE, OpenAI Enterprise UE) não altera a jurisdição.
| Nível 1: Provedores americanos | Nível 2: Gateway UE | Nível 3: UE/CH auto-hospedado | |
|---|---|---|---|
| Entidade legal | Empresa americana | Empresa UE ou britânica | Empresa UE/CH |
| Localização do servidor | EUA ou residência UE | UE | UE/Suíça |
| Risco CLOUD Act (provedor) | Alto | Nenhum (NL) / Baixo (UK) | Nenhum |
| Risco CLOUD Act (provedor de modelo) | Alto | Nenhum com modelo UE / Alto com modelo americano | Nenhum |
| Exemplos conhecidos | OpenAI, Anthropic, Google, AWS Bedrock UE, Azure OpenAI UE | EUrouter (NL), Requesty (UK) | Mistral, Infomaniak, Scaleway, Apertus |
| APD disponível | Sim | Sim | Sim |
| Para dados sensíveis | Não recomendado | Apenas com seleção deliberada de modelo | Recomendado |
Uma «residência de dados na UE» oferecida por provedor americano (AWS Bedrock UE, Azure OpenAI UE) não altera a exposição ao CLOUD Act — a entidade contratante permanece americana. No Nível 2, o gateway está fora da jurisdição americana, mas a chamada de modelo subjacente pode acionar a lei americana — ver seção do Nível 2. Em abril de 2026.
Nível 1: SaaS americano direto — quando é aceitável?
Provedores americanos diretos como OpenAI, Anthropic ou Google não são proibidos per se. O que importa é quais dados você processa.
Aceitável para: dados não pessoais (informações publicamente disponíveis, textos genéricos), uso interno sem dados pessoais, ou testes pontuais sem persistência de dados.
Não aceitável para: dados de clientes (nomes, e-mail, histórico de compras), dados de funcionários (candidaturas, informações salariais), dados de saúde ou financeiros, e documentos confidenciais com segredos empresariais.
Vários provedores americanos anunciam residência de dados na UE: OpenAI Enterprise com hospedagem UE, AWS Bedrock com perfis de inferência UE (eu-central-1, eu-west-1) para Claude ou Titan, Microsoft Azure OpenAI Service com deployment UE em Frankfurt ou na Suécia. Os dados ficam em servidores europeus — mas a entidade contratante continua sendo americana. O CLOUD Act continua a se aplicar. A hospedagem de dados na UE reduz o risco marginalmente sem eliminá-lo. Importante no APD: um provedor americano com região UE é juridicamente Nível 1, não um nível próprio.
Nível 2: Gateways UE como meio-termo
O Nível 2 são gateways: empresas europeias que não operam modelos próprios, mas encaminham sua solicitação a diferentes provedores de modelos. O gateway é uma camada intermediária. O resultado de privacidade depende, portanto, para quem o gateway repassa seus dados.
Dois exemplos conhecidos: EUrouter (registrado em Amsterdão) e Requesty (registrado em Londres). Nenhum dos dois está sujeito ao CLOUD Act dos EUA. O Requesty tem uma pequena exposição residual porque o Reino Unido assinou em 2022 um acordo com os EUA sobre acesso a dados. Ambos repassam sua solicitação, conforme sua escolha, a um provedor de modelo europeu (por exemplo Mistral da França) ou a uma plataforma americana com servidores europeus (AWS, Microsoft).
Dois resultados conforme a rota:
(a) Gateway → provedor europeu de modelo. Seus dados ficam inteiramente na Europa. Nenhuma empresa americana na cadeia. Efeito de privacidade praticamente como Nível 3 — apenas com duas empresas europeias no fluxo em vez de uma.
(b) Gateway → plataforma americana com servidores UE. O modelo roda em Frankfurt ou Estocolmo — mas Amazon ou Microsoft continua sendo o processador contratual sob lei americana. CLOUD Act volta a se aplicar. Sem vantagem em relação ao provedor americano direto.
O Nível 2 só compensa quando você escolhe deliberadamente um provedor de modelo europeu sob o gateway. Usar Claude ou GPT-5 via gateway UE significa aceitar lei americana de qualquer forma — o Nível 1 direto seria juridicamente equivalente.
Para provedores de gateway e nuvem, vale verificar ISO 27001 (gestão de segurança da informação) e SOC 2 Type II. Não substituem uma avaliação jurídica — mas comprovam que controle de acesso, tratamento de incidentes e processos internos foram auditados externamente. Para dados sensíveis, ao menos uma dessas certificações é o ingresso. Sempre solicite o relatório de auditoria atual (não apenas a promessa de marketing).
Nível 3: Provedores europeus com servidores próprios
O Nível 3 são provedores registrados na UE ou na Suíça e que executam seus modelos de AI em servidores próprios na Europa. Do contrato ao processamento, uma única empresa vê seus dados — sem intermediários, sem subcontratados americanos, sem provedores de modelo americanos a jusante.
Quais modelos de linguagem o provedor usa — próprios (como o Mistral) ou abertos (LLaMA, Mixtral, Qwen) — é secundário do ponto de vista da proteção de dados. Modelos são software. O que importa é quem efetivamente processa seus dados.
O CLOUD Act não se aplica aqui. A lei europeia e suíça de proteção de dados aplica-se integralmente. Isso torna o Nível 3 a opção mais segura para dados pessoais e sensíveis.
Mistral AI — França
Infomaniak AI Tools — Suíça
Scaleway Generative APIs — França
Apertus — Suíça (em desenvolvimento)
Lista de verificação: O que esclarecer antes de usar AI
Antes de implantar um serviço de AI em produção, questões fundamentais devem ser esclarecidas. Isso se aplica independentemente do provedor — revDSG e RGPD exigem decisões demonstráveis, não boas intenções. Uma consulta rápida ajuda a encontrar o ponto de partida certo.
Antes de começar
O que o revDSG exige concretamente de vocês
A Lei Federal de Proteção de Dados revisada (revDSG), em vigor desde setembro de 2023, estabelece requisitos concretos para o uso de AI. Três deles são particularmente relevantes para as PMEs suíças.
Obrigação de informação. Se vocês processam dados pessoais com AI, os titulares dos dados devem ser informados — de forma ativa e compreensível, não apenas nas letras miúdas da política de privacidade.
Base legal. Todo processamento requer uma base: consentimento, contrato ou interesse legítimo. Com sistemas de AI, isso frequentemente está mal documentado — especialmente quando dados fluem para provedores terceiros.
Transferência para terceiros países. Se dados são transferidos para países sem proteção equivalente (EUA), salvaguardas adicionais são necessárias. Cláusulas Contratuais Padrão (CCPs) são uma opção — mas podem não ser suficientes para provedores americanos devido ao CLOUD Act. O Comissário Federal de Proteção de Dados (PFPDT) deixou claro: o revDSG é aplicado com os mesmos instrumentos que o RGPD na UE — incluindo multas.
Comecem pelo registro de tratamento. Documentem quais ferramentas de AI utilizam, quais dados fluem e em que base legal. Isso não é um exercício burocrático — é a base sobre a qual podem demonstrar, quando necessário, que tomaram uma decisão cuidadosa. Uma hora de esforço poupa muitas horas de explicações ao PFPDT.
Infográfico: 3 Níveis de Risco para Privacidade de Dados com AI
Obrigado. O download começará em breve.
Conclusão: Conformidade não é uma declaração de certificado
«Conforme ao RGPD» e «servidor na UE» no painel do fornecedor significam pouco sem examinar o CLOUD Act. A questão decisiva é: qual lei governa a empresa que processa seus dados — não: onde está o servidor.
Para PMEs suíças sem departamento jurídico especializado: o Nível 3 é a escolha segura para dados sensíveis. Mistral (França) oferece seus próprios modelos frontier sem risco de CLOUD Act. Infomaniak (Suíça) oferece controle local máximo para tarefas padrão — incluindo cadeia de dados de parte única.
O Nível 2 (gateway UE: EUrouter, Requesty) faz sentido quando você quer jurisdição UE/CH no nível do provedor mas precisa de modelos frontier como Claude ou GPT-5 — combinado com endpoints com deployment UE.
O Nível 1 (provedores americanos, com ou sem residência de dados UE) é pragmaticamente defensável para tarefas do dia a dia sem dados pessoais — rascunhos de textos, resumos internos, pesquisa.
A boa notícia: alternativas conformes à UE e à Suíça existem, estão prontas para produção e não são mais caras que seus equivalentes americanos. A decisão não é uma questão de orçamento — é uma questão de conhecimento. Quem conhece as opções pode escolher com confiança. E quem precisa de suporte com a integração de AI pode encontrá-lo sem comprometer a proteção de dados.
Qual provedor se adequa ao seu setup e o que exatamente precisa ser documentado — isso pode ser esclarecido em uma conversa rápida. Sem jargão técnico, adaptado à sua situação.
