Onde uma reunião do InterMIND realmente roda

Mais cedo ou mais tarde, alguém do lado do host (a TI de um cliente, um DPO, um parceiro cauteloso) faz sempre a mesma pergunta: "Para onde vão esses dados?" Essa pessoa quer uma lista de subprocessadores, os domicílios dos fornecedores e um diagrama com setas.

Preferimos que você tenha o quadro completo a recebê-lo em pedaços, por e-mail. Por isso, aqui está o caminho dos dados de uma reunião: cada serviço externo que ela toca, onde cada um executa e quais dados passam por ele. Verificado contra a configuração real de deploy em 2026-05-28.

Todo caminho que toca o conteúdo da reunião fica na UE em runtime. Isso inclui as etapas de IA, que rodam no gateway de IA que sua organização seleciona, em uma região da UE do nosso próprio tenant. Os fornecedores por trás desse gateway são empresas dos EUA que operam regiões na UE. Dizemos isso com clareza mais abaixo, e dizemos também qual modelo fica totalmente fora da reunião.

Este post mostra onde sua reunião roda. O texto complementar, Do que é feita uma reunião do InterMIND, mostra do que ela é feita: quais camadas são código nosso, quais são open-source e onde somos pragmáticos com SaaS proprietário.

O que "onde roda" realmente significa

Duas coisas são confundidas nas conversas sobre soberania, e elas não são a mesma:

1. Runtime / caminho dos dados. Onde os bytes da sua reunião são fisicamente processados durante a requisição. É disso que tratam as regulações de residência de dados e a maioria dos DPAs.
2. Domicílio corporativo do fornecedor. Onde o fornecedor de SaaS está legalmente constituído. É disso que tratam as discussões sobre o CLOUD-Act: o alcance teórico de uma ordem dos EUA contra a matriz do fornecedor, independentemente de onde a carga de trabalho roda.

Quase toda pergunta do tipo "isso é UE?" é, na verdade, uma dessas duas, feita de forma imprecisa. Respondemos a cada uma separadamente para cada fornecedor abaixo.

O caminho dos dados de uma reunião

Acompanhe uma chamada desde a entrada até o e-mail de follow-up:

1. O navegador abre a página da reunião. O SSR roda na Vercel, fixado em fra1 (Frankfurt). Todos os dados de requisição/resposta (cookies de sessão, payloads de API, HTML renderizado no servidor) são processados na UE em runtime.
2. O WebSocket se conecta ao nosso servidor de reuniões em Paris (cdg). Orquestração da reunião, presença, sinalização: tudo na UE.
3. O reconhecimento de fala roda no nosso servidor de mídia. O áudio chega por WebRTC ao nosso próprio engine, a Mind API na OVH, França, e é reconhecido ali, palavra por palavra, no mesmo servidor que carrega a chamada. Nenhum serviço de fala de terceiros entra no circuito. As mensagens de voz no chat são a única exceção: a conversão de fala em texto delas roda no Azure AI Speech, o serviço de fala do gateway de IA padrão (tabela de fornecedores abaixo). O pipeline em si está em Por dentro dos quatro pipelines de tradução.
4. A tradução de voz e de chat passa pelo nosso próprio engine na OVH, França. Ele é o mind-sdk + a Mind API: nosso código, nossos hosts, na França. Nenhum modelo de terceiros entra no circuito. Há uma tradução por idioma de destino presente na sala, com residência na UE em cada salto.
5. Um documento colocado no chat (PDF, DOCX, DOC, PPTX, XLSX) vai, pelo lado do servidor, do ws-server de Paris para a DeepL, em Colônia. Empresa alemã, processamento alemão. Voz e chat não tocam a DeepL.
6. Os dados da aplicação (usuários, equipes, mensagens, metadados das reuniões) ficam no Neon Postgres na AWS Frankfurt (eu-central-1). Os snapshots ficam na mesma região.
7. Gravações, anexos e exportações são armazenados no Tigris, armazenamento compatível com S3 na Fly. Ele é replicado na edge, e o bucket pode ser configurado para multirregião na UE para tenants que precisem de uma fixação mais rígida.
8. Erros e traces de desempenho vão para a instância da UE do Sentry (de.sentry.io). A organização dos EUA foi desativada em maio.
9. A análise de produto vai para o PostHog EU (eu.i.posthog.com).
10. E-mails transacionais (magic links, convites, recibos) saem pela Resend, a partir de eu-west-1 (Irlanda).

Tudo isso fica na UE em runtime. O engine de tradução, a parte por onde passa a maior parte dos seus dados, também é código nosso, não de terceiros. O SDK de cliente em que ele roda é open-source (BSD-3-Clause) e auditável hoje. Hospedar o engine em si no ambiente do cliente está no roadmap, para quem precisar.

O mapa de fornecedores

