Onde uma reunião do InterMIND realmente roda

Toda conversa séria de compras corporativas chega, mais cedo ou mais tarde, à mesma pergunta: "Para onde vão esses dados?" O DPO quer uma lista de subprocessadores. O CIO quer saber quais fornecedores têm sede nos EUA. O jurídico quer um diagrama com setas.

Preferimos que você tenha o quadro completo do que ir entregando aos pedaços por e-mail. Então aqui está o caminho dos dados de uma reunião — cada serviço externo que ela toca, onde cada um executa e quais dados fluem por ele. Verificado contra a configuração real de deploy em 2026-05-28.

Há um caminho em que a sede do fornecedor ainda é nos EUA, e dizemos isso claramente. O resto é UE em tempo de execução.

O que "onde roda" realmente significa

Duas coisas costumam ser confundidas em conversas sobre soberania e não são a mesma coisa:

1. Tempo de execução / caminho dos dados. Onde os bytes da sua reunião são fisicamente processados durante a requisição. É disso que tratam as regulamentações de residência de dados e a maioria dos DPAs.
2. Sede corporativa do fornecedor. Onde o fornecedor SaaS está legalmente constituído. É disso que tratam as discussões sobre o CLOUD Act — o alcance teórico de uma intimação dos EUA contra a matriz do fornecedor, independentemente de onde o workload rode.

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

O caminho dos dados de uma reunião

Acompanhe uma chamada do join até o e-mail de follow-up:

1. O navegador abre a página da reunião. O SSR roda no 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 tempo de execução.
2. O WebSocket se conecta ao nosso servidor de reuniões em Paris (cdg). Orquestração de reunião, presença, sinalização — tudo na UE.
3. O reconhecimento de fala roda no navegador de quem está falando. Local. Nunca sai do dispositivo até que a transcrição resultante seja enviada para tradução. (Explicamos por quê em Inside the four translation pipelines.)
4. A tradução de voz e chat passa pelo nosso próprio motor na OVH França. Este é o mind-sdk-web — nosso código, nossos hosts, na França. Nenhum modelo de terceiros está no caminho. Orçamento sub-segundo, pool WebSocket por idioma, residente na UE em cada hop.
5. Um documento solto no chat (PDF, DOCX, PPTX, XLSX) vai server-side do ws-server de Paris para o DeepL em Colônia. Empresa alemã, processamento alemão. Voz e chat não tocam o DeepL.
6. Dados de aplicação — usuários, times, mensagens, metadados de reunião — ficam no Neon Postgres na AWS Frankfurt (eu-central-1). Snapshots na mesma região.
7. Gravações, anexos e exportações são armazenados no Tigris, storage compatível com S3 na Fly. Replicado na edge; o bucket é configurável para multi-região UE para tenants que precisam de algo mais restrito.
8. Erros e traces de performance vão para a instância UE do Sentry (de.sentry.io). A organização nos EUA foi desativada em maio.
9. Analytics de produto vão para o PostHog EU (eu.i.posthog.com).
10. E-mails transacionais (magic links, convites, recibos) saem via Resend a partir de eu-west-1 (Irlanda).

Tudo acima é UE em tempo de execução. O motor de tradução — a parte por onde a maior parte dos seus dados de fato flui — também é nosso próprio código, o que significa que o motor em si pode ser auditado ou auto-hospedado por um cliente que precise disso.

O mapa de fornecedores

Os dois fluxos de dados mais pesados em volume — tradução de voz/chat pelo nosso próprio motor na OVH e tradução de documentos pelo DeepL — também são os dois fornecedores cuja matriz está na UE. Isso cobre a maior parte do conteúdo da reunião. A lista completa de subprocessadores com detalhe de sede corporativa entra no DPA como prática padrão; a tabela acima é a visão de tempo de execução, que é do que tratam a maioria das cláusulas de residência de dados.

A única lacuna atual, dita claramente

Depois que a chamada termina, geramos um AI digest pós-reunião — tópicos, decisões, itens de ação, perguntas em aberto. O modelo que produz o digest é acessado via AI Gateway do Vercel (um proxy em região UE), mas os modelos subjacentes são o Google Gemini 2.5 Flash com fallback para Anthropic Claude Sonnet — ambos fornecedores com sede nos EUA.

A tradução de voz em tempo real, o chat em tempo real e a tradução de documentos não passam por esse caminho. O digest é uma etapa separada, pós-reunião, que pega a transcrição que já produzimos e escreve um resumo em cima dela.

Estamos fechando essa lacuna de duas formas:

1. Opt-out controlado pelo proprietário, chegando em breve. Um proprietário de workspace poderá desabilitar a pipeline do AI digest por completo, caso em que o resumo pós-reunião simplesmente não é gerado e a transcrição fica onde estava — na UE. Desligado por padrão para novos tenants; tenants existentes recebem um aviso e podem mantê-lo ligado se quiserem.
2. Modelo de sumarização auto-hospedado na UE. Estamos subindo um modelo de pesos abertos (classe Kimi) na OVH para tarefas como sumarização que não precisam de um reasoner de fronteira. Quando esse for o backend do digest, o trade-off some — a mesma pipeline funciona sem nenhum fornecedor com sede nos EUA dentro dela.

Se o digest é a diferença entre "isso serve para nós" e "isso não serve" para suas compras, nos avise — vamos priorizar de acordo.

O que isso significa para o seu DPA

Para a maioria dos compradores da UE — Mittelstand alemão, setores regulados rodando DPAs padrão de GDPR — o quadro acima responde diretamente à pergunta sobre residência de dados: cada hop de tempo de execução pela sua reunião está na UE. A sede do fornecedor é divulgada na lista de subprocessadores conforme prática normal; nada surpreendente ali.

Para souveraineté numérique francesa e compras de nível SecNumCloud, a sede corporativa do fornecedor é, em si, parte do critério, não apenas o local de execução. Essa é outra conversa — uma topologia de deploy alternativa que mantém cada componente sob fornecedores de jurisdição europeia. Não rodamos isso por padrão; subimos para um tenant que precise e em que o contrato justifique a construção.

Para compradores nos EUA e na maior parte da APAC, geralmente é o inverso — eles querem baixa latência a partir da sua região, o que é um problema diferente. Hoje rodamos em região única em fra1. Se o seu tráfego justifica uma edge nos EUA, planejamos 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 em nosso vercel.json aberto, no motor mind-sdk-web 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 faltante a você descobri-lo numa revisão de contrato.