Os dois fluxos de dados mais pesados em volume, a tradução de voz/chat pelo nosso próprio engine na OVH e a tradução de documentos pela DeepL, também são os dois fornecedores cuja matriz está na UE. Isso cobre a maior parte do conteúdo das reuniões. A lista completa de subprocessadores, com o detalhe de domicílio corporativo, entra no DPA como prática padrão. A tabela acima é a visão de runtime, que é do que trata a maioria das cláusulas de residência de dados.

As etapas de IA, nomeadas com clareza

Depois que a chamada termina, executamos algumas etapas de modelo de linguagem sobre o que foi dito: o AI digest (tópicos, decisões, action items, perguntas em aberto), o resumo pós-reunião e o editor de notas com IA (traduzir uma nota, ou corrigi-la, ampliá-la ou simplificá-la). Durante a chamada, o mesmo tipo de etapa escreve um resumo de cada documento colocado no chat e responde ao Ask AI e à Mia. Esses são os únicos lugares em que um modelo de uso geral toca conteúdo derivado da reunião, e todos eles vão para um só lugar:

• O gateway de IA que sua organização seleciona. Um único resolvedor no código o escolhe para cada ponto de chamada; não existe um segundo caminho. O padrão é o Azure OpenAI na EU Data Zone. Nas configurações, a organização pode mudar para o Vertex AI no endpoint multirregional da UE ou para o Amazon Bedrock em Frankfurt, ou apontar todos os recursos de IA para seu próprio endpoint compatível com OpenAI: vLLM em seu próprio data center, uma implantação em seu próprio tenant. Cada gateway hospedado roda no nosso próprio tenant, configurado com retenção zero de dados e sem treinamento com conteúdo de clientes. O fallback permanece no mesmo gateway (uma segunda região da UE ou um segundo modelo do mesmo fornecedor), nunca em outro fornecedor. A documentação de recursos de IA lista os gateways e as regiões.
• O resumo e a ação traduzir do editor passam pelo caminho de tradução, não pelo modelo de linguagem: o mesmo caminho que traduz o chat ao vivo.
• A IA pode ser desativada para a organização inteira: a transcrição e a tradução continuam funcionando; o digest, os resumos de documentos, o assistente de escrita e o Ask AI são interrompidos.

A voz em tempo real, o chat em tempo real, as notas e a tradução de documentos nunca passam por nenhuma dessas etapas: sempre tiveram residência na UE desde o início.

Onde ficam os fornecedores: Microsoft, Google e Amazon são empresas dos EUA que operam regiões na UE. Isso está dito com clareza na página de confiança, não escondido. É a questão do domicílio corporativo do início deste post, respondida para esse salto da mesma forma que para a infraestrutura de base. Um modelo fica totalmente fora da reunião: nosso benchmark público de qualidade de tradução usa um LLM como juiz (Gemini, com Claude como fallback, via AI Gateway da Vercel) para pontuar traduções automáticas de frases de referência do FLORES-200. É um conjunto de dados fixo e público, não a reunião de ninguém.

O que isso significa para o seu DPA

Para a maioria dos compradores da UE (o Mittelstand alemão, setores regulados que usam DPAs padrão do GDPR), o quadro acima responde diretamente à questão da residência de dados: cada salto de runtime que sua reunião faz está na UE. O domicílio dos fornecedores é divulgado na lista de subprocessadores, conforme a prática normal; nada de surpreendente aí. O mapa de residência é uma peça. Para as demais obrigações de proteção de dados (eliminação, retenção, portabilidade, consentimento), submetemos a base de código a uma auditoria completa e fechamos cada item no código.

Para a souveraineté numérique francesa e para compras no nível SecNumCloud, o domicílio corporativo do fornecedor é em si parte do critério, não apenas a localização de runtime. Essa é outra conversa: uma topologia de implantação alternativa que mantém todos os componentes sob fornecedores de jurisdição europeia. Não a operamos por padrão; montamos para um tenant que precise dela e quando o contrato justificar a construção.

Para compradores domésticos dos EUA e da maior parte da APAC, o inverso costuma ser verdade: eles querem baixa latência a partir da sua região, o que é outro problema. Hoje operamos em região única, em fra1. Se o seu tráfego justificar uma edge nos EUA, planejaremos isso com você.

A que este post nos compromete

Este é o quadro em 2026-05-28. Vamos atualizá-lo quando a stack mudar: troca de fornecedor, migração de região, um novo serviço externo. A configuração atual é verificável no nosso vercel.json aberto, no engine mind-sdk + Mind API rodando na OVH França e no dashboard de cada fornecedor.

Se algo aqui parecer errado, ou se o seu DPO precisar de uma resposta que este mapa não dá, escreva para nós. Preferimos corrigir um detalhe que faltou a deixar que você o descubra em uma revisão de contrato.

Fontes: regiões de runtime e roteamento de modelos verificados contra a configuração implantada (vercel.json, fly.toml) e o código publicado; Vercel AI Gateway (o caminho de fixação de provedor do digest), FLORES-200; verificado em agosto de 2026.